You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Date

Antitrust Policy

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:

  1. Architecture WG Harmonized Data Store Task Force
  1. openIDL - Architecture - Member Requirements Files
  2. Regulatory Reporting Requirements from Dale H (Travelers)
  3. Requirements Table


TimeItemWhoNotes




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: 





  • No labels