Domain Analysis Model ArB

Definitions

Domain Analysis Model – In its most complete expression, a Domain Analysis Model(DAM) is a collection of artifacts at the conceptual level that represents a well-defined subject-area-of-interest. The semantics – both static/informational and dynamic/behavioral – that are expressed in the various artifacts that collectively define a DAM must – first and foremost – be of use to domain experts and non-technical stakeholders who have a interest is seeing the DAM’s semantics explicitly and unambiguously expressed using standardized, understandable representations (e.g. UML diagrams, concept maps, etc.). In its most complete form, however, the semantics of a DAM must also be of sufficient robustness to enable the development by architects, designers, and developers of “down-stream” logical artifacts/models which are traceable from the original DAM (conceptual-level) artifacts. As such, the overarching purpose of a DAM can be summarized as: “A representation of the static and/or dynamic semantics of a subject-area-of-interest (i.e. a “domain”) in a manner that enables harmonization of the various perspectives of the stakeholders in the domain while also providing the foundations required to build logical and implementable representations of the domain.” (NOTE: a clarification of the phrase “...representation of the static and/or dynamic semantics...” is given in the following paragraphs.)

A DAM is a collection of artifacts including – but not necessarily limited to – the following:

1. Static/Informational
   1. Class diagrams
      1. attributes
         1. exemplar data types
         2. exemplar vocabulary domains, value sets, etc.
      2. relationships
      3. cardinalities
   2. Roles
2. Dynamic/Behavioral
   1. Activity Diagrams
      1. Process Patterns
         1. Process Flows are discouraged as being too organization-specific
      2. Capabilities
      3. Associated static structures
   2. Interaction/Collaboration/Sequence diagrams
   3. State diagrams
      1. NOTE: there is no “standard” representation required for any of the above artifacts, i.e. although UML is often used as the lingua franca to express these semantics, other representations for specific semantics (e.g. RDF graphs, concept maps, etc.) are equally viable to UML assuming the expressiveness of the two different representations is equivalent from a traceability perspective.
3. 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:
   1. Relevance: this 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 and relevant” if it serves the purpose for which it was intended by the stakeholders, e.g. “document the static (informational) semantics of the domain”.
      1. A DAM may be deemed to be “relevant” by its stakeholders without being fully “conformant” according to the following definition:
   2. Conformance: this 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.
      1. For example, 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 conformant” to the formal definition/specification of a DAM.
4. For balloting purposes:
   1. DAMs that are deemed “relevant but not fully conformant” may be submitted for INFORMATIVE balloting.
   2. DAMs that are deemed both “fully conformant” may be submitted for NORMATIVE balloting.
   3. NOTE: DAMs submitted for NORMATIVE ballot should – in all but markedly exceptional cases – have passed through Draft Standard for Trial Use (DSTU) status. In order for a DAM to be balloted as a DSTU, it must have AT LEAST TWO TRACEABLE LOGICAL MODELS THAT HAVE BEEN DERIVED FROM IT.
   4. A DAM that is submitted for either DSTU or NORMATIVE balloting must also contain specific CONFORMANCE STATEMENTS that enable traceable logical models to be evaluated for the “derivational correctness,” i.e. their COMPLIANCE to the semantics of the source DAM.

Requirements of a DAM

Following are the requirements for a fully conformant DAM that, as such, qualifies for submission to either DSTU or NORMATIVE ballot (noting the above additional requirement for DSTU submission). It is assumed that such a DAM would also be viewed by its stakeholders as relevant and therefore qualified for submission for INFORMATIVE ballot A fully conformant DAM:

1. SHALL declare the rationale for creating or extending the DAM, including reference to uses cases or capabilities intended to be achieved using the DAM.
2. SHALL be understandable by the reader without requiring access to other content protected by intellectual property rules.
3. 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.
4. SHALL explicitly define its stakeholders.
   1. Suggested categories including
      1. primary users of the DAM
      2. domain experts
      3. developers
      4. QA
      5. maintainers
      6. secondary users of the DAM
      7. initiators (strategic)/motivators for DAM’s development
      8. payers for the DAM
      9. regulators affecting DAM’s content
5. SHALL focus on the conceptual-level semantics
6. SHALL contain references to other material used to create it.
7. SHALL have a traceable path to each domain requirement statement.
   1. NOTE: There is no criteria for how many requirements "sufficiently define" a given domain-of-interest. Rather, if a given requirement -- which can be expressed in a number of ways including storyboards, use cases, or specific requirements statements -- exists, a DAM shall have a traceable path from a static and/or dynamic DAM element (or elements) to the requirement.
8. SHALL contain specific conformance statements that provide implementers of the DAM -- i.e. groups that use a given DAM to develop a specific DAM-derived logical model -- a testable, verifiable metric for determining whether the DAM-derived logical model is, in fact, conformant with the source (conceptual level) DAM.
9. SHALL be understandable by subject matter experts that were not present during the development.
10. MAY
    1. specify data type bindings either specifically or as exemplar bindings: if so, the definitions must be contained in the model or referenced from a publically available source.
11. MAY indicate logical constraints useful in generating traceable logical artifacts as needed. However, a DAM should NOT focus on implementation issues but rather aim to be implementation-independent.
12. SHOULD NOT
    1. 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.

Status

• Presented to TSC 2012-04-18 for review
• Presented to TSC 2012-05-12 for decision - none made
• Presented to TSC 2014-02-17 with request from TSC to ballot draft for comment in the next cycle.
• Balloted for comment May 2014 as "HL7 Specification: Domain Analysis Model Specifications and Requirements - Canonical Definition, Release 1 "