This page describes the scope of the technical POC to prove that openIDL meets the needs of the community.

A separate activity to show business value is to be established by the openIDL governing board.

High Level

• generate the report and it reconciles / matches expected
• where does the data reside and what happens to it along the way to the report
• multiple sources / pull the data / create the report

Acceptance Criteria

Architecture / Design

• documented architecture

Infrastructure Requirements

...

Support two statistical reports for personal auto - territory and coverage (?? official names ?? Peter Antley 

The reports should reconcile against actual reports generated through current processes.

Supports functional requirements outlined in section below

Show privacy and integrity of the data throughout the process.

Support multiple carriers providing sufficient data to prove scalability.

Acceptance Criteria

The high level requirements are met, the specific requirements are demonstrated.

A document of the POC is accepted by the TSC.

Functional Requirements

• 2 personal auto reports
• submission format is personal auto statistical plan (flat, positional)
• end to end process
  • data call creation
  • data call like and consent
  • extraction pattern development and testing
  • report creation

Non-Functional Requirements

• data privacy
• security
• auditable

Specific Requirements

Identify the specific requirements by number from this page: openIDL - System Requirements Table (DaleH @ Travelers)

...

General Comments

Put any comments about what should be in the POC

Business

...

Value

• cost to carrier
• cost to run
• funding model
• potential savings
• value provided
  • across potential scenarios
• likelihood of healthy community

Governance

• acceptance of this POC scope by TSC
• approval of spike work (budgeted or not)
• presentation of POC solution to TSC
• acceptance of POC results
• define path to business case and go / no go

...