HDS Requirements WIP

Working page to draft requirements. 

1. Business Architecture Requirements

   1. 
      
      

      
      
      

2. Strategic Architecture Requirements

   1. General

      • Must store and make accessible data elements provided by the data model working group.

      • Must conform to the OpenIDL data model standards. (?)

      Query Execution

      • Must work to maximize the simplicity of the extraction patterns.

      • HDS must be able to support arbitrary queries. Includes questions in the future that we may not yet know.

      • Extraction patterns are written against a specific version of the model.

      • Must support the state DOI, such as auto coverage and auto territory.

      • Must have sufficient performance.

      Schema Evolution

      • May only conform to going-forward models.

      • New attributes will not need to be historically filled.

      • Should allow for schema evolution with minimal impact.

      History

      • Must provide current data, defined as month end plus 45 days.

      • Must hold history according to regulatory requirements, generally defaulted to 5 years.

      Data Quality

      • Must have edits to verify data quality before being available for consumption.

      • Must have tolerances for the edits that default to 5%.

      Structural Concerns

      • Must have traceability across all layers.

      • Must provide a mechanism for model versioning.

      
      
      

3. Data Dictionary

   1. Policy

   2. Claim

4. Business Data Model

   Define…

   1. The business data model represents the entities, attributes, and relationships as understood by business users.

   2. The business data model has no regard for the implementation technology nor the processing required to load it.

   3. A data element is a singular piece of information, such as one number, one string, one date, etc.

   4. An entity is a set of data elements.

   5. A business entity is an entity that is recognizable to business users and tends to occur in conversations with them, such that the number of elements is not small enough (typically one to five) to be trivially embedded inside another entity. Policy, claim, vehicle, and home are typical examples.

   6. A relationship occurs when business users can understand the use of entity names in a sentence of the form “has a” or “has many” such as “a policy has many claims”, where “many” can include one or none, and where more semantically rich terms for “has” may be used such as “belongs to” or “contains”.

   7. The model aspires to not repeat the attributes of an entity in more than one place.

   8. The model must make it difficult to over-count elements and values.

   9. Sparsity is the measure of empty values to total number of values. For example, an entity of 100 records and 100 attributes has 10,000 cells.  If 1,000 are empty, the sparsity is is 10%.

   10. No entity when populated should have a sparsity level exceeding 10%. If that occurs, the entity should be reviewed for the opportunity to create more than one entity.  For example, an auto policy and a home policy are both policies, but have sufficiently different attributes that they could have high sparsity and warrant being two different entities.

   11. Any entity that is highly covariant with another entity may be embedded in it. g. policies have addresses.  Address can be broken out for robust handling, or it can be left inside the policy.

   12. The following are entities in the business data model:

       1. Policy – An agreement between a carrier and an insured.

          1. Auto Policy – A policy for a set of vehicles.

          2. Home Policy – A policy for a home and its related risks.

       2. Vehicle – An insurable object operated by a driver on road.

       3. Driver – A person who operates a vehicle.

       4. Coverage – A transfer of a certain type of risk.

       5. Claim – A set of events under a policy that results in payments.

       6. Claim Event – An event under a claim.

       7. More! Not exhaustive…

   13. The following are relationships:

       1. A policy has one or more vehicles.

       2. A vehicle has one or more drivers.

       3. A policy has many coverages.

       4. A policy has zero or many claims.

       5. A claim belongs to exactly one policy.

       6. A claim has many claim events.

       7. A claim event belongs to exactly one policy.

       8. More! Not exhaustive…

5. Presentation Data Model

   The presentation data model optimizes the ease of writing queries, and to do so, is willing to give up some business precision of the business data model, but is not particularly concerned about system performance, though some adaptation to the implementation model may occur.

   1. TODO: Enumerate the properties of this model.

6. Persistence Data Model

   The persistence data model is obsessed with precise preservation of truth and having flexibility into the future. It is willing to be somewhat unrecognizable to business users, and takes into account both system performance and implementation concerns.

   1. TODO: Enumerate the properties of this model.

7. Loading Data Model

   The loading data model seeks to make getting data into the system as easy as possible. It is very willing to compromise in favor of making feeds from sources easy, and TODO.

   1. TODO: Enumerate the properties of this model.