Table of Contents | ||
---|---|---|
|
Contributors
Initials | Contributor |
---|---|
DH | Dale Harris - Travelers |
DR | David Reale - Travelers |
SC | Susan Chudwig - Travelers |
JM | James Madison - The Hartford |
SK | Satish Kasala - The Hartford |
KS | Ken Sayers - AAIS |
PA | Peter Antley - AAIS |
SB | Sean Bohan - openIDL / Linux Foundation |
JB | Jeff Braswell - openIDL / Linux Foundation |
Process
The Archiecture Definition Workspace is where we as a community come together to work through the architecture for openIDL going forward. We take our experiences, combine them with inputs from the community and apply them against the scenarios of usage we have for openIDL. Below is a table of the phases and the expected outcomes of each.
...
- PA - 3, 4, 5 happening today - ? for Ken - why doing the EP after the LIKE? if we attach EP before they LIKE it can do Like & Consent at same time (KS - like confirms the carrier is on board with the essence of the data call described in the text. Don't want to develop EP for data call no one likes)
- DH - agree for stat reporting, for data call it is different - stat reporting obligated to report, no choice, for data call may not want to participate in data call and share data with openIDL, may do it themselves and go direct to regulator
- Jb JB - collected by openIDL on behalf of REG,
- DH - may not go thru openIDL, even though Reg may ask thru openIDL, collected by openIDL for those who have consented
- JB - rationale, efficiency, less expensive, concerns about sharing data based on %, if it is for reg
- DH - anything Carrier provide they get copy back (to regulator and their portion of it)
- JB - dont don't want to be larger of certain %
- DH - if participating, get copy of whole report back, their % and other carriers, value of having openIDL do it, see results, right now they know their piece, dont see what Reg sees
...