Disposition 2022-1-26 Invoice and Status Kickoff Meeting notes

Date

26 Jan 2021

Agenda

• Antitrust

• Introductions

• Future of CIECA

• Business Use Case Review for Appointment/Archive Word Documentation

• Pain Points or new Implementations needed

• API Standards

• Concept of Product Based Committee’s and meeting occurrences.

Meeting Minutes

• Antitrust Accepted

• Introductions of CIECA Staff and Committee Members on the call

• Future of CIECA

  • Reviewed the new http://cieca.com design by introducing the home page with the new video.

  • Reviewed the Products approach to the Standards documentation.

  • Reviewed that Most of the Standards Development Committees have been in maintenance mode for years, these committees used to meet twice a year for the Semi-Annual Meetings, however, the Technical CIECAST replaced those meetings and some of the meetings have not meet because the chairs did not have new work to propose.

    • Calibration last meet July 2020

    • CER last meet May 2018

    • CSI last meet October 2011

    • FNOL last meet September 2017

    • Glass last meet November 2012

    • Information Privacy Ad Hock last meet April 2021

    • Photo Estimate last meet September 2018

    • PMP last meet December 2009

    • Rental last meet July 2012

    • SCAN last meet June 2018

    • Scheduling last meet March 2014

  • Talked about scheduling the meetings and working on the Product based approach.

    • Products with Single Committee

      • Appointment - Scheduling Committee

      • Claims - VDI Committee

      • Valuation - Total Loss Committee

      • Disposition - Salvage Committee

      • Location - Rental Committee

      • Vehicle Repair - Repair Status Committee

      • Status - Subrogation Committee

      • Survey - CSI Committee

      • Title - Titling Committee

    • Products with Multiple Committee

      • Assignment (CER, Glass, Rental, Scan, Subrogation and VDI Committees)

      • Attachment (CER and Scan Committees)

      • Authorization (Rental and Repair Status Committees)

      • Estimate (Calibration, CER, Glass, SCAN, and VDI Committees)

      • FNOL (FNOL and SCAN Committees)

      • Invoice (Glass, PMP, RP&I, Rental, Salvage, Subrogation and VDI Committees)

      • Procurement (CER, Glass, PMP, RP&I, Repair Order and SCAN Committees)

  • The old web page design was based around the Standards as a package in Drop Box, but the Use Cases and Implementation Guides were based on the Committee that created the documentation. This could be easy if you were looking at the BMS and seen Tilling Services and saw a committee named Titling. However, this was not as straight forward for Location being under the Rental Committee. It was even more difficult for Assignment where you would have CER, Glass, Rental, SCAN, Subrogation and VDI documentation. You may find Assignment under Rental and not know to go look at the other examples. This is why we thought it would be best to move to a Product design.

• Business Use Case Review

  • Reviewed the Invoice and Status Business Use Case Documentation and showed the Committee based Implementation Guide as a comparison.

    • The Word Document(s) had committee information, which was moved to the committee Confluence page, and the description, industry benefits, triggers and messages were moved to the business Use Case.

    • The Business Use Cases were approved.

    • Archiving the Word document Implementation Guides for Invoice and Status Committee was approved

  • Next up will be moving the implementation Guides and Test Instances to Product base.

  • Discussed concept of moving the Standards Development Committees to be Product Based

    • This would mean that Scheduling Standard Development Committee would be Appointment, that is simple, but Assignment would replace CER, Glass, Rental, Scan, Subrogation and VDI)

    • All Standard Development Committee’s would have the same Charter and Business Plan but specific for that Product and consist of the industry expertise for that product.

      • New Invitations to the Industry would be sent to get members.

    • The Standard Development Committee would be responsible for approving all work proposed for their Product.

    • Projects:

      • If work would only impact one product, then the Standard Development Committee would be responsible for the work

      • If work would impact more than one product, a Project Committee would be implemented, and goals set for that Project. The project would be completed when the standards was proposed and approved by the SDC, SAB and/or Architecture Committees.

• API work

  • Architecture is working on the proof of concepts for the data aggregates especially the Common Type data aggregates.

  • When the work is completed, the Architecture will work with the Standards Development Committees for each product to help train how the messages should work.

  • Each SDC committee will be responsible for creating the APIs they would like to use and then Architectures will review and approve.

• Brainstorming/Discussion of Messages and Pain Points.

  • When new API and committee is formed, we need to make sure we have representation from Subrogation, they are critical and added a lot to the current messages.

Great Meeting Everyone and Thank you for your participation and continued support of CIECA.

Up Next

• Meeting Occurrence can stay as when needed at this time

  • See more meetings starting for Implementation Guides moving to Product and with new API development.

Action items

Decisions