openIDL Navigation
Grouping | ID | Date | Requirement | Notes |
Data and Data Integrity | D.1 | 5/23/22 | Data contained in the carrier data store will conform to OpenIDL data model standards | |
Data and Data Integrity | D.2 | 6/1/22 | OpenIDL data model standards shall exist for all Property & Casualty lines of business except Workers Compensation (List out lines of business). Domestic business for now. | |
Data and Data Integrity | D.3 | 5/23/22 | Minimal data attributes to be available in carrier data store shall consist of the "Day 1" OpenIDL data model fields, other attributes in the OpenIDL data model are populated at the option of the carrier | |
Data and Data Integrity | D.4 | 5/23/22 | Data shall consist of policy and loss transactions over the course of the policy term and lifetime of any associated claims based on source system activity | |
Data and Data Integrity | D.5 | 5/23/22 | Data shall be current to the Prior Month + 45 days | |
Data and Data Integrity | D.6 | 5/23/22 | Companies shall maintain data in the carrier data store for 5 prior years plus current year | |
Data and Data Integrity | D.7 | 6/1/22 | All data contained in the carrier data store is soley owned and controlled by that carrier | |
Data and Data Integrity | D.8 | 6/1/22 | Data shall remain accurate as of a point in time and may be corrected over time if errors in the transmission of data occurs with no obligation to restate prior uses of the data. Once data leaves the carrier node, that data is assumed to be published/accepted. | |
Data and Data Integrity | D.9 | 6/1/22 | OpenIDL shall maintain (specification and implementation) an edit package to be available and used by carriers to test conformance to data model standards and data point interactions similar to the functioning of the AAIS SDMA portal. Implementation is part of HDS solution. OpenIDL will audit, certify and conformance of edit package implementation. | |
Data and Data Integrity | D.10 | 5/23/22 | Data must pass through OpenIDL edit package and be within 5% error tolerance per line and state based similarly to acceptance by AAIS through SDMA portal | |
Data and Data Integrity | D.11 | 6/1/22 | The OpenIDL data model standards will foster effective and efficient data extractions such that queries of data can be satisfied within 24 hours of commitment to participate in an information request | |
Data and Data Integrity | D.12 | 6/1/22 | Any changes NAIC required fields to the OpenIDL data model will require a minimum of 18 months notice for carriers to conform | |
Information Requests | IR.1 | 6/1/22 | Requests for information shall be specific in detail and communicated through a secured protocol | |
Information Requests | IR.2 | 6/1/22 | Forum shall be established for carriers and regulators to discuss and agree to intent and interpretation of information request | |
Information Requests | IR.3 | 6/1/22 | Request for information shall be for aggregated information only, no individual policy, claim, or personally identified information shall be requested or honored | Need for info @ a policy level or vehicle, obfuscation of VIN ways these requests are added to or validated? KS: exceptions known when extrax is requested JB: at policy level, info from policies CANT be extracted (they might be useful) or some level of aggregation. Data contributed from each carrier to prevent identification DH: requests - none ask for policy or claim info up until today DH: straight to regulator? fine w/ providing info. Analytics node others have access to and can pull? NO JB: only regulators would have access to information DH: person or group making reports for reg? Concerned. Controls so they cant do anything with data DR: blurring lines from compliance-style store to transaction processing, requires higher standards, conflating 2 systems, holding to other standard can make a lot of reqs messy JB: not matter of timeliness or responsiveness, matter of scope and level of aggregation, level by which info is agg or identified, only collected for purpose of sending to regulator, covenants needed DR: purely a regulator - not LE or Insurance Commissioners. Caveat - not bulk. PII should never be requested in Bulk. If a specific question, then yay/nay "coverage exists" but leery of "give me all VINs" just because DH: dont want to open up our books JB: PII in general not involved. ND is VIN not necessarily person involved. JB - another requirement applies to Data Requests |
Information Requests | IR.4 | 6/1/22 | information requests shall identify who has access to the | DH - not naming people, data within the node. For specific info request KS: To the analytics node or to the specific report? Doesn't change from request to request. Dont add new user to analytics node DH: req from Reg, no interim body in between, just us and Reg have access to data. If AAIS has access to openIDL, and create extraction pattern, need to understand WHICH bodies will have access to that data - needs to be spelled out. Get to 3rd party: AAIS + Carpe Diem, wants to know ahead of time JB: access to the data, the results, the report DH: access to the data AND the report, outside of carrier node KS: aggregated, extracted data DH: Carrier, claim, policy, PII - I need to know who has access to it KS: anything you say is OK to be in the results, you want to know who JB - qual and credentialing DR: need for simple data lifecycle, provenance. For this request, this all lives in the extraction request, for this request - this raw data - the result shall be X and visible to Y folks for Duration Z. No unfettered access to HDS, only with some purpose. Even analuytics node shoulfn't be used for other purposes without consent KS: Definition of what data shoulf be used for JB: Categories: privileged, etc. DR: a lot may not be funct. but when we get to approval of extraction patterns, might be more implementation JB - term sheet of a request DR - adapters can see these X raw elements, can turn them into Z elements for ABC. Routine if useing same data, but shouldf be explicit KS: Nuance, part info request and part how it works. Who can see uncombined data should be part of system architecture. Refined results are what we are talking about. KS: When a carrier consents their data is run thru extrax, their data is recognizable UNTIL it is processed DR: 3 steps: RAW, Semi-Agg/not anonymized, Anonymized. Bake in now |
Information Requests | IR.5 | 5/23/22 | Information requests shall define timeframes for data to be included in the aggregation | JB: talkkng about lifetime use of info - historical or one purpose, number of uses, number of purposes DH: when you make a req for info, request must be specific (time parameters, types, etc.) for the request of the data - query range |
Information Requests | IR.6 | 5/23/22 | Information requests shall define the attributes to be used in aggregation | JB: Nature of the data call request? KS: shoudl be redundant - dont see people reading code JB: query, results in aggregated things, 2 parts of a request-report. Req will identify the things selected and need to be accessed. If you did this via Wizard or screen, those criteria included at that level. Translated into extraction KS: least big declarATIVE IS A HEAVY LIFT. Not sure short term target, right now map-reduce function Peter - attaching meta data to the calls, human readable - will need that clarity JB - not talking NLP, but request-translated-terms/types requested and accessed in raw data. KS: whats going over the wire a result of an agg routine. Will return written premium by x and y. DR: acceptance criteria - request, tells us XYZ, approve/reject - some plan lang explanation of what is being asked for. REG: these premiums these lines - should come out in the aggregate. Who writes the query? Analytics node? REGs? Here is what the output looks like, whats needed to gen output. Prob run test execution, these elements were accessed, accepted. DH: also want to know if there is extraneous data requested thats a backwards way to get some data PA: not quite sure what actor will write Extrax Pattern, will be run on certain analutivcs node, who owns that query JB: if in fact, aggregating total premiums per zip, other criteria involved wouldn't show up in req. If you asked "give me total premium on house on Main street" - different thing. Providing info in aggregate JM: solutioning - req is clear, if you use elements, tell me what you want to use DR: needs to be a req JM: might be hard, implementation JB - nature of query will specificy types of data JM - by def, person capable of reading code will be able to answer question. Must be operable by human beings PA: I will write an Extrax pattern to calc premium on X. Who will come in and validate that query is doing what it is supposed to be doing? DR: solution prob for how to verify, on us to solution for, need to know what was supposed to be requested PA: person running Analytics node needs to validate JB: query request, what you can request, minimal set to expand, translates to extraction logic DR: someone writing query should be responsible, result A and Inputs B - need to be able to verify only B was touched and ONLY A came out. what data pulled for what end - must be defined - shoudl be trivial for whoever is writing the query JB - specificying the things the query is for and validating thats what it does JM - saying you can block someone AND block/report. "I reject this request" vs "You said you needed 5 things and we see you requested 7 so..." JB specifying what it is intended to do is a starting point DR - then governance JB - glossary DR - not thousands of elements |
Information Requests | IR.7 | 5/23/22 | Information requests shall define the logic for extracting and aggregating data | DR: interpretation - doesn't need to be pseudocode level or extremely details but has some detail JB - business justification request? DH/JM - yes JB - specifies purpose, what elements, who its for, how done - human understandable JM - will be metadata page, very descriptive, processable by humans JB - logical request KS - human TRANSLATABLE (understandable) |
Information Requests | IR.8 | 5/23/22 | Information requests shall identify and define the calculations to be used in aggregations, analysis, and reporting | JB - similar to logic. Combine with IR.7 |
Information Requests | IR.9 | 5/23/22 | Information requests shall define the specific use of the information | JB - use and access - REG only, single use? JM - who in the sense of roles not names, will know what they want to do with it. Privacy +. Different than "WHO". KS - restriction/constraint. If you say you use it for that, thats all you can use it for. JB "specific purpose and not other things" - like licensing JM - commercial vs personal all the time. |
Information Requests | IR.10 | 6/1/22 | Information requests shall define the permitted accessors to the information and users of data | JB: the WHO. Use declarative, WHO is a restriction JM - redundant with IR.4 DH - who has access to final report JB - other was access in transit. RELATED to IR.4. JM - lifecycle flow - who has access throughout DR - implementation has that data in the same place, doesn't hurt to be explict with requirement JB - tempted - come up with a draft of template of a term sheet for this DR - few weeks ago - definition of that request template. DH: beyond the smart contract - business level |
Information Requests | IR.11 | 5/23/22 | Information requests shall communicate the proportion of individual carrier information to the population of data in the extraction prior to final commitment to participate | JB - keep carriers protected from self-detection. Data can't be deidentified. Provided to each contributor. JB - only know when you have the total DR - requirement: maximum acceptable, sep req that says "no darta will be pulled or aggregated UNLESS it can be confirmed. Might have to do pseudo-extraction to get a rough size. JB - consent to request, what it is asking , data is contrib to the analytics node as "pending" but not approved for use until such time there is sufficient data to let the node say what the totals were DR - maybe do with a lighter weight. Shallow (25% of WHAT) JB - general metrics, so many policies outstanding JM - language of "prior to final committment to participate" DH - two step - what portion you will have (query all avail carriers, who will participate) then when there is a sense of what % of the total WILL we participate. Others face same thing KS - time problem - bartering back and forth JM - regardless of how we do it, data wont be seen until we meet the threshhold. We won't see data unless X%. Multi-stage scares me a lot. DR - once extracted have we lost control? Governance. In Analytics node. Lost effective technical control. Def recourse. Affirmative tech control is lost. Jm - governance level requirement. Whole solution requires not release data w/o reaching threshold. You pull one carrier then ouch KS - micro-req - define participation threshold - then argue governance DH - 2-step process, another requirement below, set at 15%? KS - % of what? premium, loss? KS - reports just dont tell one thing, define that and then deal JB - requires more thought IMPORTANT ONE |
Information Requests | IR.12 | 5/23/22 | Information requests shall be for one time use only. Additional uses for data will require a new request. | JB - licensign of its use, one use, baseline, mayube beyond 1-time use. Use can be controlled or specified JM - what if you know something is 1/4 or annual. Each submitted as a sep request DH - 1 req per year or some timeframe sufficient PA - some indication - has your org approved before? changed year to year? JM - grand vision - if you did have something monthly, set as monthly recurring, could be useful DH - specific req recurring, do it on a time period - this month X next month similar but not the same. Dont want scoppe of any req expanded beyond what was agreed to JM - RECURRING important but maybe out of scope for now JB - data not being used without consent, without apprvoal, who is using it |
Information Requests | IR.13 | 6/1/22 | Information requests shall identify the path information will flow from its raw form through final reporting (e.g. carrier data store to private analytics node to Multi-Carrier aggregation mode to Regulator) | |
Information Requests | IR.14 | 6/1/22 | Information requests shall identify the form information will flow from its raw form through final reportings (raw data; carrier summarized aggregated and anonymized data; reported data) | |
Information Requests | IR.15 | 5/23/22 | Information requests have an expiration date and time from which consent is needed, if applicable | |
Information Requests | IR.16 | 6/1/22 | All requests for information, its approval, the disposition of data from its raw form through final reporting shall be tracked, recorded and archived within OpenIDL | |
Information Requests | IR.17 | 5/23/22 | Carriers who participate in information requests shall receive a copy of the final information presented as well as their individual carrier results | |
Information Requests | IR.18 | 6/1/22 | Carriers decide in which information requests they will participate | |
Information Requests | IR.19 | 6/1/22 | Carriers must provide an affirmative response prior to any information being extracted to the private analytics mode | |
Information Requests | IR.20 | 5/23/22 | Final reports shall be archived by OpenIDL for 3 years | |
| Information Requests | IR.21 | 6/13/22 | Information requests should be testable. Should be able to execute a dry run and know exactly what would be returned if the data call executed | |
Access and Security | AS.1 | 5/23/22 | Carrier's raw data will be "walled off" from other entities with access only through permissioned protocols | |
Access and Security | AS.2 | 6/1/22 | Carriers raw data shall not leave its control - a secured limited access "private analytics node" may be established for processing information requests | |
Access and Security | AS.3 | 6/1/22 | If multiple information requests are being processed at the same time, separate "private analytics nodes" with separate access shall be employed | |
Access and Security | AS.4 | 6/1/22 | If multiple information requests are being processed at the same time, the data for each request will be segregated | |
Access and Security | AS.5 | 6/1/22 | Carrier data may be transmitted to a private analytics node only as the result of an approved data request via a permissioned access protocol | |
Access and Security | AS.6 | 5/23/22 | Carrier data may be transmitted to a private analystics node that has been aggregated and anonymizated through a secured protocol | |
Access and Security | AS.7 | 6/1/22 | Carrier data in the private analytics node shall only be used for the purposes for which permissioned access has been granted | |
Access and Security | AS.8 | 6/1/22 | Carrier data in the private analystics node shall be immediately purged upon completion of the processing for which permissioned access was granted | |
Access and Security | AS.9 | 5/23/22 | No Personally identifiable information (PII) data shall be transmitted | |
Access and Security | AS.10 | 5/23/22 | No altering or embellishing data including appending outside data is permitted throughout the processing of the information request unless approved by carrier | |
Access and Security | AS.11 | 5/23/22 | No changes to request, attributes used, extraction patterns, accessors, users, or specific use of the data is permitted post consent | |
Access and Security | AS.12 | 5/23/22 | Only authorized approvers may commit carrier to a data request | |
Access and Security | AS.13 | 5/23/22 | Data request communication shall be through a communications protocol within OpenIDL and archived within OpenIDL | |
Access and Security | AS.14 | 5/23/22 | Individual carrier contribution to a data request will not exceed 15% of the population of premium, losses, exposures, etc. for a given information request | |
Access and Security | AS.15 | 6/1/22 | OpenIDL is responsible for fulfilling multi-carrier information requests including extraction patterns, aggregations and formatting of final reports | |
Communication | C.1 | 6/1/22 | All requests for information via OpenIDL will be through a secured communications portal within OpenIDL | |
Communication | C.2 | 6/1/22 | All communications will be written (electronic) and be archived by OpenIDL for 10 years | |
Communication | C.3 | 6/1/22 | A non-response to a request for information will be considered a decline to participate | |
Communication | C.4 | 6/1/22 | Requests for information must come from an authorized representative of the requesting body | |
Communication | C.5 | 6/1/22 | Requests for information must state the regulatory authority for the information being sought | |
Communication | C.6 | 6/1/22 | Agreement to participate in a request for information is conditioned on OpenIDL providing the carrier the proportion of data that carrier is providing to the population of data | |
Communication | C.7 | 6/1/22 | Final agreement to participate in a request for information is valid once received by the OpenIDL communications portal | |
Communication | C.8 | 6/1/22 | Final agreement to participate may be recinded up to an hour after final agreement is received by the communciations portal to affirm participation |
Time | Item | Who | Notes |
|---|---|---|---|
Overview
Content Tools