Page History

...

• Jeff Braswell (openIDL)
• Mason Wagoner (AAIS)
• Peter Antley (AAIS)
• Brian Mills (AAIS)
• Dale Harris (Travelers)
• Greg Williams (AAIS)
• Josh Hershman (openIDL)
• Kelly L Kemp (
• Michael Payne (AAIS)
• Reggie
• Susan Chudwick (Travelers)
• Aryan (AAIS)
• Patti Norton-Gatto
• Ash Naik (AAIS)

Minutes

I. Opening Items - Peter Antley called the meeting to order, welcomed everyone, and acknowledged the LF Anti-Trust Statement.

II. Agenda

A. Mason's work - recap - Error message page - with OLGA

1. Peter's team has started pulling up errors onscreen
2. He's been working on their load - loading a couple million stat records
3. Arian is working on the validation engine
4. They have a very basic page where errors are listed - more features will be added in 2 weeks
5. After error page is live, in-line editing will be tied in with the errors - all this will be linked with the validation engine, so that when someone updates a row, Peter's team can remove any applicable errors that may be involved.
6. RRDMWG meeting again in two weeks - should have much more functionality surrounding the error table at that time. Then toward the end of the month validations should be working.
7. They will then have a test environment set up, so attendees of the RRDMWG can click around in it and explore - user testing, etc. End of this month or early September

B. NE Cat PoC

1. Peter shared briefly the data standard developed for this - draft document - Loss Transactions
2. Work itself should be relatively simple
3. Cat event has yet to be determined - Hurricane Sandy and Hurricane Zeta have been discussed but not committed to. (Note: Isaias was later decided on given related data retrieval issues - see B7 below)
4. Existing stat plan will be used - and previous stat records will be used for most companies. But for participating companies that haven't produced these records before for the event in question, they will use a simple form that Peter pulled up in the meeting
5. These parties will be asked a series of straightforward questions:
   1. Line of insurance (so that the team can track this)
   2. County code
   3. Transaction code
   4. Loss amount
   5. Cause of loss
   6. Occurrence state
   7. Occurrence identifier
   8. Claim number
   9. Catastrophe indicator - some lines needed to be added around this. Currently only in 1 position.
6. Much of information has been taken from original stat record and "pared (or trimmed) down." 
7. An extended discussion took place regarding the challenges of pulling the data wrt Sandy c.2012  - the carriers may not have access to this data. This is a fundamental issue that needs to be addressed. Carriers spoke at length about the difficulty of retrieving broad enough data from an event 11 years old. 
   1. Peter clarified the data we need to move forward with this per above and noted that transactional data is needed
   2. Carriers in meeting also noted the difficulty of doing reporting on a monthly basis given the amount of time required for turnaround.
   3. Information that Peter laid out - carriers noted that it is provided for cat events by claims department, not provided as part of statistical records.
   4. Probably necessary to involve claims dept and statistical reporting divisions
   5. Also noted, however, that this is more a matter of increased frequency than a whole new process. Monthly level of granularity should be sufficient for the purposes of this PoC.
   6. Re: 'closed' versus 'not closed' question - typically a transaction is received that has a zero outstanding loss. The period of time where there are not outstanding loss transactions leads to an assumption that this claim is closed - this is the default assumption. Any claim that has an outstanding loss associated with it is considered option.
   7. It was also noted that for purposes of the RRDMWG this is a much higher priority topic than OLGA and should be given the front seat to that.
   8. If Zeta is used (2020 event) this is fine; data is more available for this. It just needs a Cat indicator, this must be filled out somehow.
8. It was also noted that we need to be careful conflating accident date (date that the claim/incident occurred) and occurrence, which can span multiple days - occurrence = span of Cat event itself. Is there a way to single out these are the (x event - Sandy?) claims? These are the data claims? Might not be in the stat format. 
   1. There are Cat Codes that serve as the de facto industry standard, but that isn't referenced anywhere in the current table. Will we come up with our own definition - i.e., so that if we have an extraction pattern where there is a Cat Data call - is that pattern reliant on a specific cat code, or is it a range of dates, locations and causes of loss, that we define or that the Cat data call has defined?
   2. Answer: this is To Be Determined.
   3. It was noted that the group has access to a pre-made Cat code, but there is internal opposition to using it. 
   4. The way it is done today: the state issues a Cat data call, all the insurers say "here is the information I need to provide,"  they will independently go through their claims and say yes, these are the claims pertaining to x event and that's the data I will include in my call, and respond with the claims I deem as x event claims. The challenge is that carriers may have different definitions (despite the same Cat code) for what does or doesn't pertain to a specific catastrophic event. Question was raised of whether we should have the regulators define this tightly.
   5. Peter: we don't have a strong cat code we can pull from, so we're going with an optional boolean on 146, to say "do you consider this part of the cat claim for purposes of the PoC." (This solution is fine for 1 PoC but won't necessarily be useful if we extrapolate to multiple PoCs).

III. Logistics of RRDMWG

A. Meet in two weeks for now and think of how we're doing to deal with the Cat PoC off-meeting

B. Think of eventually returning to a weekly cadence for the RRDMWG

Discussion items

...