Open Insurance Data Standard - White Paper Working Group - 11/11/24
Attendees:
Peter Antley
Jim Bamberger
Rob Clark
Cory Isaacson
Andy Mielke
Lanaya Nelson
Nathan Southern
Greg Williams
Central Discussion
Peter Antley (PA) revised his diagram per the above and provided the following high-level notes:
The goal in the creation of the above diagram was to outline the process and to outline why the work that this group is doing makes sense.
From the carrier’s perspective, everything starts with the Policy Administration System (center, above) and the Claims Processing System (4 o’clock from center, above).
The two teams labeled above that have a direct connection to the system are the Data Support Team and the Consumer Support Team that provides direct support to whoever is ‘consuming’ the application.
Data Engineering extracts the relevant information from the Claims Processing System and the Policy Administration System. Then the Consumer Support Team handles the data. The CST validates the data, makes the transformations that are required and submit the data to the consumer.
From a stat plan perspective: data engineering will extract the data; it will then be validated and put into the stat plan format and submitted to the stat agent.
In addition to reporting to the stat agent, a number of carriers report to the DOIs - for the DOIs and for business partners, the process is much the same - extract, validate, transform format.
The idea is to follow this process for every one of your consumers for every line of insurance that is being consumed.
It is possible to add numerous identical workflows and say “this is multiplied each time you have a new consumer” (or a new requirement).
The above process (the current one) is tedious and laborious and the above illustration/diagram reflects this.
In addition to that, the future state process is a one time only process, that supplies information to everything/everyone else that future state is visually depicted here:
In this future state, the process is as follows: carriers & P&C systems send their data to conversion into the OIDS format, then the data is rerouted to numerous parties (stat agent, analytics partners, business partners, etc.)
Note that it also retains the vertical line of direct contact with the DOI from the carrier - however, the DOIs typically don’t look for data at the policy & claim (coverage) level but at the aggregate data level - which is why this diagram above doesn’t filter DOI info collection through the transformative process. Note: there was some objection from participants in the meeting to this idea - the logic being that if everything is done at a coverage level you can always “roll up” to aggregate, but you cannot “roll down.” Accordingly, PA revised the above diagram to reflect this:
The idea of the above involves building everything around the OIDS format, which will make everything easier. It means using one system to do everything, not multiple systems used to put this data together.
PA indicated that he will add a whole new section to the white paper about a company that has multiple systems contributing to the stat process - indicating how tedious and cumbersome that is. (See Action Items, below).
-Key questions for Peter to consider in augmenting the above diagram:
How can we show multiple policy admin systems
How can we add standard OIDS exporters/transformers?
How can validations be diagrammed in?
The benefit of this future state: even if you have multiple source systems, it is still fairly simple. Diagramming multiple source systems for one carrier will showcase many of the efficiencies of this new system.
Format Discussion
Rob Clark (RC) indicated that Cloverleaf has a format, and they can turn it over to PA and his team, so that the latter can investigate and decide what about that format needs to change.
RC described the Cloverleaf format as follows: it is basically a policy record and a claim record that both oeprate at a coverage transaction level. This is how the data is feeded. Cloverleaf has additional data formats that are specific by line of business - for instance, they have a personal auto format that is make, model, year, etc. But the policy and the claim are the core that enable most of the reportage - except in cases where the lines have really specific and unique needs (such as, for example, home construction lines and corresponding data calls.)
PA asked, in turn, how specific/detailed we want the white paper to get in terms of clarifying the format, and Cory Isaacson (CI) recommended just specifying something broadly, along the lines of a csv format or an excel format.
Cloverleaf typically uses csv files instead of .json.
Next Meeting
A series hadn’t been set up on a weekly basis for the white paper task force. CI requested that Lanaya reach out to Laura (Cory’s EA) to facilitate a recurring series based on reThought and Cloverleaf’s availabilities.
PA anticipates adding additional details to the white paper and moving into a discussion of outlines in the follow-up white paper meetings.
Action Items
Peter Antley - add a new section to the white paper about a company that has multiple systems contributing to the stat process - indicating how tedious and cumbersome that is.
Peter Antley - Per Cory’s suggestion, add the transform step to each path in the future state diagram in the white paper. Also diagram in validations - which should happen each time before data is put into the OIDS format.
Peter Antley - Add a second diagram with multiple source systems for one carrier.
Peter Antley - Once this is all in place, schedule a second working group meeting.
Cloverleaf Team - Share the current Cloverleaf data format with Peter Antley for close review.
Lanaya Nelson - Work on scheduling follow up white paper task force meetings (a possible series)