2022-06-06 Architecture WG Meeting Notes

Date

06 Jun 2022

Antitrust Policy

Attendees

• Sean Bohan (openIDL)
• Dale Harris (Travelers)
• Peter Antley (AAIS)
• David Reale (Travelers)
• Brian Hoffman (Travelers)
• James Madison (Hartford)
• Jeff Braswell (openIDL)
• Allen Thompson (Hanover)
• Dhruv Bhatt
• Greg Williams (AAIS)
• Joan Zerkovich (AAIS)
• Ken Sayers (AAIS)
• Megan Ebling (AAIS)
• Rajesh Sanjeevi (Chainyard)
• Satish Kasala (Hartford)
• Truman Esmond (AAIS)
• Tsvetan (Senofi)

Agenda:

1. Report from Architecture WG Harmonized Data Store Task Force (PeterA)
2. Report from RRDMWG WG (PeterA, JeffB)
   1. Notes from this call - thanks Nathan Southern 
3. Future Architecture WG Agendas
   1. 10 min open discussion
   2. Stakeholders:
      1. OpenIDL (network)
      2. Infrastructure partners
      3. Stat Agents/ Analytics providers
      4. Regulators
      5. Carriers
4. Continue discussion - Node Architecture and Requirements (Satish & JeffB)

Documentation:

1. openIDL - Architecture - Member Requirements Files
2. Regulatory Reporting Requirements from Dale H - VERSION 1(Travelers)
3. Regulatory Reporting Requirements from Dale H - VERSION 2 (Travelers)
4. Architecture WG Requirements Table
5. HDS Requirements WIP (JamesM @ Travelers)

Notes: 

• 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 time-bound
• 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 - don't 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 (especially 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 business as well
• Brian -domestic business
• Dale - domestic 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 talking about HDS or openIDL-visible?
• covers a lot of ground
• just data stores visible to openIDL?
• Dale - wants getting into solution-ing, 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 analytics 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 why 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
• don't 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 don't 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 change 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 (wrong 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-requirement - we dont have to notify when things were fixed
• David - ever a case where that happens 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 request 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 reprocessing 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 would we want to, may have a log with "what changed" but not want to be explicit about that
• Jeff - aren't most of the additions from SOR to HDS - editions and appending data, updating field 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 existing 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 update if you have transaction in SOR?
• David - faithfully recreates SOR
• onset-offset transaction? reflected
• if error occurred post SOR, not reflected as sep transaction - 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 don't want to ID what writes are new vs what are corrections
• could do it - doesn't add value - just say "this is the data, as written, if updated then updated"
• don't want to be explict, dont want requirement
• one thing - just because a req doesn't mandate something doesn't mean an implementation detail cant expand as things evolve
• Jeff - no obligation to restate as opposed 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 errors and above 5% tolerance, will try to correct
• either pre HDS or in HDS and we've cert these records have passed Edit and these have not passed edit
• as you do extraction, do you use data that has ONLY passed the Edit
• 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
• Peter - start with .11
• Jeff - agenda items
• ken - wil add them in line
• jeff - further comments 

Recording: