6/7/2022 HDS Task Force Meeting

Date

07 Jun 2022

Antitrust Policy

Attendees

• Sean Bohan (openIDL)
• Peter Antley (AAIS)
• Dale Harris (Travelers)
• Jeff Braswell (openIDL)
• Allen Thompson (Hanover)
• Brian Hoffman (Travelers)
• George Bradner (CT)
• Greg Williams (AAIS)
• Ken Sayers (AAIS)
• Megan Ebling (AAIS)
• Truman Esmond (AAIS)
• Rajesh Sanjeevi (Chainyard)
• Nathan Southern (openIDL)
• Joan Zerkovich (AAIS)
• Tsvetan (Senofi)

Agenda:

1. Continuing Discussion of Requirements from Architecture WG Call 6/6/2022

Action items

Notes: 

Dale's Requirements Spreadsheet V2 (picking up with d.11)

• d.11 data model standarfs will foster effective and eficient data extractions such that queries can be satisfied within 24 hours of committment to participate in an information request
• Dale - performance metric
• design of DB may influence how long it takes to get answers
• 24 hours seems reasonable, not looking for immediate
• Satish - max 24 hours
• George - for when a request is made for info, what about turnaround time on stat reporting
• Dale - not delivering final report, but extract info from ind carrier nodes
• George - we would say "stat info for all companies in CT"
• Peter - execution of query would equal less than 24 hours to run
• talking about keeping data, prior month + 45 days (45 days after the close of a month)
• George - makes sense
• Peter - access to quicker info, info that fresh can't be reconciled against NAIC reconiciliation until it is done
• doing everything we can to keep data as correct as possible at all times as it is loaded
• if we find error in the load will immediately move to correct it
• available and up to date
• Satish - is it 24 hours after consent?
• Dale - in my mind it is execution time
• Staish - digg req - is there a time limit after a request? 
• Dale - it is coming
• Ken - specification of standards, can get to it later - quality rules include the fields expected, format, etc
• what the reqs of the standard are (data model standard)
• Satish - how do we make sure, flesh this out - lot in this requirement
• d.12 - changes in NAIC required fields to the openIDL data model will require a minimum of 18 months notice for carriers to confirm
• Ken - just NAIC? what about new fields/data
• Dale - req fields day 1, all other fields at option of the carrier
• Ken - carriers not be able to respond to new kinds of data in less than 18 months, not just nAIC
• Dale - if not required a carrier may decide never to populate it
• required they have to conform
• basic time limit to make that happen
• Ken - do we want to put a finer point on comform?
• ready to consent to extraction patterns that inc this new data?
• Dale - yes, in HDS at that point
• Peter - data must be avail in HDS
• Ken - able to respond to that request for that data
• Jeff - 18 months seems like a long time between possible revisions of the data model -- should it not be based on what is required to make the change, after consultation ?
• Brian - yes, carriers need to reconcile the new request in order to respond
• Jeff - should it take that long? not a fixed time period, understandable a lot of data might be required for some?
• Dale - edit it for "new fields"?
• Jeff - agree when new fields are proposed, "will take us this long" respnse to timing of the change vs "it cant happen"
• Brian - biased by the past so when something comes through, tends to be 18 months - but going from SIC to NAIC, maybe do a translation table, etc.
• we want to future proof this and see it do other things, look a little forward
• Jeff - instead of arb time period "future changes to the model will have reasonable efforts..."
• Peter - would you see changes that happen mid-year?
• doesn't think 18 mos is too bad
• Dale - 18 is long but 2 is impossible to achieve
• Jeff - arb fixed number not appropriate - shorter term inquiry, might be useful and impelmentable in 3 or 6 months might be inappropriate
• Dale - for "not required" a carrier may choose to put nothing in there
• if dont want to participate wont put data into HDS, only those fields required
• needs to be consensus - any company can object
• Jeff - reqs wont come from a party, but a regulator might say 
• George - cant speak for NAIC - put a hard fast # in there like 18 months, if we had a data call after a hurricane, and we say "we need this info" and carriers said "we need 18 mos" it would not be acceptabole
• need some NAIC folks on what a brand new data field request, never been asked for before
• not sure NAIC's expectations today 
• Brian - other thing to consider - lets say regulator asks for "capture residential properties with undeground electrical lines" state wants, NAIC agrees
• if we are reporitn gon quarterly or monthly basis, we can capture it
• is that somethign we would say "ok, need 6 months to build infrastrucree"
• Dale - as soon as we have info avail, dont want timeframes too compressed to get there
• if there is a hurricane that comes, dont have info in openIDL, would give info anyway DIRECTLY
• George - would prefer it comes thru openIDL, make request, standard report right now that nAIC uses for disaster
• wish Sandra Darby was on this call
• her input on stat reporting
• maybe a sep meeting to talk about it
• issue havving now - waiting 18 months to get info on automobile
• if we want to gather info, NAIC gets report and we are waiting almost 2 years
• that is unacceptable in this day and age, having data that old, not being able to get current year info
• if I wanted 2021 info, I should be able to go and get it, not wait 18 months
• Dale - 18 mos is NEW data fields, data will be current to prior month +45 days
• Peter - encouraging people to get data in as soon as possible
• George - maybe see if we can get together with Sandra Darby and NAIC to make sure - a brand new data element it would be reasonable for a company to take some time
• Peter - bring this up on Friday call
• Dale - all reqs go before regulators
• Truman - regulator requirements somewhere else
• George - we need agreement
• Truman - some are nonstarters outside of trad stat reporting
• not requs, parameters for something
• Dale - view these for all reg reporting, not just stat reporting
• TRruman - all data calls, 
• Jeff - reasonable conservative timeframe - change management of the data model for stability reasons
• Truman - whoever hosts a node can put whatever they want in the HDS, to the degree a query that wants answers from that carrier, is the data good enough to respond to the question
• can it respond
• Jeff - limiting to what are the minimal required elements of the data model
• Joan - these reqs are for RR because data quality will require min standards this team is working on
• anything they want in a repository
• whqat would be first minimum viable set
• quality, timeliness
• all what regs need to trust this data in the timeliness george is articulating
• need data and in more timely fashion
• timeliness related to quality
• yes for RR
• will get to next pahse, but unless there are standards will be minimally useful
• Brian - great point, once data is in the HDS, somehow query it, lot that you see when you think of a catastrophe where you will get insight even with stat data
• and then when yuo do need more we move forward
• gheorge - id like more info re our property book proximity to coast, deductibles
• did a study 5-6 years ago - very painful
• Joan - one of the things, like what i am hearing here, talking about things the standards group deals with, as stat reporter deal with, bring industry together, mult stat agents w/o common standard
• prob for regs and carriers
• if we can put data in a node, just stat data, your catastrophe call can be answered, but to answer questions quickly need data in repo, right format, at quality
• sync up data across all carriers
• George - looking at homeowner book of biz, getting excel spreadsheets, look and find issue in thousands of cells, excruciatingly painful
• IR.1 request for info shall be specific in detail and communicated thru secure protocol
• Dale - smart contract but beyond smart contract - req for info, data call or stat reporting, request needs to be specific and the key word is "secure protocol" - blockchain, hashtags, whatever
• Brian - effectiveness, efficiency, thinking about data call, when George or any regulator sends request, it is painful the routes it has to take, some regs and companies goes thru specific email address and then there is the interpretation of it
• secured protocol - diff look to it, whole idea is effective and efficient
• Satish - what does speific mean - defined criteria
• Dale - they are coming
• make it specific and actionable - if we have what those criteria are
• Dale - lets not filter on just 6/1s, all gory details
• Ken - always asking - just what the reg puts in text vs what is executable - found that thinking about that is important and then thinking implementation - requirements around a minimum of carriers need to confirm this is doing what it says it does
• where I get stuck with these reqs
• should we have diff section
• Dale - view this as the ask
• should be another piece - implementation of the ask
• George - ask going to be on the data standards as defined in most cases?
• Ken - what access and then what do with it
• i am going to access these pieces of data (VIN, coverages, zip codes) - the whole data call - THEN someone has to implement
• Dale - example: Hurricane, coonecticut, all properties in New London Cty - thats the ask, using the data in the HDS
• ask has to be specific (thing, where, what, timeframe, etc.)
• Joan - hurricanes, cty - total insured by carrier - total impact in the cty
• context of asking different question
• regs want to know "total insured is" - all 100 carriers provide a single number
• sending a lot of data into regs
• lot of questions
• reqs for HDS, ask carriers "what is the financial health before it hits" then Hurricane changes course and need it for another cty
• after hurricane, want diff questions about what happened
• some experience, hurricanes, or fire in CO, questions before, during and after
• less aabout having all the data in the HDS, more about answering specific questions before and after event
• Dale - ask needs to be defined
• not looking to flood world with data
• IR.2 forum shall be established for carriers and regs to discuss and agree to intent and interpretatiojn of information request where needed
• IR.3 request for info shall be for aggregated info only, no individual policy, claim or personally identified information shall be requested or honored
• Peter - ND Uninsured Motorist - working with VINs, do they count as PII?
• Dale - no
• Jeff - VINS not aggregated
• Satish - if the carrier creates an agg based on a data call and the agg is extracted and pushed - do you ever need details on HOW aggregation was created, do we ever need to drill back
• Dale - George - yes
• George - maybe identify different request 
• quality checking work
• Jeff - what level you request aggregation at
• level of agg in request
• do we need to capture 
• Satish - aggregated but that should be good enough
• Jeff - this req is anonymization, aggregation is one of the measure
• Satish - going from agg to details
• clarification
• data lineage
• Jeff - regulators have ability to go ask whatever they need for a specific case
• may specify second request with less aggregation
• directed more at, look into ti
• good question
• Satish - carrier might have ability give answers to followup questions
• Peter - when we talk to eric about it - A not SOR, if he wanted that he has legislative authority to do that, and talking about striving to keep HDS as up to date as possible
• run query, 2021 auto report, run mult times as data gets updated
• Peter - not everything aggregated
• ND is not part of RR
• ND will send VIN #s from carrier node to analytics node
• same HDS
• Ken - purpose, main drawing potins is it is a per-request consent
• some travelers wont agree to that other carriers might
• seems like this is a broad "thou shall never' but the purpose may make sense 
• Jeff - second level 
• when data sent to analytics node, not just level of data aggregated 
• Dale - my concern - regualtors always have opportunityt ask for specific pilicy, claim, can ask for info on ind policies and claims
• hesitant to have info flow thru openIDL without knowing who can see it
• dont want it going into some pool somewhere, shifted somewhere esle
• Ken - agree and unserstand
• as a requirement
• "you shall know the provenance and the path of the data, part of your requirement for that consent"
• know all the things 
• Dale - design thing - if I turn down data calls george is asking for because going thru analytics node anyone cane see
• if there is a gateway to george...
• Ken - could see situation where George/DOI doing data call just for me, anyone who wants to contrib to that data call would be connected to this analytics node"
• see whree it is going
• Ken - dont assume anyone can see it - not everything into a common pool, kept secure for regulator requests
• data call could say "only doing this" so only DOI of X State, no other companies, etc.
• need to be visible and auditable as well
• Peter - when can we bring these requirements for approval/share in other calls
• Jeff - needs more discusion
• Peter - Friday regulators, earned premium discussion
• Ken - some requirements he would like to put into the document

Recording: