Page History

...

...

• What is the data? Glossary or definition? What is being loaded (stat report well-defined)
• Assumption - stat plan transactional data, metadata is handled by spec docs as yet to be written
• Data existing in HDS, what schema says, there to fulfill stat report, this is just data thats there, period and quant/qual of data designed to do stat report, for this purpose just a database
• Minimal data catalog - whats the latest, define whats there (not stat report per se), whats in there is determined thru the funct described (time period, #, etc.) - diff between schema for a db and querying it, format for what could be in there
• Minimal form of data catalog - info about whats in the data
• Schema is set but might evolve - "type of data loaded" - could say "not making assertions this data is good for a specific data call but to the best of our ability it is good to X date"
• KS - must be able to develop report from extracted data

Load Function

• Deeper in process of data you have getting into openIDL, details of managing
• Process, raw data in carrier DB, turned into some "load candidate", proposed to be loaded into system, needs to go thru edit package
• DH - before HDS?
• KS - from your raw data to accepted HDS data (load function) and will inc other pieces like edit package
• DH - internal loading to the carrier
• KS - carrier resp for turning data into intake format (stat plan)
• DR - req for "heres what data should look like to be ingested" - 
• data model - stat plan day 1, day 2... data model
• KS - process of taking it in, do work to make more workable in the middle, dont commit to saying "what you put in front end is exactly what ends up in HDS" - right now not putting it exactly, turning it into at least a diff syntax and never will be 1:1, semantically close, 
• DH - more sense for decoding
• KS - load funct part of openIDL, carrier entry point, what carrier putting into load func is stat plan, THEN run thru edit package, review/edit (a la SDMA), "go" and then pushed thru HDS - carrier not doing transform, carrier loading thru UI (SDMA), may even be SDMA (repurposed) to load HDS at end of day
• DH - HDS w/in carrier node?
• KS - adapter package - need to support 1 keeping data in carrier world and dont want everyone to write their own edit package and load process, agree on somethign that runs in your world that is lightweight edit package
• DR - simplify, essentially a data model, how does it lie in HDS, may or may not be a different input data model that is whats loaded, once in HDS and "loaded" should conform and have any edit packages already run on it, all running on carrier side, dont want it going out and back - caveat, edit packages are shallow tests, not looking at rollup or reconciliations, "is it in the format intended?"
• KS - row by row edits, not across rows, had to have x w/o errors, etc. - syntactical and internal, "if you pick this loss record cant have a premium"
• DR - sanity checks and housekeeping 
• after edit, push to HDS (tbd format, close to stat plan day 1)
• PA - extensibility, adding more to end of stat plan in the future

...

• KS - requestor needs to be able to see if they have access to data call, and see one or more reports related to that data call - if you can get to data call you can get to the report
• DH - participants and REGs, credential who can see it?
• KS - can't get into UI w/o credentials, report viewer? 
• DH - for carrier and requestor, dont want low level analyst sending report to newspaper
• KS - levels of access to access a report, true of creating and a lot of functions (regulator has login and can see but not create data calls) - finer-grained permissions
• DH - once submit a data call to a state, no control over it
• KS - requirement not to be able to download it, method to keep them from abusing, sharing file
• DH - NOT editable 
• Watermarking reports? maybe not a requirement
• DH - only the requesting body can get the report
• KS - how does it relate to carriers being able to get report?
• DH - if EL does a data request and gets results doesn't mean GeorgeB can get results - needs to do his own data call
• KS - scope of the data call 
• DH - recipients limited to state requesting data without further approval - dealoing with data calls too - it would be nice if REG as making request would identify if the request is adhoc or recurring?

Receipt

• SB - Receipt

...

• that the Regulator has received/downloaded report - given to Reg, Carrier and Stat Agent
• DH - maybe PULL w/in UI
• KS - automatic? follow link, you know you received it
• DH - notification report is avail, you go in and pull the report, as pulling report UI could then update to reflect report was taken
• KS - assumption you are not following link from notification
• DH - is the report so big it can't be emailed or delivered
• PA - question, requirement, we dont want to make a file b/c we dont want it to be shared, KS said "not be able to download it"
• KS - struggle w/ how we can not have a file
• JB - have a file, encrypt it
• DH - want file protected so not editable
• KS - once downloaded impossible to prevent sharing
• DH - some form of report
• KS - know who downloaded
• DH - if info is anonymized, are you telling Regs who participated?
• KS - option the data call could have, who participated, when does it make sense for Reg to know who participated
• DH - ok if carriers are listed on a report IF boundary/threshold for data (%) met - how much of market are REGs going to have included in any data request
• KS - how would they know?
• DH - asking provider "how much of the market is this representing?" - might ask Stat Agent (AAIS in example) as intermediary
• KS - NAIC? is that the NAIC #, the total market
• DH - NAIC page 14
• SB - what are the elements of the receipt?
• DH - Data Call Name (whatever its called), who received it, when received (time/Date), a receipt for every individual accessing (downloading?) a report - indicate WHERE they are from (VA DOI ELowe = who and where) - include organization
• PA - if resp for reports want to know who provided data for report and who downloaded, when filed - can stand up to rigorous audit, like to know who turned it down (DALE doesnt want) - doing auto coverage report for TRV in State X, when they say "we dont want to do this report (whatever reason)" needs to say that was travelers not participating
• KS - scenario for data calls, not req to do reporting for TRV (might not use openIDL) for stat reporting, req to do the reports, contracted to do stat reporting for carrier, can tell if they werent on the list, know they COULD have and can tell if they are on the list-
• DH - Stat Report SHOULD HAVE, Data Calls COULD HAVE
• SB - doesn't want receipt with Hartford, Hanover, and NOT_Travelers
• DH - carrier's business how they respond
• KS - how public is the list of contribs to a data call or stat report, just list? other contribs see other contribs - if EL asks for a data call he can see participant but can other participants see who else - Can Carrier1 see who else participated?
• DH - public info once hits Insurance Dept, gets to point of aggregated and anonymized, could be public, but  a lot of data calls under confidentiality agreements
• PA - turn in report, list of #s responsible for, turn in list of participants and non-participants 
• DH - maybe not participate over tolerance? why sign up with AAIS for stat reporting and not use for a given state
• PA - some companies work with AAIS do to Stat Reporting, have legacy systems, may not write all the lines (dont write coverage, or have team and do analysis themselves)
• KS - targeting carriers? how does a regulator say "I want TRV to respond TODAY"
• DH - maybe not do it over openIDL, can make data call to TRV, obligated to respond w/in their level of authority
• KS - in the system?
• DH - envision, similar to sign up for AAIS or stat agent, say "these lines are open to openIDL doing our data calls"
• KS - that notification, new data call comes in 
• DH - could envision a REG request a data call to only one Carrier, wouldn't want to entertain going thru openIDL if JUST TRV, data already there, can pull it themselves, who creates EP, formats report, all that stuff, maybe own
• KS - over time used to doing things thru openIDL, skillset to build report and continue
• DH - just their data, may want more eyes looking at it, verifying whats being reported, resp for the info going out, just them, nuances in results you. make sure management is aware of, aggregated and anony, that concern doesn't exist - build this more for where it is a wide spread call, not 1:1 carrier:regulator - future build 1:1 into system but for now they have well-defined processes

Auditability/Traceability

Exception handling

Notification

• KS - notification report completed
• DH - notification of data call (new)
• PA - external to UI or outside of UI
• JB - within network, preferred way, channel comms request
• KS - inbox expectation?
• DH - push or pull
• JB - default channel, comm of request, responses, likes - same mechanism
• KS - what it does now - find data call, def not robust UI, push-pull?
• DH - push preferred
• KS - subscription model, subscribe to notifications
• JB - application looks for those events and pushes notification
• KS - pull worth considering, inbox items you should consider, if Dale gets a push "you have report" , has to find emails he needs to respond to, otherwise logs into system, notifications in Inbox
• DH - what has been sent and disposition of those items in the UI, perhaps a delete option, acknowledgement (instead of inbox filled forever)
• KS - notification management (delete /archive)

Auditability/Traceability

...

Data Call

Communications for resolving conflicts, etc.

...