Date

Positions 104-109 do not explicitly say that they are commercial auto, but when Peter looks at the different classifications they are using, they reflect this line
Peter will therefore delete the commercial content from classification codes - set about deleting multiple pages
He also deleted Michigan (21) from Exception Code A - these are all commercial. Also deleted New York (31) taxicabs and public library - also commercial.
Private Passenger Non-Fleet Retained
Penalty Points/Surcharge (108-9) Retained
Assigned Risk Coding - Auto Stat Plan-Extended Discussion

B. Discussion of SDMA Uploading in EBCDIC Format - Peter asked if this is an older relic that should be removed. Group: revised date in the lower right corner means it should still be there. (Peter agreed with this as a rule of thumb). Point raised that openIDL needs to be able to receive both ASCII and EBCDIC formats.

C. Discussion of Acceptable File Formats - raised by Peter - txt zip and pgp, but for mvp for this application, what file types should be supported? Zip files a necessity or only text files? (result of this question inconclusive in meeting).

D. Statistical Data Management Application Basics - Section 2. Peter highlighted this section, because it describes how to work with the SDMA. Highlighted it, for now, because it needs to be addressed, but until loading application is set up, it will be difficult to write the instructions for it.

Peter noted that he will clean up the document and then have Tornquist go through it, then post next week on the wiki.

Noted that functionally we will be closer to the GT2 but functionality will be much closer to the SDMA

E. Project Roadmap

Imperative for running openIDL: a way to submit data, run editing packages, inform in-line editing, and submit to the HDS so that it is ready for reporting.
Mason and Peter developed a project roadmap in 8 phases:
1. Phase 1: Gathering Current Functionality (This is ongoing right now - in April applies to both the SDMA and GT2 (identifying gaps and issues)
  1. Carrier input (likes, dislikes, needs, wants, etc.)
  2. Login
  3. Landing Page - login, and can see a list of all the submitted files, so base of operations
  4. Upload Data
  5. Run Validations in an Event Driven Way
  6. Editing of Single Records and Bulk Updates
  7. Run Validations Again - Make sure it's under error threshold
  8. Submission of data - which will move data from staging in the upload application into the actual HDS so it can be used in reporting, pending approval of extraction pattern
2. Phase 2: Identifying Gaps/Issues
3. Phase 3: Solution Discussion
4. Phase 4: Pixel Perfect Mockups (clear sense of what we're going to build)
5. Phase 5: PoC API/Database
6. Phase 6: PoC UI/UX React
7. Phase 7: Production Migration Plan
8. Phase 8: Production/Deployment
Application Requirements
1. Login
2. Upload P&C Insurance (Local-→OLGA) openIDL Loading Graphical Applications
3. Running Validations (Edit Package)
4. Review Validation Errors
5. Review Records
6. In-Line Record Updating
7. Bulk Record Updating
8. Submit P&C data OLGA-→HDS.
Questions
1. Susan: Do we have the capability when we review the validations - are there reports we will review and download if we need to, into our own space? Peter: yes, would like to set up/explore customizable workflows.

Discussion items

Time	Item	Who	Notes

Attendees

Minutes

Action items

Browser not supported