...
Attendees
- Sean Bohan (openIDL)
- Joan Zerkovich
- Ken Sayers
- Eric Lowe (VA)
- Nathan Southern
- Jeff Braswell
- Satish Kasala
- David Reale
- Brian Hoffman
- Greg Williams
- Peter Antley
- Rajesh Sanjeevi
Agenda:
- Architecture WG Harmonized Data Store Task Force
...
Action items
Notes:
- JeffB
- DaleH's document
- great input on aspects of arch requirments
- High level way of looking at the work that might be going forward
- Trad process: network stack, 1 party talking to another at different levels
- division between parties
- division between horizons (business and data)
- below the line - infrastructure implementing this
- definitions and stipulations (matrix)
- looking at requirements on the contributing side
- carrier node
- influence, impact on lower levels
- take a look, great contribution
- when Dale discussed last week, concept of granting consent to a data call
- orchestrated workflow transactions
- might be over thr course of days
- data call req announced, on carrier side can it be provided, consent, other data? in aggregate not just one carriers business dominating the data
- business orchestration transacting at app level
- impact on how we implement in fabric
- good example, kind of req that will impact arch
- making dsure on this call, work contributed
- KenS
- worth going thru it
- give folks a sense of what was contributed, see the value of it, restate what is not clear
- can walk thru it
- Dale - organized it - what are the diff things that need to happen for stat reporting on openIDL
- Reading column D
- D4
- DavidR - transactions will be determined by source system
- any changes to this source will be reflected in HDS
- Ken - can we clarify it?
- Satish - are we saying HDS will maintain time series on the polcy AND the claim?
- Ken - yes, changes as they happen based on what source system says
- diff - if there is an error moving from source system to HDS, will not correct errors will replace (no onset-offset)
- Satish - only incremental or delta change?
- Ken - cant do snapshots, dont know what time period request is asked for
- need history as unfolded
- Satish - snapshot - point in time of a policy, if you take a point in time copy of the polisy at 3pm on 5/23, take a copy of that same policy tomorrow there could be changes in between, question - are we capturing jsut changes or complete copy
- Jeff - data submitted in format of the data standard reqs, would reflect things that have and haven't changed - record format
- Ken -snapshot on pull, source data must have eveyr possible snapshot, doesn't keep at snapshot
- David - HDS will be accurate rep of source systems in correct format at any time
- not incremental
- will look at entirety of period of relevance
- David - req captures that "these will be the records"
- Ken - policy and loss transactions
- D5 - data freshness
- D6 - 5 prior years + current in HDS
- Peter - strawman - need a decisiuon on how long we retain data
- Ken
- D7 - data in the HDS will remain within 5% error tolerance per line and state based on openIDL edit package
- what? Data requested, data loaded? do we need to reevaluate every time we load data?
- Peter - would like someone to correct - NAIC handbook talking annual reporting
- Ken - constraining ourselves to annual reporting
- Jeff - mark for clarification from dale
- Brian - 5% coinsistent with AAIS stat plan
- Ken - we do it on load,
- Peter - individual load
- Ken - unclear of math / thresholds
- Jeff - biz requirement for arch
- D8 - access is permissioned
- Jeff - diff categorties
- David - what Dale wants, any new use is consented to on a use by use basiss
- if there for stat reporting, data not accessible without specific approval
- Ken
- permission on extraction
- David - you could be permissioned party for one use (annual report) not permissioned to pull data for another purposed - granual permission based on use
- Ken - use = extraction
- ask for another extraction
- Jeff - for the staged data, in extract data - single defined use - once you have the data cant use for another purpose (Column F ROW 2)
- david - nuance - cant extract data, you can only use for cert purpose - yes - use must be approved
- Satish - internal access? d0 we need to worry about internal access, from a carrier standpoint
- if you put data into HDS - can we see who put data into HDS from carrier standpoint
- Jeff - carrier would approve requests
- Ken - out of openIDL's hands - you own HDS< you control however you want
- David - HDS is carrier-owned asset they do with as they see fit
- Ken
- E2 - DATA shall be aggregated during extraction, E3 anonymized
- these two cells are related
- should we change from during?
- aggregated ON analytics node
- Jeff - not every detailed record supplied, some form as part of extraction query
- David - instead of on extraction - raw data doesn't leave carrier node in its raw form
- maybe cleaner to write - raw data doesn't leave carrier node
- Satish - original intent of rwquest data, add requirements: consent, when, time period valid
- data shall be aggregated should be moved to extract
- David - columns are confusing stuff
- Ken - ignore columns for now
- David - raw data (no extraction pattern that pulls all data out)
- Carrier node to analytics node
- Ken
- E3 - anonymization happens on analytics node
- Jeff - does this also mean some of it does get transmitted for specific policies without unique identifiers
- David - where this goes - defining how specific extract patterns might behave
- dont want a lump travelers dataset sitting on anaylytics node indefinitely
- if pulled for purpose - would like to occur immediately, not stored as travelrs data in perpetuity
- Ken - carrier is the identifier
- Satish - not about PII but just carrier
- data source shall be anonymized
- David - PII should not be stored, etc.
- Eric - one of the things, havign DL #s in HDS, VA wont get it but if not in the store - other things for useful research doesn't happen
- PII in and of itself
- Ken - DURING extraction
- Eric - not give me permission to get it
- confusing data reques from smart contract that gives me permission
- Satish - clarification
- anonymized
- do we ever need to know from RR standpoint that this data is from Hartford, Trav?
- Eric - either a data call or building HDS and go into other areas, if I call a market conduct of Hartford for thisd year send me all your info on your policies, you may pull from HDS
- smart contract negotiated - here is the data you have permission to pull it in this form
- option there going forward
- not limiting to hwat we see today but could happen in the future
- Jeff - stat report does not need to ID, in aggregate
- Eric - now stat rep, could be used for other reporitng requirments, devil in this detail is the extraction
- David - lot of reqs driven by extraction pattern
- is EP says "combine x carriers by y carriers" will be stored that way
- specific use cases will define that
- concernd - storage of data will be determined by extraction pattern terms
- Eric - right now only for member companies, and right now AAIS gets it not totally anonymized
- you dont give me who carrier is, but AAIS has definied business need
- Jeff - combined at service but not available or reported
- Eric - AAIS not get or not reported (have it not reported)
Recording:
{"serverDuration": 136, "requestCorrelationId": "06c58a863ee6ba93"}