Open Insurance Data Standard - White Paper Working Group - 11/18/24
- Nathan Southern
Attendees:
Peter Antley
Jeff Braswell
Cory Isaacson
Andy Mielke
Lanaya Nelson
Nathan Southern
Jennifer Tornquist
Greg Williams
Opening Remarks
Peter Antley (PA) began by acknowledging the LF Antitrust Policy (above) then welcomed attendees to the group.
Central Discussion
PA began by re-referencing his visual depiction of the Current State process, pictured above and discussed in the previous session on Nov. 11th. He made the following high level points about this diagram:
This shows that we have four different consumers consuming policy from the same two policy/claim administration systems.
In this diagram, the data begins in the middle systems. The relevant data gets extracted out.
The team that is focused on submitting the data to the end customer then has to validate, prepare the data in the consumer’s format and then notify them of the data and send the data.
The above could be okay for a small mutual company, for example, but in the case of the type of stat reporting that this team is trying to do, we might have one parent company that buys up and sells smaller ins. companies to buy up an insurance group - so the idea of one policy and one claim system doesn’t fit how the market works.
This explains the presence of three different policy and claim systems, as in the diagram below.
The addition of numerous additional consumers and additional layers has a tendency to become extraordinarily complicated; Cory Isaacson (CI) suggested copying and repasting variations on the same diagram multiple times to illustrate different systems (instead of, say, combining everything into one multilayered diagram).
The whole flow changes for each consumer
Clearly showing the constant replication of work/replication of processing in the Current State can reinforce the idea that there are numerous redundancies, work done in parallel over and over again with various adjustments - which will elevate the cost to unreasonable levels.
The future state model is as follows:
The following high-level considerations should be made:
The primary change in this diagram from the previous version that Peter presented is the ‘Map to DOI Format’ box at the center. This is a prerequisite for going from the Open Insurance Data Standard straight to the DOI, because at present the DOIs don’t have a way to accept data that isn’t in the DOI format - which is an aggregate, high-level format.
PA also added the phrase “Validated on Extraction” to clarify, per a prior request, where the validations come into play schematically.
PA feels that ideally, in the future state, most of the consumers will be ingesting the data in the OIDS format - which is why there is only one “mapper” in the diagram above. The DOIs, however, require mapping.
It is possible that the OIDS format may eventually be able to do aggregate reporting, but for now it is only geared to transactional reporting.
CI suggested revising the future state diagram (above) to have multiple systems on the left for Carrier P&C - i.e., System 1, System 2, System 3, etc. and then have multiple consumers - some with the OIDS mapping and some without. PA agreed with all of this.
It was decided that the direction for the white paper overall (additional diagrams, structure, etc.) will be worked out in the Thursday meeting (Thu. 11/21).
It was also re-stressed that with the Current State, each carrier system on a major carrier would be doing all of these steps. It was stressed that the following diagram - as byzantine as it is - happens for every single one of the use cases. CI suggested that thumbnails could be used - i.e., this happens for one system, but when you have multiple systems this has to be replicated an exponential number of timess
It was also stressed that the ROI in efficiency and cost savings of moving from the current to the future state system is incalculable. In the future state, we just have customization on the consumer site and only in those cases where someone will not take the default OIDS format.
Ideally, it would be helpful to calculate the number of man hours spent on the current process, especially for multiple use cases.
Action Items
Peter Antley: Revise the Current State diagram to draw out and reinforce the redundancy, excess work and temporal waste of the Current State model.
Peter Antley: Revise the Future State diagram - per Cory’s suggestion - by having multiple systems on the left for Carrier P&C - i.e., System 1, System 2, System 3, etc.; and then having multiple consumers - some with the OIDS mapping and some without.
Group: Plan to work out the overall structure and included diagrams of the white paper on Thu. 11/21.