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)
David - making sure data used for what it was requested for
Eric -c ant envision every use case but if we have raw data and extraction patterns, no free reign for me (or other r3egs)
David - if intended data call says "all data agg with other carriers, noting from aais
would have to approve at the time
Eric - group needs to figure out min # of carriers to prevent regulators from deidentify who submitted it
Ken - E4 - only aggregated and anony shall move past analuytics node
E5 no PII data transmitted beyond private analytics node
Satish - do we ever need PII data published in stat repoting?
other reporting?
BrianH - not as part of stat reporitng
Satish - other data calls?
Jeff - dont need actual PII
David - one of the cores - if there is every a use case requiring PII, would want connection to be made prior to transfer out
major benefits of this topology
doesn't leave carrier node
GDPR, CCPA makes it messy if it ever leaves
Ken - didn't quite match
could leave the carrier and be used for reporting but it never leaves analytics node
David - major Arch req, in former design had to, this winter thought maybe we move it into the carrier node
imp requirement - where is that line
Jeff - req still stands
not analytics node and not carrier
Satish - example - age range of drive, sometimes requested, individual elements like date range - is that PII
David - fact aggregated would obscure identifying things
game is messy to play
Ken - how do we from openIDL perspective meet this req
Carriers not framework
David - messy, say there is a req to put some sort of info considered PII in HDS, obfuscated and deidentified by extractioin pattern, would set rule EP do not hold PII - nonfunctional req, needs to exist
based on some use cases, will be necessity
thinking
Satish - in some cases, one of more PII elements, even if not contribute to constructing full ID of a person