Conceptual Data Types Model Artifact Definition

Return to Artifact List

Conceptual Data Types Model

Definition and Purpose

Defines a set of data types for use in constructing Conceptual Information Models. These types are independent of any particular reference model or design paradigm and are intended to be intuitive to non-technical healthcare domain experts.

SAIF Matrix Location

Row(s)

• Conceptual (CIM)

Column(s)

• Information

Prior Methodology Correspondence

HL7 has not historically published a Conceptual Data Types Model, however in the early stages of RIM development, the HL7 MDF (Message Development Framework) did have a concept similar to Conceptual Data Types called Attribute Types to provide initial typing for RIM attributes before the HL7 Abstract Data Types specification had been fully defined. The initial draft of Conceptual Data Types will likely draw on this source.

Audience

Health Care Community Audiences:

• Health care practitioners
• Health system administrators

Health Care Semantic Analysis Audiences:

• Business Analysts: Map requirements to models (or system requirements)
• Informaticists: Select and differentiate between information models and terminologies
• System analysts: Map system requirements to specific technical solutions

Health Care Information Technology (IT) Audiences:

• Standards developers and standards development organizations
• System designers and architects
• Education/Research

Applicability

There should be exactly one Conceptual Data Types Model for use by all of HL7 International, affiliates and other implementers.

Rationale: The set of types needed is not large and, because they are conceptual, do not require realm-level refinement. By standardizing on a single model, consistency can be established across conceptual models reducing the learning curve for new entrants.

Requirements, Relationships and Content

1. Must be able to create uniquely named types
   1. Rationale: Allows the types to be referenced within Conceptual Information Models
2. Must allow detailed description of the semantics and intended use of the type
   1. Rationale: Ensures consistent interpretation of the type
3. Must allow guidance on what "additional considerations" should accompany data elements referencing a given conceptual type. E.g. "Is uncertainty relevant?"; "Might translations be needed?", etc.
   1. Rationale: Helps guide the requirements capture process without causing data type selection to encroach on the design space through the creation of detailed descriptions of data type components

Relationships and traceability

• MAY resolve to 1..* datatypes from a Logical Data Types Model
  • Rationale: Identifies candidate types that could be used in place of the conceptual type when migrating to a logical design. Also helps clarify the depth and breadth associated with a given conceptual type.

Artifact types that may or must relate to this artifact types:

• Conceptual Information Model

Content

• Name - A short, intuitive label for the type
• Description - Explains the meaning of the type with easy to understand, non-technical terms
• Requirements Considerations - Lists questions that should be considered when referencing the type
• Naming Guideline - Identifies the pattern that should be used (generally a suffix) for attributes referencing this type
• Corresponding types - Lists logical and implementation types that might be used for this conceptual type. For example, UML simple types, schema types, HL7 Abstract types

Artifact Technology

UML Class model

Rationale

• Conceptual Information Models are created as UML class diagrams. Alignment will allow for tight referencing between the information model and referenced types
• Required data elements can be captured as part of the UML annotation and using tags.

Alternatives

Word document

• Slightly easier to author, but no ability to easily enforce or check use within Conceptual Information Models

Content Constraints

1. Name must be unique
   1. Rationale: Ensures referencing can be performed
2. Description is mandatory
   1. Rationale: Ensures data type is understood
3. No use of relationships (including generalization) or definition of attributes/properties
   1. Rationale: The purpose of Conceptual types is to categorize attributes, not to provide detailed design. Selection of specific properties and typing of those properties as well as dealing with inheritance hierarchies is a design step that will occur at the logical level

Content Guidelines

1. Names and descriptions should be intuitive to non-technical healthcare domain experts
   1. Rationale: This is a primary requirement for logical artifacts

Publishing Representation(s)

1. HTML or PDF document
   1. Rationale: That's the easiest way to read the content and expose tag information
2. XMI
   1. Rationale: Allows the types to be used by others within UML tools

Publishing Constraints

1. UML descriptions must follow a pre-defined template with formatted labels
   1. Rationale: Allows content to be parsed and rendered as HTML or PDF

Tooling Considerations

1. Nice-to-have: Ability to validate references to HL7 data types
   1. Rationale: Ensures that Conceptual and Logical specifications remain in sync
2. Nice-to-have: Ability to cross-reference list of logical datatypes to ensure they all have some sort of home in the conceptual model
   1. Rationale: Ensures consistency between models and ensures all necessary concepts are addressed by conceptual model

Development Process Considerations

1. This specification will be created and maintained at the HL7 International level. Once approved it is likely to be quite stable
   1. Rationale: No reason for realm or implementation-specific variants.
2. This would be a candidate for ISO standardization
   1. Rationale: There's nothing in it that is specific to HL7 and other organizations are likely to have a similar need for conceptual types.

Artifact Exchange and Version Management

Content will be managed as XMI 2.1.

Authoring and Maintenance Tools

The datatype model will be maintained using a UML tool to be determined.

Governance Process Considerations

1. Approval - The specification will be approved through a normative track ballot process, possibly as a JIC work item
   1. Rationale: This specification will be binding on all HL7 designs and may have relevance outside of HL7 as well.

1. Conformance - Conceptual Information Models will be conformant to the Conceptual Datatypes Model if all attributes in the Conceptual Model are bound to types defined in the Conceptual Datatypes Model
   1. Rationale: That's what a datatype model is

Issues

• Not clear if we need a MIF representation of this artifact. If not, we'll need a set of rules that enforce constraints on the XMI