Date
Attendees
...
RRDMWG OpenIDL is inviting you to a scheduled Zoom meeting.
Join Zoom Meeting
https://zoom.us/j/
...
95368716559?pwd=
...
VjJYcnVTNDNJM3pVWFZEMXlma1pEQT09
Meeting ID:
...
953 6871 6559
Passcode:
...
211245
One tap mobile
+
...
19292056099,,
...
95368716559# US (
...
New York)
+
...
13017158592,,
...
95368716559# US (
...
Washington DC)
Dial by your location
...
+1 929 205 6099 US (New York)
+1 301 715 8592 US (Washington DC)
+1 305 224 1968 US
+1 309 205 3325 US
+1 312 626 6799 US (Chicago)
+1 646 931 3860 US
+1 507 473 4847 US
+1 564 217 2000 US
+1 669 444 9171 US
+1 669 900 6833 US (San Jose)
...
+1 689 278 1000 US
+1 719 359 4580 US
+1 253 205 0468 US
+1 253 215 8782 US (Tacoma)
...
+1 346 248 7799 US (Houston)
...
+1
...
360 209 5623 US
+1 386 347 5053 US
888 788 0099 US Toll-free
...
877 853 5247 US Toll-free
Meeting ID:
...
953 6871 6559
Find your local number:
...
https://zoom.us/u/
...
Minutes
...
ankbNIz2
Jenny Tornquist
Lori Dreaver Munn (Deactivated)
Michael Payne
Matt Hinds-Aldrich
Kevin Petruzielo
Reggie Scarpa
Kristian Farner
Mike Nurse
Patti Norton-Gatto
Joseph Nibert
Minutes
Discussion items
I. James Madison discussion
A. Consumption layer - recap on GB mtg
- Value proposition to carriers. Some discussion around this re: OSS and consumption of data by carriers and regulators at the recent in-person GB meeting.
- Clarification wrt vision for consumption layer. Even if we forget the carrier-regulator relationship there is still the matter of consumption of data. What is vision for the consumption layer?
- During the GB meeting, for example, George Bradner referenced wanting to look up all the vehicles that were Hyundais or Kias.
- The model can be derived from the VIN but there is a layer of indirection present.
- This leads to the question: how slice and diceable should the interface be to accommodate requests? If we build out all the Harmonized Data Stores and everyone's model looks the same - and we can fire queries against them and produce results, the results get aggregated to a specific place, and we want to be able to do something with them. We may have to tweak the requests multiple times - this reiteration is common.
- This used to be highly doable 35+ years ago - then in the late 90s people began to add business intelligence tools to it. So this has been done.
- Should we have some mechanism in openIDL platform to be able to slice and dice data? Or if someone requests it, they can have the data set but will need to take it apart themselves, and if so what role would be doing this?
- If the data is structured correctly to be sufficiently relational and is consumed by a tool that knows how to navigate the structure (e.g., Tableau Click), it is theoretically possible to slice/dice data to answer questions that weren't the original query as long as the data is sufficiently deep? Is this one of the value propositions?
B. Group thoughts on this
- KS: Each one of the "slice and dices" is a different request, because requestors want to know up front at beginning what data is being used for. Also: sufficient structure to do this sort of slice and dice would be deeper than what carriers want to share? This would basically mean a transactional-level depth, and that wasn't the original intention. Intent was rather to obfuscate carriers and details in the individual reports.
- JB: Key question: what level of detail is necessary on the carrier side to respond to different queries.
- KS: Carrier side transactional premiums and claims, in the beginning, should constitute a sufficient depth. In other words, as one does a new data call, one adds to what is in the Harmonized Data Store.
- Carriers have extreme depth, but also veto power to refuse to share a specific level of data.
- PA: Challenging this a bit - wrt the auto covg report, which breaks down KPIs on a per state level. But auto territory report breaks it down to much smaller in state regions - not a transactional level but broken down enough to be able to do intelligent business level analysis. So we need to ask at what point the data becomes too granular to come out?
- SC: the issue with territory: it is inconsistent among carriers.
- JM: What can we say to carriers to start getting them more involved? Some marginal win exists around operational efficiency - because we can do some data calls without re-asking. Discussion concerns idea that if we've contributed to a data set, we have a right to that data set. Is this a high enough value proposition to help sell it? If we have the right to see aggregate data from other carriers, and given a sufficient safety threshold, and if we can see enough of the data calls, is this a sufficient value proposition for buy-in?
- DH: Probably not - since most of the data calls are state regulator-requested. There is very little interest internally.
- SC: The sale isn't that we want to buy it back, but rather that if the data calls can be done through openIDL, this represents a 'win.' (Dale agreed - if someone is doing extraction pattern and formatting for the carriers, that is of carrier value).
- DH: Most of calls done are recurring, so these in themselves are of little utility, but what people are interested in: when a brand new call, what are people asking for? Because this might point to a new public policy of which there is limited awareness.
- PNG: her management less concerned with the data call itself than if the data call in the generalized population could replace things they are purchasing from ISO today regarding lost cost today.
- MN: this is touchy because many carriers do not want to share this type of information. And this means getting really granular wrt how we look at a company's data.
- SC: Many of the fields are not required by AAIS today so they don't have it.
- MN: The issue with ISO - they went from a non-profit to a for-profit. (SC pointed out that the carriers let that happen but have since learned better - they would never vote for it now). MP agreed: as open source, openIDL will never become for profit, i.e., ISO 2.0
- JM: The concern: the data that leaves the system/firewall is where the value proposition is - i.e., the aggregation and use of data - that can be used to sell carriers, because they won't adopt openIDL without a business case. Will play out like this:
- Data sets are issued
- Intrinsic understanding that there is no an operational lift in not having to do traditional data calls and stat filings any longer - although data will need to be restructured to go into HDS.
- One of arguments, however is: if we are a contributor, we get to see all the data sets to which we've contributed. Is this a value proposition? Likely not. And how likely is a carrier to let one see the data? These calls tend to be one-off and it is easier for regulators - both of these undermine business case.
- PA: Some of smaller carriers would likely be into getting more data and attaining greater visibility - this means value and corresponding business cases.
- DH: one of Travelers' reasons for wanting to move to AAIS is a desire to protect their intellectual property - they don't want others learning from their data; this is a competitive advantage of theirs.
- JM: Question: even with that threshold in place, why would a large carrier share data so that 300 smaller carriers can see it? (Competition, etc.)
- JB: This is why it is critical to pull in many more carriers - to increase critical mass. Much of it depends on varied products, lines, coverage, etc.
- DH: Disinterested in putting Travelers' data out there so that someone can compile industry-wide loss costs. Not so much value to the big carriers vis-a-vis the small ones but perhaps in future when regulators' questions are posed more accurately and efficiently? Having trouble seeing value even for regulators.
- SC: Perceived openIDL from the beginning - from a carrier perspective - as almost an intermediary with the regulators. When buzzwords or requests arise across industry, it prompts the desire for add'l ad hoc data calls from regulators - "I want to know about X," carriers respond, "this is what you're after, tell me what you're looking for and we'll figure out what makes sense," also giving the same data to different states. So ultimately, states will be looking at consistent useful data and that will make it more streamlined for carriers. (An argument for large-scaled efficiency (clarity on what is being looked for repeatedly) ahead of ad hoc data calls)
- PA: if we were to assign multiple additional carriers beyond the first two - at what percentage of the full pie do the aggregates become interesting to the first two carriers? JM: rephrased it - if there are 50 carriers on the network and a carrier is guaranteed that its data e.g. won't be more than 5%, and the threshold is set to 20 - i.e., unless 20 carriers have contributed and your data is less than 10% of the set, you're "safe." Of all the calls in the last 12 months that fall within this threshold, what % approx would you say "I would love to see the data set from all the other carriers"?
- DH: 5%
- KP: 5% - Majority of data calls are routine year over year, of little intrinsic interest. Ad hoc calls are of greater interest, such as the hurricane data related to Fort Myers.
- MN: More interested in companies having AAIS support them (the Hartford) and being able to answer requests that are incoming from the various states.
- KS: Does the first use case warrant all the cost? In other words, can you do data calls just because you're doing stat reporting?
- SC: Original proposition: we are starting with basic stat and adding additional fields to accommodate ad hoc requests as they arise.
- DH: it would make sense to have a basic consistent report across the network for the regulators.
- JM: quantifiably how many ad hocs do we get compared to standard data calls? 2x? 5x?
- DH - around 5%.
- JM: how important are these?
- DH and KP: Very.
- SC: The issue with the ad hoc requests is the timing - so x party might say "I want this hurricane data in a month" - very difficult to turn around through normal means (i.e., without openIDL).
- MP: Other issue with the ad hoc calls: even if the fields are common and consistent, claims identification can be a challenge. ("These are the claims that are part of that cap")
- KS: All of the carriers would also have to produce the data immediately even if they don't regularly do that to get the value out of it - unless it were added to HDS and loaded on time.
- JM: Can we make a strong enough business case for the regulators that they start pushing it, and scare the carriers into compliance? E.g., you must provide sufficient data that we can ask 15 questions in an hour?
- KS: Regulators don't ask some questions because they are sensitive to the cost to carriers and don't want to upset them.
- SC: NAIC meets monthly - all regulators want this data quicker (#1) and voted and all four stat agents agreed that on auto data they would get all the information in e.g., Dec '22 instead of Mar. '23. However this has been discussed for a long time and they are only getting two elements three months earlier. openIDL represents an outstanding solution.
- LM: Even with the pending updates to the stat handbook, the data will still be old.
- JM: the speed and efficiency need to be communicated more clearly to the regulators, i.e., openIDL as a dynamic solution. It needs to be communicated that the requests are not unreasonable or unrealistic.
- MN: this may necessitate internal modifications - an expansion of the capability of what openIDL can provide.
- JM: Bottom line: what if the value proposition for carriers is really hard to make? And what if the value propositions for the regulators (7-8 hurdles) and the right amount of authority from the regulators might get us where we need to be?
- KS: If the regulators know we can do more, the value proposition to the carriers is that they have a way to actually do it more easily and readily and frequently.
II. Job - what does it mean to load HDS and what happens when it fails?
A. PA - Looking at GT2
- PA to JM: Originally doing ETL/load and Javascript to decode unload. GT2 loads into a single table and a normal database, so they will use reference tools and a materialized view to decode. Thinking it makes sense to use surrogate keys to keep the codes separate from the IDs. Any significant red flags?
- JM: No major red flags - all sounds solid
- PA: will dive deeper into this in the AWG on Monday.
| View file | ||||
|---|---|---|---|---|
|
| Time | Item | Who | Notes |
|---|---|---|---|
Action items
...