Public Page

2021-03-9 Architecture Meeting Minutes

Public Page

 

      
   CIECA 500 Westover Dr  #11617; Sanford,  NC  27330 

 

Date

Mar 9, 2021

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

  • Antitrust and Meeting minutes acceptance

  • Privacy Issues with Name and Company

  • Review Action Items

    • Swagger Hub

      • Paul checked with SmartBear on when they plan to implement 3.1 in Swagger Hub

    • Indicator

      • Chris is looking into values used for Indicator

    • Data Type Usage

      • Dan and Mike both have documentation to present to the team.

        • Mike has updated the CIECA - Open API Data Types we reviewed last week

        • Dan has the BMS-CAPIS simplification comparison Excel sheet

        • JSON Style Guide

        • Several Schemas

      • Andy is creating a script to see how often a data type is used.

  • FNOL

    • Look at ADMIN INFO and break it into the Data Types and Aggregates that we need.

Meeting Minutes

  • Antitrust Accepted

  • Meeting Minutes were accepted

  • Swagger

    • Paul Checked with SmartBear about the implementation of OES 3.1; they replied that it is on the radar but not prioritized. They are looking at the Member needs to determine priority.

    • Bryan the Product Manager from SmartBear reached out to propose a new time to present the team with a demo. He recommended next week.

      • When the invite is sent, the Architecture meeting for March 16 to be a Swagger Hub demonstration.

    • 3.0 Vs 3.1 There was Data Types supported in 3.0 that have been removed.

      • Not sure if these data types were actually removed, it could be that they are using extensions as part of the die out directive, they may still be allowed but not supported.

        • base34 and base64 are two data types that were in 3.0 and no longer in 3.1

    • Without Swagger Hub being updated, they will not supported our data types and standards.

      • We can use other tools to generate the schemas, Swagger Hub does not have to hold us up.

  • Mike made updates to the Word Document CIECA - Open API Data Types_3_8_2021

    • Mike made modifications to the document that was requested from the last meeting.

      • Email, Time and duration is defined in JSON

      • Timestamp Needed?

        • It goes to the millisecond, is that something that is required?

        • The Committee recommended to Drop Timestamp Data Type.

      • Decimal, Currency, Percentage

        • BMS has named ranges for Decimal and percentages allowed, along with Character limits for other data types.

          • Is this something we want to continue?

            • Can we do TShirt Sizes of ranges and Character limits? For Example Small Character, Medium Character and Large Character?

            • CIECA rule if anyone request for a field to be larger, we will go larger.

      • Everything in the CIECA Column is unsupported in JSON.

  • Privacy Issues

    • Topic came up when removing OrgId and PersonId last week, that could we merge them into one and still provide Privacy.

      • Some background, CIECA is taking slack over data privacy at this time. Companies are saying that CIECA messages do not provide security, so they are having to modify messages to be PII compliant.

        • This is of course allowed because the BMS has the fields but Private fields are not required, therefore, they are actually doing what CIECA recommends to create more secure and private messaging.

      • CIECA has been educating the industry that CIECA messages have private data and the implementations need to be secured.

    • In moving forward

      • CIECA messages should be micro messages that only have the data required for the message.

        • There are some messages that will require Private fields, such as name and phone number of VIN

          • Do we want messages that have privacy information and messages that do not have the privacy information?

            • It was concluded that if Privacy information is not required, it will not be included, however, if it is required, that we will tag the message to identify it as a messages that has PII.

        • VIN PII?

          • There are many industry segments requesting VIN to be private, because they do not want the information on a vehicle to be sold to others.

            • Would it be possible to identify a car with last 6 of VIN? Not to be accurate.

            • As being discussed above, VIN is something that the insurance company and body shops need to communicate to make sure they are working on the correct vehicle.

            • Compound fields for VIN? Compound fields means the data is still there and can still be obtained, so it is no more secure than one field with the data. As Andy stated, its like a fence around your yard, it will prevent good people from coming onto your property, but its not going to keep the bad guys out.

        • CIECA will need to Identify all the Elements and Aggregates that contain PII so we can easily identify messages with PII.

  • Dan walked us through the Excel document BMS-CAPIS simplification comparison

    • Does Address need a Type?

      • Today we have address types of unknown, street, mailing, etc.

      • Early discussion, the committee feels we need to keep address types.

    • Coordinate Longitude and Latitude.

      • These were removed first round, with onStar, they will provide the accident location with these elements. We need to look at which data we will need to keep.

    • International data aggregates or elements

      • Address in other countries are different, so do we want to look at the International standard?

      • Phone number is another International element that will need to be reviewed.

    • Other Elements Vs Custom Fields

      • We don’t think we need both?

Great Meeting Everyone! Hour Flies by when your making progress. Thanks for all the great information and work!

Up Next

During this one-hour session we will be able to speak about SwaggerHub Enterprise features, show you examples in real time, and also answer your questions on having a collaborative platform for all your APIs.

Below is a quick agenda, feel free to send me any specific testing scenarios that your team has so we can tailor the session as best as possible.

Agenda:

  • Introduction: Cieca & SmartBear Teams

  • SmartBear Story

  • Cieca’s Criteria

  • Swaggerhub Presentation

  • Q&A

  • Determine Next Steps

    • Trials: Set up check-in calls

Action Items

Decisions

  1. TimeStamp Data Type will be dropped and not used in the APIs.

 

 

Participants

  • @Paulette Reed

  • Mike Hastings

  • Dan Webster

  • Jeff Schroder

  • Andy Bober

  • Paul Barry

  • Cindy Chapman

  • Brad Broerman

  • Aaron Daniele

  • Phil Martinez

Participants in the meetings are noted for your information.  If you have questions on the committee’s activities, please contact a recent attendee. Architecture Committee