Open Insurance Data Standard White Paper Work Group - 2/20/25

Attendees

James Bamberger

Sean Bohan

Jeff Braswell

Amanda Brine

Rob Clark

Josh Hershman

Cory Isaacson

Andy Mielke

Lanaya Nelson

Michael Payne

Mike Puchner

Andrew Regis

Ken Sayers

Michael Schwabrow

Nathan Southern

Michael Sullivan

Jennifer Tornquist

Greg Williams

Opening Logistics

Sean Bohan (SB) opened the meeting, welcomed everyone and read the Linux Foundation Anti-Trust policy

Discussion

Linux Foundation Antitrust and Code of Conduct were shared with the community on the call.

A broad consensus from the group that the paper overall is close to completion, but needs some additional tweaking/editing/polishing.

The bulk of the session today focused exclusively on recent revisions to the OIDS white paper. Josh Hershman (JH) emphasized that for all the questions left unanswered at the beginning of this call, each stakeholder should go back to his or her organization and think through those matters/work them out/report back for the next iteration of the meeting.

The following high level points were made/revisions recommended with regard to specific content:

New content: Ken Sayers (KS) contributed the abstract, which was written impromptu and instinctively - this needs to be reviewed in meeting by the group

KS: The purpose of this section: answering for readers, Why do I want to read this document? I have this problem, this paper is going to help me solve it, etc. CI and JT responded highly favorably to this section
JH: In this section, the use of ‘another company’ in ‘share data with another company’ should be modified to ‘…another third party/organization’ and ‘allow that vendor’ should be modified to ‘allow that third party/organization' - the logic being that this captures more potential use cases.

KS also changed the basic titles in the document to actual headers (title1, title2, title3, etc.) to facilitate navigation throughout the paper. In the process, the numbering was removed

SB: It is not issue for the numbers to be removed at this point, because section editors serve the same purpose
We can return numbers in the final version, on the last pass through the document (See action items below)

For the introduction, Lanaya Nelson (LN) offered a suggested rewrite of the introduction, written as follows:

“In the P&C insurance industry, the needed effective and secure data exchange among carriers, reinsurers, brokers, regulators, data providers/third-party vendors, and for cross-industry applications has not yielded a successful, trusted mechanism. Data exchange transformation is essential to meeting the industry’s needs of smooth business functionality, operations, and insights accuracy, risk management, and regulatory compliance. The exchange mechanism is also essential to successfully matching the rate of global emerging technology advancements and their commercialization. The success of this transformation will also have a significant impact on our economy at large. Traditionally, proprietary data formats are used for industry data exchange. The stronghold of and reliance on these proprietary systems has limited needed innovation and resulted in loss of data control and ownership, fragmented data, high integration costs, and barriers to scalability. Non-proprietary and open industry standards present a solution to these challenges, offering a universally accepted, low-cost, secure, and flexible means of sharing data across diverse systems and stakeholders. Open standards are publicly available specifications for data formats, communication protocols, and methodologies that promote interoperability and relieve the industry of requiried, ongoing licensing fees or intellectual property royalties. This paper investigates the specific benefits of adopting such standards in the P&C insurance industry, focusing on how an open platform addresses the limitations of proprietary data formats while driving innovation and cost savings.”

JT proposed, in meeting, that attendees read this alternate introduction and provide live feedback.
JT responded favorably to it
LN stressed that she didn’t write this from whole cloth, but worked from the preexisting introduction and revised it as needed - so it has many elements/pieces of content from the prior version.
KS suggested that attendees take time over the following week to review this new optional intro, and circle back to the group in the meeting on 2/27.

Ken Sayers - Diagram Revisions

KS felt that the diagrams were overdone for the amount of information present in the paper, and revised them to make them more concise.
KS also heavily revised the descriptive text at the beginning of the diagrams to explain and dissect the (deliberately messy/confusing/chaotic) current state diagram. The text reads as follows, now:

Each time organizations need to share data, they must agree on a format. This format has a syntax and a semantic. The syntax defines the technical language used which might be JSON, Excel, CSV, Flat File and the field names. The semantic defines the meaning of the data. This includes the definition for codes, specific coverage names etc. Both of these require considerable thought to get right. If each time a new connection is made, we use a new format, we must reestablish the syntax and semantic. Here are some situations that create new connections:

-A Company submits statistical data to statistical agent A

-A Company submits statistical data to statistical agent B

-A Company reports loss data to reinsurer A

-A Company reports loss data to reinsurer B

-A Company responds to a data call for DOI A

-A Company responds to a data call for DOI B

The Company must deliver data in many different formats. If we add more DOIs, more Data Calls, more Reinsurers, more Stat Agents, we see an explosion of formats. Each format requires time and effort to define the syntax and semantic. The idea is that this all leads to an explosion of different connections (and by extension, much greater time and cost) - and supports the messy current state diagram very well.

CI suggestion on top of this: consolidate several diagrams for individual transmissions reflecting different party-to-party connections, syntaxes, formats, alongside the current state diagram. The goal is to make it scarier. We now have three diagrams. Cory’s suggestion:
- One diagram showing carrier A and all the things it has to deal with
- Two additional diagrams for inbound and outbound
- Current state ‘explosion’ diagram - can stay as is.

Overall Goals: Finishing the White Paper by the next OIDS meeting 2/27 - the end of February. Next step will be determining who is a part of the next phase of this: the Standards Working Group.

The Limitations and Risks of Proprietary Data Formats (4) and Benefits of Open Standards

KS has already gone through these already and vetted them
Lanaya’s comment on the side about adding security and accuracy (made alongside this section) needs to be reviewed

Reduced Costs Through Royalty-Free Licensing

LN has a comment on the side of this section that needs to be considered and possibly incorporated into the paper

