Date

ZOOM Meeting Information:

Monday, Oct. 2, 2023, at 11:30am PT/2:30pm ET.


Join Zoom Meeting

https://zoom.us/j/7904999331

Meeting ID: 790 499 9331

Attendees:

  • Sean Bohan (openIDL)
  • Jeff Braswell (openIDL)
  • Peter Antley (openIDL)
  • David Reale (Travelers)
  • Josh Hershman (openIDL)
  • Yanko Zhelyazkov (Senofi)
  • Faheem Zakaria (Hanover)
  • Satish Kasala (Hartford)
  • Tsvetan Georgiev (Senofi)
  • Ken Sayers (AAIS)
  • Ash Naik (AAIS)
  • Brian Mills (AAIS)

Agenda:

  •  How the analytics node functions in the PoCs vis-a-vis the state regulators

Notes:

  • ND = 1 DOI
    • would have EP
    • would submit EP
    • Carriers return data to Analytics node
    • AN would combine data, generates report
    • DOI gets report
  • NE CAT = N States (10?)
    • how to run POC to make it as effective as possible
    • immediate - asking for conssitent set of data covering different areas
    • doesn't make sense to have nodes for states
    • appropriate approach - analytics node performing data call request to collect data, 
    • so carriers provide data for mult states
    • carriers prep data per state
    • only need one AN to provide interfaces for the state
    • as an add-on, one or two standard, possibility what it would look like for DOI to make a request
    • simple filter
    • limitations on report they get back
    • AN gets data from carriers from var states, perform reports on behalf of states
    • Will every DOI get the same report?
    • format of the report is the same, relative data is the same, EP is the same, results look the same, report generator doesn't care about state
    • thing that scale, amount of effort, different EP returns same results - if diff formatted report, requires work
    • format/output of the report - standardize it to make it trackable
    • possible to put filters on input data, "x coverage" or "y locations" filters that effect how report processed
    • when you have to change code on the report it is more work
    • thinking: EP is a collection of data for subsequent reporting, the state Regs could request diff filters of data
    • first step, content more than format
    • carriers - dont want DOIs to have a dash with BI capabilities
    • for POC, this data is for the POC, one time use of the data
  • lets say Maryland running EP, will they need to have an end clause to list out the counties? Or "in the state of Maryland and then AN filters out counties"
  • if it is for a particular cat, ID areas in state by cty/zip where damage occured, thats in EP, filtering happens after that
    • because CG will be involved in doing the work to help, timely, bring them into the picture
  • data standards to put out will also inv some input from states
  • good idea of what things look like, NAIC standards there, additioonal data elements in play
  • conceptually how we approach, formats not locked
  • Reports are ephemeral - dont have anything saved outside of carrier's node
  • dont want stitching together of various data calls and making an external data store to ask other questions
  • Need clarification from Dale - not just approving query - also THE STATED PURPOSE
  • "looking at x data in this format, for y purpose"
  • not just approving mechanics of extraction, approving data product
  • Regulators can ask for a specific purpose
  • every data call in the POC will be for this POC, strictly for that report, blanket covenant
  • stated code for purpose of data call
  • can be process instead of tech solution
  • not just an FYI - binding, this is what it is used for, like  a TOS
  • shouldnt be filtering in the data analytics node
  • only what it is said to do
  • flexible means needed so they can ask for what they want
  • involve in next conv on data side, get regs involved, fact we will have help 
  • more news ssoon on that - agree on data elements
  • what output format to DOI?
  • default model at the moment - want to have that conversation, get input from the states
  • excel or PDF? 
  • multiple DOIs dont get each other's reports
  • pull it out of the S3 bucket
  • exclusivity? Only so DOI could see it, didnt make it for mult DOIs, wont see if you dont consent
  • constraint - not assoc with a state you cannot consent to it
  • designed right now - each DOI would have own node, in this we would simulate all DOIs having own node
  • issue - not really serving the function as a proof - would have to set up mult nodes
  • not really doing what it says it is doing if there are caveats


TimeItemWhoNotes




Documentation:

Notes: (Notes taken live in Requirements document)

Recording: 







  • No labels