Versions Compared

Old Version 2

changes.mady.by.user Nathan Southern

Saved on

compared with

New Version 3

changes.mady.by.user Nathan Southern

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date



This is a weekly series for The Regulatory Reporting Data Model Working Group. The RRDMWG is a collaborative group of insurers, regulators and other insurance industry innovators dedicated to the development of data models that will support regulatory reporting through an openIDL node. The data models to be developed will reflect a greater synchronization of data for insurer statistical and financial data and a consistent methodology that insurers and regulators can leverage to modernize the data reporting environment. The models developed will be reported to the Regulatory Reporting Steering Committee for approval for publication as an open-source data model.

openIDL Community is inviting you to a scheduled Zoom meeting.

Join Zoom Meeting
https://zoom.us/j/98908804279?pwd=Q1FGcFhUQk5RMEpkaVlFTWtXb09jQT09

Meeting ID: 989 0880 4279
Passcode: 740215

One tap mobile
+16699006833,,98908804279# US (San Jose)
+12532158782,,98908804279# US (Tacoma)
Dial by your location
        +1 669 900 6833 US (San Jose)
        +1 253 215 8782 US (Tacoma)
        +1 346 248 7799 US (Houston)
        +1 929 205 6099 US (New York)
        +1 301 715 8592 US (Washington DC)
        +1 312 626 6799 US (Chicago)
        888 788 0099 US Toll-free
        877 853 5247 US Toll-free
Meeting ID: 989 0880 4279
Find your local number: https://zoom.us/u/aAqJFpt9B

Attendees

Goals

A. Stat Plan

  1. Recap
    1. Mr. Antley discussed the Test Data Set following Dr. Harris's work on this set in Excel - calculation of EP, etc. 
    2. Mr. Antley evaluating where Dr. Harris's records and his work have diverged. 
    3. New business rule recently identified
  2. Outstanding Records 
    1. Multiple records - same coverage and same Occurrence Identifier, and different values for the outstanding. Currently: picking largest outstanding value. (Latest is unavailable).
    2. Data is heavily modified but not duplicated. Not recent data. 
    3. Question raised: should we have business rules that identify issues with records? (Group Discussion)
      1. DH: we shouldn't accept it if we can't trace specific loss to a particular entity
      2. JT: If claimaint field isn't completed and 5 records can't be distinguished, these should be tagged as errors
      3. PA noted that this is older data from a company no longer in business - we can develop a rule to tag specific pieces of data that may be tied to SDMA issues
    4. Dr. Harris noted that he is creating expected values - litmus test seeing if PA can match/align with his values.
    5. PA: will define a rule to use for testing, a claimant, and also may define a rule to test per SDMA. We want to be able to do checks that span multiple rows
  3. Conclusions
    1. We will continue to use the big one
    2. We will develop rules that span multiple rows

B. Work recap - AWG

  1. Spike POC - focused POCs to validate various modules to be used in openIDL
  2. Looking into moving into relational database. Utilizing postgreSQL 
  3. KS: decision making brought to TSC. Agreed that AWG will draw arch. schema - decisions will be made within this group (e.g., HDS/relational database). Supporting documents will bely key decisions.
  4. Large decisions will command a vote. All decisions will be documented.
  5. PA discussed relational database - we will have 2 tables/line. 1 tbl premium records, and 1 loss records. Clean tabular design. Possible index added to tables as we are loading, w/a primary key for each record. This will provide easier tracking mechanism
  6. PA. Premium Table
    1. We're looking at adding Annual Statement Line (optional) - which raises key questions about how to handle #. (Raised as question for group)
    2. KS: suggested taking # as a string (as is) not as a #. (PA agreed).
    3. PA: everything (including Zip code) is VARCHAR except for 'Date'
    4. PA: for numbers, we're using numeric.
    5. JM: sought to discuss nature of identifier in field, as this is a querying type table not a loading type one. This table may be what we query from. KS: This is the first level of basic structure that will be in HDS. 
    6. JM: the challenge w/numeric: if you make it a sequence, you get into parallelism problems, gaps in it, etc. Especially if carriers are providing the sequence. (JM: this is only looking ahead, not a problem necess. to deal with right this moment).

C. Review of postscript progress

  1. This table set up 
  2. Loss record next week
  3. ETL - we will load up all premium records from test data set 




Discussion items

TimeItemWhoNotes




...