Page History

...

1. Re: Input, Stat plan as it is gives us adequate data to do regulatory reporting, and we can ingest most of needed information:
   1. Accounting date
   2. Duration
   3. Coverages and exposures
2. Re: Output: some of the terms for which people are asking (presented examples here): e..g, Earned premiums, car years, incurred loss, earned/written exposures and premiums, incurred claims/losses, calculated ratios, average expenditures, average premiums, underwriting expenses.
3. Mr. Antley: the way they solve (@AAIS, in his warehouse) these questions today: they take the input records, process these to be centered around the idea of a policy, and then calculate: earned premium, paid loss, incurred loss, outstanding losses, earned exposures, paid claim counts, outstanding claim counts. They calculate all of this on quarterly basis. Sits and persists in data store on level on which they are making reports, they have these terms, grouped by policy, calculated by quarter. If x person asks "what is my earned premium for the year, for these kinds of coverages," he does a select query that does filters and aggregates and produces year output. Data on a policy and quarterly basis with the premium after it has been earned.
4. In AWG: Discussion - how do we set up HDS so it is accessible to regulators, sans putting undue burden on rest of system?
5. Pointed to base layer, from which we answering questions. How do we make it accessible to the persons making queries? Quarterly basis reports right now -→ fairly easy and straightforward
6. Mr. Antley solicited thoughts/suggestions from group about what the data layer will look like
   1. Mr. Sayers: when looking at data layer, we must ask visibility to whom? Carriers e.g., want to see stat plans eventually with more data. Can we put this in HDS per Mr. Braswell's suggestion? Data layer could be an ephemeral pass-through that is part of the extraction pattern, or a standing entity where ETL transforms stat plan. Key questions: what are we asking the carriers to prove, and do they care about any format other than the stat plans?
   2. Mr. Antley: who are the voters in this RRDMWG? We have carriers, and we have regulators. Another critical question: if we just look at the easiest way to load this, and say, the carriers can just be done with loading the stat records, at this point who is tasked w/turning the stat records into a query that makes sense for the regulators? Without relying on regulators to expend the energy/effort into turning records into something useful?
   3. Mr. Sayers: There is discovery here. We start from the stat plan - may want to make it less codified to make it more workable, but it can be a perfectly viable raw material. We can throw some reports at it however and say how difficult is it to get from the stat plan data to this report? Points to ultimate question: do we need an intermediate format?
   4. Mr. Madison: In this meeting, the intermediate business layer is as flexible and organic and transformative as we need it to be. Much more critical to define input and output layers. Stat plan = Day 1 (broad consensus), and then if we add numerous additional elements to this input layer, we can also make considerable progress. There also seems to be a series of additional elements that we want in the output layer that are not in the input - Simplest model complete conformity between input/output elements, but we're talking about something more complex and sophisticated than this. If something is a raw element, it has to go on input side. If it's stat plan plus, still has to go on left hand side - this is a column that will grow in complexity as the years pass. Output elements should be those that are fundamentally derivations from layer 1. Business layer is an unknown for now.
   5. Mr. Braswell to Mr. Antley: this group should remain focused on data modeling, and not the machinations of transforming data through various stages. This falls under the aegis of the Architecture Working Group.
7. Left-right computations (input/output) 
   1. Mr. Madison agreed with this point but distinguished the business machinations - re: what we have in input vs. output. (Mr. Braswell agreed with this point fully). This meeting is not trying to solve what is in business layer. 
   2. Mr. Harris: re: using existing stat plan as a means of building the plumbing. We spent months putting together auto data model. Much time being spent on trying to engineer existing stat plan. he is more concerned that plumbing itself is working from an architectural perspective. i.e., request comes in, permission gets approved, the extraction occurs and at the end of the day we have a report. In his mind: just the plumbing. Called for us to go back to the data model we have and into which we invested a great deal of time. Argued this is most pertinent. 
   3. Mr. Braswell: to Mr. Harris's point this is much more of an architectural concern, but idea of using stat plan to move things forward and make sure it all works is an excellent one. 
   4. Mr. Antley: having a great challenge making desired outputs from inputs. Mr. Harris: it works in AAIS with existing stat plan. Why can't it work in idl?
   5. Mr. Braswell: this is expressly an architectural question. AAIS work involves many workflow steps - this needs to be respread out now over source and destination.
   6. Mr. Sayers: extraction pattern has been broken up into multiple levels to get it to work in AAIS. Putting all of those layers into one extraction pattern is extraordinarily complicated. 
   7. Mr. Madison: there is already considerable work (modeling) going on in transformation from left (input) to right (output) - two things happening simultaneously. if we knead them together it gets muddied.  One of questions: what are rules happening in middle layer. Another what is technical design of this that allows efficient adherence to those rules?

...

1. 1. Clarity of the rules

...

1. 1. is a critical question and needs elucidated. It is possible to

...

1. 1. overengineer any model

...

1. 1. : no such thing as a right level normalization. 0-6 with one layer in the middle with 8 levels. We need to clarify what we are trying to achieve. It is necessary to have the logic in the middle layer, and data structure and technology in the middle. Middle layer contains modeling but also business rules. We can't mash these together.
   2. Mr. Braswell: with this in mind, we have to identify elements on right side that are not carbon copies, and that require additional legwork for transformation
   3. Mr. Madison: this is question. Not a single straight move of data left to right in every case, for instance, consider earning premium, and developing losses. These are more byzantine. We should identify these elements.
   4. Mr. Antley: is there any single straight move? Others: straight moves would include summing/aggregates. So yes there are. 
   5. Mr. Madison: maybe from a business perspective, but less of a straight move from Mr. Antley's perspective however when we are summing across 13 different tables.

...

Discussion items

...