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
