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
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 prop to carriers. Some discussion around this re: OSS and consumption of data by carriers and regulators.
- Clarification wrt vision for consumption layer
- Wrt Gb Meeting comment about pulling all of vehicles of a certain type: how slice and diceable should the results be to accommodate regulator requests? This used to be highly doable late 90s/early 2000s. Should we have some mechanism in openIDL platform to do this? Or if someone requests it, should they be able to do it themselves?
- If 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 and dices" is a different request, because requestors want to know up front at beginning what data is being used for. Also: sufficient depth to do slice and dice would be deeper than what carriers want to share?
- KS: Carrier side transactional premiums and claims rep a sufficient depth. 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 we need to ask where data gets too granular to come out - i.e., where line is.
- JM: what can we say to carriers to get them more involved? 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 have the right to see aggregate data from other carriers, is this enough of a value proposition to buy in?
- DH: Probably not - since most of the data calls are state regulator requested. Most of calls done are recurring, so little utility to them, but people are interested when there is a new call what people are asking for because it 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.
- JM: The concern: the data that leaves the system/firewall is where the value proposition is - one of arguments is: if we are a contributor, we get to see data. Is this valuable? And how likely is a carrier to let one see that? 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.
- JM: Question: even with threshold in place, why would a large carrier share data so that others can see it?
- KS & DH: what is the value proposition for the larger carriers? (Not the small ones).
- DH: Not so much value to the big carriers but likely in future when regulators' questions are posed more accurately and efficiently?
- SC: made an argument for large-scaled efficiency (clarity on what is being looked for repeatedly) ahead of ad hoc data calls
II. Job - what does it mean to load HDS and what happens when it fails?
| Time | Item | Who | Notes |
|---|---|---|---|