Analysis Information Model Artifact Definition

Return to Artifact List

Analysis Information Model

Definition and Purpose

A Conceptual Information Model captures, documents and permits review of domain understanding and requirements in terms of primary data concepts, their relationships and their properties.

SAIF Matrix Location

Row(s)

• Conceptual (CIM)

Column(s)

• Information

Audience

Everyone – This artifact should be accessible and understandable for clinical and other domain experts as a means of understanding, validating and mapping the content of a domain to their own representations. As a requirements source and principle target for mapping from the platform-independent level, the artifacts will also see heavy use by modelers and implementers.

Applicablity

This artifact is required for all projects that will be producing Information Models at any other layer of the SAIF matrix (PIM or PSM).

Rationale: The Conceptual level is the level targeted at most business experts. For other levels to be understandable and useful, this level must exist.

Requirements

1. Must be able to capture descriptively named structures, properties within those structures and relationships between structures
   1. Rationale: That's what makes this a "information" analysis model
2. Must be capable of including definition/data dictionary information about each structure, property and relationship
   1. Rationale: Names are not sufficient for semantic disambiguation
3. Must be capable of (separately) including or referencing the requirement/rationale driving the inclusion of each structure, property and relationship
   1. Rationale: Traceability of *why* a particular data element is necessary/relevant is essential in understanding and maintaining the model
4. ?Must be capable of identifying rough quantitative relationships for associations and properties such as "always" vs. "sometimes" and "one" vs. "many"
   1. Rationale: Optionality and cardinality are an important part of the semantics of a model
5. Must be expressible (excluding definitions and rationale) in diagram form
   1. Rationale: Diagrams are more quickly reviewable, navigable and comprehensible than text or tabular representations
6. Should be framed in the context of dynamic business requirements (e.g., use cases, activity diagrams)
   1. Rationale: Processes provide clear scope for what belongs in the model and what does not

Relationships and traceability

• Conceptual Information Models may exist in a refinement hierarchy from general to more specific Conceptual Information Models.
  • Rationale: Traceability will be required between data elements in a Conceptual Information Model to those that it is derived from
• Conceptual Information Models may reference elements from other Conceptual Information Models
  • Rationale: Efficiency of design and consistency across designs
• Conceptual Information Model elements may also be associated with formally defined requirements
  • Rationale: Provides traceability to manifested requirements
• Conceptual Information Model elements may have traceability to RIM model
  • Rationale: Provides formal grounding of semantics
• Conceptual Information Model attributes may reference Concept Domains
  • Rationale: Provides consistent definitions of terminology spaces across models and elements
• Conceptual Information Model attributes have Conceptual Datatypes as types
  • Rationale: Conceptual models need datatypes at a different level of detail than logical or implementation levels
• Conceptual Information Models or portions there-of will be referenced by conceptual computational models
  • Rationale: Links behavior to the structures the behavior manipulates
• Conceptual Information Model elements may be referenced by storyboards and/or use-cases
  • Rationale: Identifies the information structures being referenced and helps ensure consistency of conceptual layer
• Logical information models (DIMs and SIMs) and the elements in them will have traceability to Conceptual Information Models and elements
  • Rationale: Traceability from Conceptual to Logical

Artifact Technology

Conceptual Information Models will be represented for all HL7 specifications using UML Class Diagrams.

Rationale

• Meets all requirements
• Widely understood by modeling community and implementer community
• Lots of tools available, including open source
• "Learnable" by most clinicians
• Ties into many other aspects of the development process, hopefully simplifying mapping and certainly simplifying tooling

Alternatives

Concept map

• Easier for clinicians to understand
• When viewed through tools, provides nice "exploration" view
• Doesn’t have the same familiarity to the user community
• Doesn't have the same integration through tools
• Does not embody the same kind of commonly understood conventions -- every mind map instantiates a new metamodel for its readers to learn
• Most products do not support cyclical relationships or multiple perspectives -- they use a single hierarchy

Content Constraints

1. UML content must include the following elements:
   1. Classes
   2. Associations (including generalizations and compositions)
   3. Attributes
   4. Descriptive text, including notes on the diagram
   5. Rationale: That's all we need to meet requirements.
2. Association ends and attributes will capture business-friendly names and cardinalities (limited to 1, 0..1, * and 1..*). Names will follow a convention to identify the approximate datatype (coded, boolean, name, etc.)
   1. Rationale: The names are needed to expose semantics and cardinalities are needed to meet requirements above. Selecting specific datatypes is premature, but categorization is a key element of business semantics.
3. Coded elements must include a tag identifying the associated concept domain or must provide an in-line definition of the concept domain, meeting concept domain requirements (including provision of examples). In situations where the expected enumeration of concepts is small, the attribute may link to an explicit enumeration of "display names" for the desired concepts.
   1. Rationale: Exposing the intended use of coded elements including types of codes and approximate granularity is essential to understanding a model.
4. Other UML capabilities including stereotypes, tags, etc. are prohibited except as described below
   1. Rationale: Allowing additional elements breeds inconsistency and increases issues for training users and readers, importing content into tools, etc.
