I. Intro to Meeting
A. Initiation By Peter Antley - Meeting formally opened + Group Identification
B. Reading of Linux Anti-Trust Policy Statement
C. Discussion Of Today's Agenda
1. Introductions (note: we skipped these)
2. Scoping Document from Last Week/Open Discussion
3. Rereview of Gen Zero/Day 1 Elements (side note: almost all Day 2s filled out)
4. Discussion of Sample Data + Looking ahead to Day 2 on a Conceptual Level
II. Daily Business
A. Scoping Document created by Antley (an in-depth discussion followed request for each attendee to review)
1. Change from terminology "Day 1" to "Generation Zero" one/same. To clear up confusion.
2. Review of Gen Zero Stat Plan - reg. reporting can be accomplished with this. But also value in decoding stat plan into more functional model/
3. Generation 2 - New Attributes Come Into Play - much further down the road
4. Ultimate goal to produce auto coverage report. Secondary goal: homeowners. Annual state DOI report? Suggested.
B. Plan of attack: take Gen Zero and Potentially Gen 1 and develop sample data. Intention for this meeting: define sample data and what that will look like. How do we visualize?
C. Feedback collected from group. Additions spelled out (what are they?) to Gen Zero Et. al. addn of NAIC annual statement line #. Spelled out.
D. Reminder that AWG has considerable work ahead prior to implementation.
E. We need to clarify the size of the sample that is most relevant and which parties are involved.
1. How many policies matter? 100? 10? 5? Less than 5 not very relevant or useful. (10 Agreed to - put into flat model & normalized model and generate reports from the combination).
2. A mock-up will enable Antley to report back to the group on the validity. Prove the model out more comprehensively. Visually.
F. Clarification of work of RDMWG - group is tasked with looking beyond Day 0. Technology has to be the primary focus of modeling group. Modeling group has to come up with data elements.
G. Query: move to homeowners? No, definitions of Day 0, 1, 2 & agreement should come first. (Broad consensus on this).
H. In-Depth Review of Day 1 Data - ASL codes, etc. Field modifications.
1. Note that many elements flow into each field for a given variable.
2. How do we transition from generation to generation? And to new fields? How many fields can be standardized, and how can we handle this?
3. Where is the "misalignment line"? We should standardize based on the commonalities.Finding the core set of data with which everyone can populate their HDS. Which fields are shared by all? Reduce # of transformations.
I. For Day 2: what are our new coverage codes and acceptable values? (Examples discussed)
J. Discussion of highest generation/new attributes - Antley vs. how much lift can we get from simplification vs. a series of adds right now. (Answer: simplification: not there).
K. Can we look upstream with the target in mind? What is Generation 3? Can it simply be appended or will this create numerous issues? Can we simply add 26 more fields that would go 1:1 with the record as it right now? Could we make the fields optional?
L. Can we unpack existing stat plan from all these codes? And if so what format would we have to display the expanded data? (Right now, a long string of #s we have to parse). Simplify to be clearer without idiosyncrasies of code mappings. A big lift: intermediate extra conversion. Ultimately we want to feed more
raw data without having to do the mapping ourselves. Simplifying = decoding. Day 3 = add. Focus on unpacked fields for now.
M. Question of when we will implement. What day etc. What legal clearances are needed? Should we wait for architecture to be built? Still waiting for this.
1. Day 2 - looking beyond stat plan, Day 1. Will be unpacking but what else will it involve? This is the exercise we need to figure out. New standard to be written into HDS, new set of data we can agree on. It will depend more on the # of differences than the commonalities. Goal is to get everyone on the same
common data standards
2. Possibility raised that we might be "there" already from a data modeling standpoint - but AWG - which is the critical path - is going to take some time,. Is this purely a tech play, or trying to do something more? Is it a purely a tech pitch at the end of the day?
N. Joan Z. of AAIS interjection into discussion - not simply tech play.
1. Original discussion not just talking about tech change, but a dramatic shift in how we exchange information.
2. Addressed use case re: new way of bringing carriers in to share information. Complete revamp of how we're providing info to the HDS.
3. Moving beyond statistical reporting: a platform for information exchange that has never existed before. It can do many things beyond basic statistical reporting. Wrong to just frame it as a tech play.
4. Joan feels like broader vision of what this can do is missing from conversation. Feels we just need to build it 1x and then delineate different ways to use it. Nothing fundamentally has to change with the framework. Not just for regulators - value to carriers as well. Not just a matter of changing
the stat plans. Not strictly a stat reporting platform. Ideal starting point. Ultimately carriers and regulators will come up with uses we've never thought of.
a. Data standard necessary
b. We need to have a level of granularity necessary to make outstanding policy.
c. Data has to be present & security, in HDS and then we can build from there.
d. We need to stand up a test network.
e. Next best ideas will come from carriers and regulators.
f. This is not the same as building an enterprise wide application, but a platform for the exchange of information
g. Step 2 will be unknown for a while, and this is acceptable.
O. Hand-Offs to Architecture Working Group - agreement that RRDMWG's accomplishments for Day 1 are fine but business requirements need to be defined beyond this.
P. Broad agreement on the points Joan raised, but questioning the discipline we are employing, and the related costs, re: exposing the data. Rules are changing, goalpoasts are moving. A disciplined plan is absolutely necessary. Structure, discipline, acceleration re: moving forward. A commitment to using the
platform laid out over several years of work. How do we move forward? (Bear in mind things can still be fixed/improved). AWG can make progress, RRDMWG can test out in an LF Test Network.
Q. Agreement on this although per Travelers, AWG needs to iron out kinks of test network because it isn't currently functional. Moving to more of an adapter model. For now, Day 1 Stat Plan is there. Next week? Start taking a look at Homeowners. 2 & 3 paused for near term. Agreement on this.
II. Discussion of Plan for next week
A. Talk about homeowners (w/Andy on the call) - any critical components on homeowners?
B. Or per Joan should we see auto stat plan in practice before we move to homeowners? (Consensus on the latter).
C. Barrier to this is getting finalization on technical side. Joan Z. proposed: that we move forward with North Dakota data call that we have today, while AWG and TSC move forward to get platform to where we need it to be.
D. Proposal from Antley that we take two weeks off to let AWG and TSC do its work. Resumption of meeting on June 3rd. (Broad agreement on this).
|introductions||introduce new people|
|generation 0/ day 1|
|generation 1/ day 2||Discussion on the Day 2 fields. It would help the technical teams to see the dictionary for the next phase.|
|worked example||To prove out our model we will use test data to build some sample data via excel.|