PeterA gave an update on HDS Task Force and RRDMWG Calls
Jeff brought up amending the agenda for this call
categories of stakeholders
Truman - agrees updating the format of the call
Peter - lot of stuff from 6/1 - would not be in the last version
Dale - 5/23 - items in the original, 6/1 new items
filter C look at 6/1
information request - 4 sections
data and data integrity
information request
access and security
listened 2 weeks ago and deciphering what he was thinking
one item
timing
in information request → in terms of timing, the info being sought needs to be timebound
calendar year 2022, specifically spelled out vs it being "everything in all data"
need a beginning and endpoint in the extraction
Jeff - format is good
Satish - lets go over 6/1
d.2 openIDL data model standards shall exist for all P&C lines of business except workers comp
Peter - interesting - starting out doing one, what does saying "all except"
Dale - dont want to stop at auto and homeowners
all or nothing
Peter - all lines? list them out? order/prioritize
would help with the roadmap
Dale - as we design/build needs to be robust to cover all lines
Satish - commercial lines more complicated (esp property, auto)
need to list those out
have seen data models for commercial auto, property - can get convoluted
Truman - straightforward re: stat reporting
could be more to use it in a more robust way (rate-making,, etc.) but regulatory and stat reporting
auto is the bulk of the lift (output v input)
Dale - most calls multi line and Personal and Commercial
Truman - each of those should be covered, model & Arch of what an org will use it for
Satish - begs a question - only for domestic policies? International?
US BAsed carriers could be underwriting international buisiness as well
Brian -domestic business
Dale - domenstic for now, if we expand internationally it is a day 2 or 3
Satish - any more open questions on this requirement
d.7 All Data COntained in Carrier Data Store is owned and controlled by that carrier
Jeff - context?
Ken - are we taling about HDS or openIDL-visible?
covers a lot of ground
just data stores visible to openIDL?
Dale - wants getting into solutioning, HDS is the solution, trying to be generic but meant HDS
d.8 data accurate as of point in time and may be corrected over time is the errors in the transmission of data occurs with no obligation to restate prior uses of data
Dale - if transmission error, will go in and fix it when/if they find it
not going to restate or maintain a history (no transactions created) - its a transmission error - will fix when find out it is "in error" not expecting to have to restate all past data calls to restate what was in error
hearken back to what EricL was saying, Laura from Maine - data will be updated over time, pulling something on Jan 1 vs Jan 3
Ken - related ? - we basically said if a report goes out and data is fixed, we can't reproduce that report
Dale - correct - wouldn't be able to correct to source but able to recreate based on analutics data to the extent that what is allowed is archived
deleted soon as you created your aggregations
Ken - if we have to repro a report from this data or not?
cant rerun reports if we change the source - can re-run but wont get same numbers
explaining whu when regs ask "why is this different?"
jeff - small error, fixed, no material impact on a large report
ken - could be huge, couple zeros
Brian - what is a scenario where there may need to be something that big where we run it to restate
doesn't know, curious if others have an idea
Jeff - materiality metric (change by x amount, material connection)
James - scenario where millions put on individual instead of commercial - transmission error
dont find until month ends
James - can change code, rerun numbers
Ken - DOI caught it?
James - had to run a correction
DavidR - if all changes happened on system of record, factored in, would be reflected
if it is done manually or outside of SOR, not reflected but accurate
Ken - want to make sure we dont have to keep the wrong thing around
DavidR - doesn't help to keep the wrong data around
Ken - do we have to notify anyone who might use this data that it has been fixed? "update SOR, re-ran HDS, any report based on old data might be wrong - requirement to notify an error was found
Satish - is there a req where there is a gate, you publish, at some point in time the node says "we approve/accept and then there is no vhange to that data set"
ken - date for data used for the report and a time to go out and can't be changed
Satish - the date of the data call, due date , is what drives acceptance of that data
does the carrier node need to be notified
interested that we determine the data set is good enough after expiration or due date
Ken - black and white - data can change that was used to create report (wronmg for whatever reason)
brian - reserve releases, happens all the time, never go back, normal course, not transactional data, keep coming back to, not changing go forward
Satish - go forward is when data leaves carrier node
"done, not going back"
anything after leaves the carrier node
as accurate as date when you move the data
Ken - anti-requirment - we dont have to notify when things were fixed
David - ever a case where theat happends today? "our policy changed, if you rerun that report again it will be different"
Brian - in 6 months..
David - like balance sheet, different every day but also right every day
Ken - James, that case where you had to fix and run some stuff?
Dale - interested to hear what the regulators might want to say about that requirement
David - could in theory run the report again to see if it evolved
do it now
in theory they could run it again
if they chose
would have to reqiuest again,
not a carrier requirement
how they think it should be
notification - can't define that req
Peter - discuss Friday?
Dale - give them all of these and weigh in on all
Jeff - could have update log/exception log
even if you don't worry about reproccessing data
some log maintained if there was any question
David - starts to get into things we want to avoid - being stateful
11 SOR downstream, might not know every change, right what went wrong with every change, nor woul dwe want to, may have a log with "what changed" but not want to be explicit about that
Jeff - arent most of the additions from SOR to HDS - editions and appending data, updating fireld in previous record?
David - crux - example if premium was $100, was $100, was translated about $1000 in HDS, the fix would not write new record, would change existingf record to $100
see in log change made, but not entry "this data changed because of this"
Jeff - most cases, some type of error - would you do similar updae if you have transx in SOR?
David - faithfully recreates SOR
onset-offset transax? reflexted
if error occurred post SOR, not reflected as sep transax - in-place correction
Jeff - addition of new data, new records, corrections was in fact data processing error
one way to deal with this - log of updates, prob because of error transmission
adding to data store that offset form source
David - can table for HDS - we dont want to ID what writes are new vs what are corrections
could do it - doesnt add value - just say "this is the data, as written, if updated then updated"
dont want to be explict, dont want requirement
one thing - just because a req doesnt mandatwe something doesnt mean an implementation detail cant expand as things evolve
Jeff - no obligation to restate as oposed to things that needed to be done
0.9 openIDL shall maintain an edit packages to be available and be used by carriers to test conformance to data model standards and data point interactions similar to functioning of AAIS SDMA portal
Peter - ETL req or HDS req?
talking about following path of SDMA - checking a data set as being loaded, complies with rules they have
Dale - extraction is too late - if there are errorrs and above 5% tolerance, will try to correct
either pre hds or in hds and weve cert these records have passed eidt and these have not passed edit
as you do extraction, do you use data that has ONLY passed the eidt
edit package that is uniform, maintained buy openIDL that all carriers would use
Ken - generic req
cant require things about the data in there b/c a cert extraction will happen
general purpose data, cant say "only these coverages" could be another as long as it is another coverage that could be there
Jeff - not necc after data was extracted, processed for consenting
Truman - not general purpose data, it is explicity, specific data
Satish - key ? - openIDL will maintain - who takes ownership of the eidt packages and oslutiin coponents - ruls, interfaces, etc.
is openIDL up for this
Ken - specification of rules and implementation of rules
part of the requirement to have that edit backage generic across all. AND Speciric to auto, rules and states
Peter - data should be in HDS unless run past edit package
James - place to put it and publish
ownership od spec and implementation
does openIDL maintain implementation
David - what could work fairly well - whenever you have mult orgs chekcing to a standard with independnent processes, brings inconsistencies
consistently checks across all carriers
if you ask 30 carriers to implement checks get better quality
Dale - more efficiient if owned by one org
Ken - need cert so someone imeplements the rules
David - talking both spec and implementation, if we all impelemtnt the spec could own the
James - Carriers own impelmentation
Jeff -0 couldf be common utility code to maintian HDS
community contributes and maintains
solutiom - in F/OSS
should clarify - this is the specificatioN AND the implementation
Jeff - implementation goes hand in hand with the reques/specs
James - one could argue everyint is a extraction pattern
David - a lot could be built in a similar way
Satish - variation in source/data set
as long as we can extract that
David - bare minimum conmform in a conssitent way
lives with each data model
this part foes not live with the data calls, it lives with the data model otherwise it is too hard
Dale - compamion - openIDL will audit carriers for compliance in maintaining and implementing edit pckage
Ken - obviated that by saying it is owned by openIDL
if we provide spec and impleemntation -
Dale - if I tell you I did it, doesn't mean i did
if you do an audit, independently have these errors
James - accountaibility for running the package
David -could build and never run, getting into governance but has to be defined
Jeff - spec this so it doesn't become a project in and of itself
so checks can be run on commone data, good to have utilityes running off a common model, not the end all
might be needed down the line
not going to be the total sanity check of the system
have some capability for running common sanity checks
James - worth discussing
important line items in the whole thing
Jeff - 80/20 - best you can, once again, fit for purpose for initial uses
not all in one converions
Ken - point of logistics - out of time, great progress great momentum
expand this meeting or tomorrows meeting, nother couple hours
.png?version=1&modificationDate=1654539132992&cacheVersion=1&api=v2&width=444&height=250)