5. Text will be split into two pieces to handle definitions and rationale
   1. Rationale: Definition and rationale are distinct things and we will need to render separately
6. Tags must be used, where appropriate, to link elements within the information model to formal requirements that are manifested or dealt with by the element
   1. Rationale: There needs to be traceability from Conceptual requirements to the Conceptual Information Model.
7. To be 'complete' (and thus eligible for balloting) Conceptual Information Models must include mappings for each element to the RIM. This could be done either by embedding tags showing the mapping or the construction of a DIM with mappings to all elements in the Conceptual Information Model.
   1. Rationale: Without such a mapping, it's not a v3 artifact, it doesn't have a semantic grounding and likely has inconsistencies and missing elements. The RIM mapping process grounds and ensures completeness and rigor of semantics.
8. References to other Conceptual Information Models are accomplished by referencing the "package" representing the other Conceptual Information Models and including the class or classes (including domain-relevant attributes) to which associations are required.
   1. Rationale: It's important to have re-use of content, even at the Conceptual level. However, a drill-down approach often hides relevant data, making understanding by business experts challenging.

Content Guidelines

1. The information model should be constructed with a viewpoint based on the intended use(s) of the artifacts created in the domain (e.g. exchange, persistence, permissions, etc.)
   1. Rationale: Models are influenced by the perspective used in creating the model. It's important that the model be constructed based on how it's going to be used.
2. The analysis information model must encompass all data elements present in lower-level models.
   1. Rationale: The Conceptual level is the level targeted at most business experts. For elements at other levels to be understandable and useful, they must map to something at this level.
3. Artifacts must be named and documented in the official language of the organization or affiliate responsible for the artifact (e.g. U.S. English for HL7 UV content).
   1. Rationale: The language needs to be understandable and reviewable by all members.
4. The information model should only incorporate content that falls within the defined scope of the domain and should reference other Conceptual Information Models when dealing with content that does not fall within domain scope. In situations where another Conceptual Information Model does not yet exist, the out-of-scope should be managed within its own package.
   1. Rationale: Scope management is important to consistency, interoperability and management of resources.
5. Definitions must include non-tautological, business-friendly explanations of the meaning of the element. They may also include examples.
   1. Rationale: It's important to have consistent content in definitions, both to ensure clear semantics and to have consistent feel to published artifacts.
6. Model constraints should reflect data available and relevant to exchange/use, not a perfect omnicient world of "what data logically exists". For example, all documents must, by definition, have an author. However, in implementations, the author may not always be known or relevant. By this rule, the minimum cardinality should be 0, not 1, to reflect the real-world requirement.

Publishing Representation(s)

• Source will be made available as XMI 2.1
  • Rationale: Developers, realms and others may need the source for import into tools, to create their own derivations, etc.
• One or more diagrams, ideally in a vector-based format for easy scaling
  • Rationale: A single diagram may be overly complex for reasonable understanding or to be reasonably viewable on a printed page. Allowing multiple diagram views of the overall model addresses this
• A text or tabular view that provides full data dictionary information for the elements in the model. The rationale should be able to be included or excluded as desired
  • Rationale: Definitions are critical for understanding the artifact. Rationale will be of interest to some users, but not all.
• Note: When made available in HTML or other mechanism with linking capability, it should be possible to navigate from diagram to data dictionary view and back
  • Rationale: Eases understandability, simplifies review process

Publishing Constraints

1. Content must be provided using XMI 2.1, valid against a Schematron to be developed (to deal with the fact that some tools aren't consistent in their use of XMI)
   1. Rationale: Need a single formal syntax to allow use with tooling and publishing
2. All UML diagrams will be imported into a standard HL7 tool and will be rendered using that one tool
   1. Rationale: Need consistency in appearance of all diagrams to create professional appearance and help create comfort in consumers. Rendering in different tools can have subtle differences

Tooling Considerations

1. Nice-to-have: Support complex annotations and business names within UML authoring tools including translations, markup and discrete annotation types.
   1. Rationale: Artifacts may need to be published with multiple languages in some countries (e.g. Canada). Markup allowing references improves maintainability
2. Nice-to-have: Profile or other tooling that enforces which elements and tags are permitted and prohibits authoring of models that attempts to use UML elements other than those permitted.
   1. Rationale: Preventing invalid content from being created is a lot easier than cleaning it up later.
3. Required: Ability to look up and create links to requirements, concept domains, RIM elements and elements from other Conceptual Information Models
   1. Rationale: Significantly speeds up authoring process, reduces errors

Development Process Considerations

• As a rule, there should not be more than one Conceptual Information Model per domain and per topic. The need for more than one such model suggests a need to split the topic or domain. It is possible that several topics may share a single model.
• As an alternative to creating the Conceptual Information Model from scratch, it may be possible (and desirable) to generate the Conceptual model as a view of the Logical model to minimize alignment and mapping issues.

Artifact Exchange and Version Management

Conceptual Information Models will be exchanged as XMI 2.1 files.

Todo: Need to determine if we need to constrain to XMI from a specific tool; identify expectations around version management

Authoring and Maintenance Tools

Todo

Issues

• We'll need to define Conceptual Datatypes