Domain Analysis Model ArB

This page is one of the ARB work items. NEW definition To be approved at the May 13, 2012 Face-to-face meeting:

• A Domain Analysis Model(DAM) is a collection of traceable artifacts at the conceptual level that represent a subject area of interest the purpose of which is to harmonize the perspectives of the stakeholders and inform work required to build logical and implementable representations of the subject.
• For a given collection of artifacts claiming to be a DAM, there are two perspectives that must be considered relative to the type of HL7 ballot to which those artifacts may be submitted:
  • completeness: Completeness is a subjective metric that reflects the collective judgment of the domain experts for whom the DAM was built. A given DAM may be considered by these stakeholders to be complete if it serves the purpose for which it was intended by the stakeholders, e.g. “document the static (informational) semantics of the domain. A DAM may be deemed to be “complete” by its stakeholders without be fully “correct.” DAMs which are viewed as “complete” by their respective stakeholders may be submitted for INFORMATIVE ballots but may NOT be submitted for NORMATIVE balloting.
  • correctess: Correctness is an objective metric used to evaluate the collective semantics of all of the artifacts labeled as a DAM for a given domain. Specifically, the metric refers to degree to which the artifacts have documented both the static (informational) and the dynamic (behavior) semantics of the defined domain. A given DAM may include “just” an informational (or behavioral) model and be considered “complete” by the domain experts for whom it is intended. However, without the additional inclusion of the accompanying, inter-related behavioral (or informational) model, the DAM cannot be considered to be “fully correct.” Only fully correct DAMs may be submitted for NORMATIVE balloting.
• Following are the requirements for a fully correct DAM. It is assumed that such a DAM would also be viewed by its stakeholders as complete.
  • SHALL declare the rationale for creating or extending the DAM, including reference to uses cases or capabilities intended to be achieved using the DAM.
  • SHALL be understandable by the reader without requiring access to other content protected by intellectual property rules.
  • SHALL have a definition of the shared purpose scoping the domain including the rationale for creation or extension, including reference to use cases or capabilities intended to be achieved using the DAM.
  • SHALL explicitly define its stakeholders.
    • Suggested categories including
      • primary users of the DAM
      • domain experts
      • developers
      • QA
      • maintainers
    • secondary users of the DAM
      • initiators (strategic)/motivators for DAM’s development
      • payers for the DAM
      • regulators affecting DAM’s content
  • SHALL focus on the conceptual-level semantics
    • MAY have logical constraints as needed but should NOT be focused on implementation issues
  • SHALL contain references to other material used to create it.
  • SHALL be understandable by subject matter experts that were not present during the development.
• A DAM MAY
  • specify data types: if so, the definitions must be contained in the model or referenced from a publically available source.
• A DAM SHOULD NOT
  • include logical and/or implementable artifacts that distract from the clarity
    • e.g. Foreign key constraints.

Note on evolution of a DAM: The ArB recognizes several types of evolution of a DAM including:

1. change in scope/boundaries
2. change in existing semantics
3. addition of new semantics (within original scope/boundary definition)
4. change in representation of existing semantics

Only changes of types 1 and 2 should affect the “compatibility” of a given DAM and therefore require a new ballot cycle.