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
Update on SmartBear/SwaggerHub
Do we want to add a new section to the Architecture Guidelines for CAPIS guidelines or should we have a separate document
SmartBear is still having issues getting a technical resource to demo SwaggerHub to us.
It was agreed that we would go ahead and get a trial version or monthly subscription of SwaggerHub to try it out.
CAPIS Guidelines
The current Architecture Guidelines will be used for BMS and a new version of CAPIS Guidelines will be created for the CAPIS project and moving forward.
GITHUB
After the last meeting we created a Project, however, its just a Kanban board version of the Repository.
We will be creating a new Repository under GitHub
CAPIS
In accordance with the not having arbitrary hierarchy we will be removing Admin Info, Org Info, Person Info.
Another CAPIS Guideline would be to minimize the required fields, which will not be called properties using JSON terminology.
Data Types used in JSON is (boolean,string,number) and each of these can be formatted/patterned.
Do we want to use formats/patterns and cause invalid properties errors on messages?
it is rare to receive an invalid email error, even when passing an error.
Open API has standard formats/patterns for things like email and phone number. We need to review these and see if we can use them and if there are others we need to add.
Mike Hastings is going to work on preparing to present this information to the committee.
ID Info needed?
ID info reflects how they are being identified (Policy Number, Account number, Employee Number, etc) and the number. This can be used for an individual or a company.
It is seen that this is needed to stay.
Communication
Phone number should not be formatted, in recent years, formatting of the phone number is become unnecessary.
Communication Qualifier will identify the communication type as home phone, work phone, email, etc. Do we need to have Com qualifer to repeat or should we have each one identified.
In looking at the iPhone contacts, you can have zero to many phone numbers (home, work, School), as well as many addresses (CIECA may need Billing Address), emails, social media(Twitter, Facebook, etc).
Mike Hastings is going to look at how Facebook and other popular companies define a User/Person.
Have a great week everyone!
Up Next
Antitrust and Meeting minutes acceptance
Review Mike Hastings Action Items
Continue to work on the CAPIS.
FNOL Use Case
Look at ADMIN INFO and break it into the Data Types and Aggregates that we need.
Do we want to add a new section to the Architecture Guidelines for CAPIS guidelines or should we have a separate document?
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