Easier Regulatory Compliance

For now, KS just placed some bullets in this section to earmark pros/benefits on a high level - wasn’t yet ready to incorporate pros into the full text - this is forthcoming.
One of the insights gained from the state Departments of Insurance is the insight that they do not create data calls because it’s such a burden on the carriers. There is an opportunity cost here. From a DOI’s perspective, regulations are a burden because the data is poor, and the data is poor because it’s difficult to obtain. This information needs to be incorporated into the white paper.
JT: On a side note tangentially related to the white paper: NAIC is revamping its statistical handbook for the first time in 15 years - so this represents/embodies a wonderful opportunity (and the openIDL team has NAIC contacts). NAIC - multiple working groups. One is the Statistical Data Working Group; they will be rolling out a new initiative to streamline and modernize regulatory processes in the industry. This represents a wonderful opportunity for the IDL project.

Sections 2.5-2.8

2.5-2.7 have been revamped, reworked and edited by Lanaya
Section 2.8 per LN is critically important in terms of content
SB’s comment about future proofing in section 2.5 also critical - a solid reflection on the power and ubiquity of open source, open governance and scalability.
LN would like to add another subsection here that is exclusively about open governance and that touches on the Linux Foundation as well (See action items, below)
A discussion ensued here - per Sean and Ken - about the criticality of futureproofing what we’re doing and emphasizing this in these sections of the paper - particularly in light of some of the healthy skepticism in the insurance industry. Per Lanaya: this points to the usefulness of including a section on The Linux Foundation and its open governance model.

Section 3 - Rob Clark - Cloverleaf

3.1 is the Core Model - he covered the core - all lines of business for P&C - then mentioned that it has to be extensible, then explains what extensibility is
Numerous additional related subtopics covered here, but it needs to be interwoven into the rest of the document.
However, it was pointed out that this section is, by necessity, long and detailed as it represents the core material of the document.

Section 4 - An Evolving Standard

Jeff Braswell (JB) authored this section - on code licensing vs. specifications licensing
JB’s comments in the sidebar - on permissions, patent rights and IP considerations around some of the different licenses. However, these comments are only for background information; they don’t necessarily need to be incorporated into the document itself.

Section 5 - Learning More about openIDS

This section will largely include links for the white paper community.
Calls, meeting, Github, how to get involved
An effort to get people active and give them things to do.

Section 7 - Conclusion

This section of the document still needs to be tightened up (see action items, below)

JT: Stressed that most of the content is present in the paper but may need to be structurally overhauled and re-ordered. Also stressed that once edits and restructuring are done, everyone should reread the paper to get an overall sense of its flow, cohesion, strengths, any weaknesses that need to be resolved, etc.

The next openIDS meeting will take place on Thursday, Feb. 27th

Links

Action Items

Work Group Participants:

At the OIDS meeting on Thursday 2/27, participants should be prepared to discuss how they feel about each of the unresolved matters in the paper and the group can weigh in on the points, one by one.
Take the following week 2/20-2/27 to review Lanaya’s new proposed introduction to the document (in comments) and be prepared to weigh in on it during the 2/27 meeting.
Finalize the document by the end of February (2/27)
Once all edits are done and structural reorganization has been made in paper, read through the whole document ‘soup to nuts’ to get a sense of the overarching paper and call out any last minute edits or changes.

Ken Sayers:

Per Josh Hershman’s suggestion - and to redress the fact that the white paper was written by numerous individuals and therefore stitches together different styles, run the whole whitepaper through AAIS marketing team, once the bulk of the work in the body is done, for checks on punctuation, flow and consistency. Try using ChatGPT or Grammarly - and per Rob Clark’s suggestion, make sure the material is cohesive sans overlap.
Clean up the diagrams per Cory’s suggestions.
Review Lanaya’s side comment about adding security and accuracy to the document (alongside lack of interoperability/high costs) and consider incorporating this material into the document.
Review Lanaya’s suggested addition to paper in the comment feed next to Reduced Costs Through Royalty-Free Licensing. Evaluate and consider incorporating this suggestion.
Under the section ‘Easier Regulatory Compliance’: flesh out pros by interpolating the bullet points into the narrative, and also incorporate related insights about why state DOIs don’t generally do data calls. It should include the argument that we’ll have better regulation born out of better data.
Review Lanaya’s suggested additions to paper in comments alongside sections 2.5-2.8 of the white paper and consider incorporating this material.
Review Cloverleaf contributions in Section 3 and interweave into material throughout remainder of the document.
Announce to group when done with edits.

Lanaya Nelson:

Take the basic unanswered questions in this meeting and distill them into a list. Circulate to group.
Take the diagram in the white paper beneath The Benefits of Open Standards for Data Exchange and animate it - place it in lieu of the current animated diagram on the OIDS page (redirect) of the openIDL website - per Ken’s request
Change ‘OIDS’ to ‘openIDS’ throughout all content (including white paper) per Jenny’s request.
Add a section to the paper (2.9?) about open governance and The Linux Foundation - while bearing in mind that the audience will likely already be familiar with The Linux Foundation. Stress - per Ken - how this is different than what they’ve seen in the past, such as ACORD.
Tighten up conclusion (Section 7 of document) working with Josh’s suggestions - and overhauling Peter’s WIP text; combine the two into a revised, fluid whole. Make sure tone is consistent; consider incorporating Werner Kruck’s paper (Problem for the Industry) content.
Announce to group when done with edits.

AAIS Team: Once content in document is done and polished, take a pass back through the paper and re-add numeric identifiers to sections.

Sean Bohan

Take another editing pass at section 4 about licensing specifications (Apache 2.0 et. al.)
Resolve your comment from 1/29 about extensions to the core.