Public Page

2022-12-06 Architecture Meeting Minutes

Owned by Paulette Reed
Last updated: Dec 13, 2022
3 min read

Public Page

Date: Dec 6, 2022

 

 

 

ANTITRUST STATEMENT

As participants in this meeting, we need to be mindful of the constraints of antitrust laws. There shall be no discussions of agreements or concerted actions that may restrain competition. This prohibition includes the exchange of information concerning individual prices, rates, coverages, market practices, claims settlement practices, or any other competitive aspect of an individual company’s operation. Each participant is obligated to speak up immediately for the purpose of preventing any discussion falling outside these bounds.

Agenda

  • Network/Welcome

  • Antitrust

  • Review Meeting Minutes

  • Moving BMS to CAPIS Data Dictionary

Meeting Minutes

  • Antitrust

    • Reminder that we were going to review onscreen and not read the antitrust

    • Antitrust accepted

  • Meeting minutes reviewed and accepted

    • Architecture meetings being in JSON so only architecture could read them

  • Mitchell is going to use the capis schema for claim save

    • Found that in the release we moved the structure from GitHub and in doing that the unbundled schema is now invalid until we move the dependents and the definitions to be in the sister directory.

    • Party Type code list does not follow the enumerations and follows a different design pattern.

    • Property Info is needed in assignments for claim save. There is a possibility of a vehicle info or property info to be used, and this is an example of the extensions that we want everyone to feel like they can do.

  • Car Part is using capis and working with the part information

    • Right now everyone is working on getting experience with capis and coming up with questions and suggestions.

  • We are sticking with Zero Based Budgeting concept moving forward

    • If we have a code list for “car ID” and “carID” we need to clean this up

    • Code list for Party is a monster and we need to look at making sure we use the enumeration pattern and not an array.

      • In the first release we have the array

      • we need have instances that will validate an error when the enumeration pattern is not used

  • Versioning

    • Mike did homework on versioning and likes the Version in the URL approach

      • Lots of positive feedback for the Version to be in the URL for capis.

      • Most companies do not run to versions of the same message at the same time, so there is a little pushback.

        • But putting the version in the end point gives you the advantage of running side by side if you want.

        • The larger platforms that drives implementations with their partners is different than the little guys that have to work with different systems and keep up with all those implementations of the larger guys. This allows the little guy a break.

  • Education on API

    • There is a Blog on 200,000 Open API files by postman that has a lot of good information

    • Both Stoplight and Swagger are doing presentations

      • Mike is attending to hope to find when open API 3.1 will be available

  • Arrays Vs inline parameters

    • Mike displayed an example in XML Spy

      • On the left side we have part nums array and a part prices array

      • On the right side is where we flattened those arrays into properties

    • Programmers prefer the flattened and optional parameters over the array.

    • The Party can be a Company or Person in the BMS and CAPIS, so with a Company we recommend adding a Contact Object.

      • We need to discuss this and get approval in another meeting.

      • ID Info

        • Systems talking to each other need for contact is an ID and it can be an integer or a GUID

        • We need one ID

        • We would have ID for specific fields, so UUID we would call UUID and make it a type of UUID or format

          • In the previous versions we would have XOR so you could use integer ID or UID so you would know to use one or the other

          • In JSON it will be optional, so it would be possible for them both to be sent or neither.

        • Recommending longer dictionaries and simpler instances

        • Custom Elements and Named Value Pairs

  • Jira Review

    • Review JIRAS in the next meeting.

Great meeting everyone. A man with one watch knows what time it is, a man with 2 watches never knows what time it is. (Segal’s law)

Up Next

  • Network/Welcome

  • Antitrust

  • Review Meeting Minutes

  • Review JIRAS

Action items

Decisions

 

Participants

  • Paulette Reed

  • Dan Webster

  • Mike Hastings

  • Jeff Schroder

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. https://cieca.atlassian.net/wiki/spaces/ARCH