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/ankbNIz2
...
A. Consumption layer - recap on GB mtg
- Value prop 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 layerWrt Gb Meeting comment about pulling all of vehicles of a certain type: how . 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 and sufficiently relational, one can ask numerous questions that differ from original query as long as data is sufficiently deep?KS: each one of the "slices 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 depth 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 rep , 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: This notwithstanding some of the reports break down very far - so 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 where data gets too at what point the data becomes too granular to come out - i.e., where line is.?
- SC: the issue with territory: it is inconsistent among carriers.
- JM: what What can we say to carriers to get 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 I 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 enough of a sufficient value proposition to for buy-in?
- DH: Probably not - since most of the data calls are state regulator-requested. Most . 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 to them, but what people are interested in: when there is a brand new call, what are people are asking for because it might ? Because this might point to a new public policy of which there is limited awareness.
- PNG: It might be a question of whether individual requests can replace Iso requests and save costs.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 - one of arguments - 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 others 300 smaller carriers can see it?
- KS & DH: what is the value proposition for the larger carriers? (Not the small ones).
- DH: Not (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 but likely 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: made an 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?
II. Job - what does it mean to load HDS and what happens when it fails?
...