Refinement, Constraint and Localization
Modeling & Methodology Co-Chair / George Beeler Jr PhD.Beeler Consulting LLC
Primary Contributor / Sandy Boyer
Consultant
Conformance Co-Chair / Lisa Carnahan
National Institute of Standards
Modeling & Methodology Co-Chair / Jane Curry
Sierra Systems & CIHI - HL7 Canada
Internat'l Technical Committee, Co-Chair / Leo Fogarty, MD?
Modeling & Methodology Co-ChairConformance Co-Chair (outgoing) / Mary Ann Juurlink
Canada Health Infoway Ann Hueber
PAML
Primary Contributor / Lloyd McKenzie
IBM Canada, CIHI - HL7 Canada & Alberta Wellnet
Modeling & Methodology Co-Chair / Dale Nelse
Zed-Logic Informatics, LTD
Conformance Co-Chair / Jennifer Puyenbroek
McKesson Information Solutions
Conformance Co-Chair (interim) / Peter Rontey
U.S. Department of Veterans Affairs
Modeling & Methodology Co-Chair / Abdul-Malik Shakir
Shakir Consulting LLC
Conformance Co-Chair / Ioana Singureanu
Eversolve, Inc.
HL7® Version 3 Standard, © 2004 Health Level Seven®, Inc. All Rights Reserved.
HL7 and Health Level Seven are registered trademarks of Health Level Seven, Inc. Reg. U.S. Pat & TM Off
Table of Contents
1 Introduction1.1 Overview
1.2 Refinement process
1.3 Constraint Process
2 Constraints
2.1 Appearance constraints and cloning
2.1.1 Mandatory Inclusion Flag
2.1.2 Conformance indicator
2.1.3 Cloning classes
2.2 Cardinality constraint
2.2.1 Cardinality
2.3 Type constraints
2.3.1 Data types
2.3.2 Common Message Element Types (CMETs)
2.4 Vocabulary domain constraints
2.4.1 Vocabulary domain
2.4.2 Coding Strength
2.5 Other value constraints
2.5.1 Default value
2.5.2 Textual Constraints
3 Constraint Profiles
3.1 R-MIM refinement
3.2 Other forms of constraints
3.2.1 Conformance Indicator
3.2.2 Data Type Constraint
3.2.3 CMET Constraint
4 Conformance Statements
4.1 Conformance Overview
4.2 Conformance Statement Work Products
4.2.1 Vocabulary Conformance
5 Localization
5.1 Localization Overview
5.1.1 Target audiences
5.1.2 Approval Processes
5.1.3 Organization of section
5.2 Information models
5.2.1 RIM
5.2.2 R-MIM
5.3 Type structures
5.3.1 Data types
5.3.2 Message types
5.3.3 CMETs
5.4 Vocabulary
5.5 Interaction design elements
/
1
/Introduction
1.1
/Overview
The Version 3 Messaging standard provides a rich set of messages to support communications in a variety of clinical and other health related endeavors. Moreover, HL7 Version 3 messages will be specific enough to permit strong conformance claims to be asserted and verified. Refer to Conformance Statements (§ 4 ) for more details. Nevertheless, any standard faces two challenges. First, it can always be made more specific in order to provide a precise solution to a particular requirement. Second, it will not contain all of the data needed in every environment, particularly when international requirements are considered. These challenges lead to a pair of complementary requirements: the ability to constrain the standard in more detail, and the ability to extend the standard in a controlled fashion.The Constraints (§ 2 ) section documents, in a normative fashion, what the HL7 Technical Committees are permitted to do as part of the Version 3 Refinement process (§ 1.2 ).
Intertwined with the notions of constraining and extending the standard are two critical capabilities – the ability to establish a testable statement of conformance to the standard, and the ability to create a "profile" of the standard that formally defines how the standard will be implemented in a particular setting.
A profile is a set of information used to document system requirements or capabilities from an information exchange perspective. The documentation is expressed in terms of constraints, extensions, or other alterations to a referenced standard or base profile. Profiles referenced in the HL7 Version 3 standard must be derived from a balloted Version 3 specification, as balloted by either HL7 or one of its international affiliates. The categories and use of profiles include:
- Annotation profiles document; it is exactly the standard but with more information (these profiles will not be discussed further here).
- Constraint profiles may contain unchanged and constrained elements.
- Localization profiles may contain unchanged, constrained, or extended elements.
- Conflicting profiles may contain unchanged, constrained, or extended elements as well as elements that violate the HL7 refinement, constraint, and localization rules (these profiles will not be discussed further here).
This document specifies the rules and principles that govern the definition of profiles, but does not state how to represent these profiles. A formal representation of profiles is required in order to allow the creation of tooling to assist in development, documentation, comparison, and testing. Such representation is outside the scope of this standard.
A Conformance Statement is documentation of the degree to which a particular application conforms to the specification. Part of that document will be a profile expressing the requirements relevant to a particular standard.
This section of the standard addresses:
- the "rules" and processes for refining the standard through constraint and extension, including which standard artifacts are subject to constraint or extension
- the definition of constraint and localization profiles
- the critieria for establishing a conformance statement
- the principles guiding who may define extensions to the standards and under what circumstances
The strategy for development of Version 3 messages and related information structures, as discussed in the Version 3 Guide, is based upon the consistent application of constraints to a pair of base specifications – the HL7 Reference Information Model (RIM) and the HL7 Vocabulary Domains – and upon the extension of those specifications to create representations constrained to address a specific health care requirement. The processes described are precisely the processes that the HL7 Technical Committees followed in developing Version 3 standards. Thus, this section also serves as a reference work for the core standard.
Just as the standard is developed using a series of constraints and targeted extensions, the design of applications to implement these messages, the definition of conformance claims, and the definition of localization specifications, will all require further constraint and extension of the base standard.
1.2
/Refinement process
The HL7 methodology uses the Reference Information Model (RIM) and the HL7-specified Vocabulary Domains as its starting point. It then establishes the rules for refining these base standards to arrive at the information structures that specify message types and equivalent structures in Version 3.The following figure shows the refinement process specified in the methodology. Each red arrow in the diagram represents an application of the processes detailed in this section of the ballot. As diagrammed, the processes are used to derive one or more Domain Message Information Models (D-MIM) from the RIM. Each such model represents the set of concepts applicable to a particular health care domain of interest.
Note to TC: These model artifact names will probably be renamed prior to publication to correlate with the HDF (when it is official).
Refinement Process for defining messages based on the HL7 RIM.
Within the domain, the Technical Committees use the same constraint process to derive one or more Refined Message Information Models (R-MIM) from the D-MIM for their domain.
Finally, the committee applies the same constraints, coupled with a traversal of the information model graph, to arrive at the specification for an Hierarchical Dessage Descriptions (HMD) and its Message Types. In reality, as discussed in the Version 3 Guide, some of the message types in a single HMD may represent a further constraint on the common, or base message type for that HMD. Although this is not shown in the diagram above, this constraint also follows the rules outlined in this section.
The fundamental rules of constraint, cloning and extension remain the same at each stage. This is true even though: the documentation of the constraints may vary stage to stage; the results may be documented in different forms; and the constraint process may be coupled with other processes, such as the graph-walk for an HMD.
1.3
/Constraint Process
The process diagram above also shows a recursive loop whereby the constraint process can be used to further refine an R-MIM to arrive at a new R-MIM to be used to define alternative messages. All of these processes will be used by implementers of the Version 3 messaging standards to define profiles of messages to be implemented. These profiles have a variety of anticipated uses. They may be:- Created by an HL7 International Affiliate organization to specify the localization of the Version 3 standards to be used in the affiliate’s region
- Used by an application vendor to document the conformance of their application to the Version 3 specifications.
- Created by a user to document the specific implementation of communications between the user’s systems.
2
/Constraints
Constraints are the central feature of the refinement process, as they reduce the generality of the specification and focus it on a particular requirement. The constraints that may be asserted against an element (attribute or association) fall into five broad categories:Appearance constraints determine whether a particular element must appear in models or messages derived from the base model, and/or whether the element is precluded from appearing therein.
Cardinality constraints define the number of repetitions that may occur for a given element.
Type constraints limit the structure or "type" of the element in question. These are constraints placed upon the data types for attributes and upon the use of Common Message Element Types (CMET) for associations.
Vocabulary domain constraints limit the set of concepts that can be taken as valid values in an instance of a coded attribute or field.
Other value constraints provide for the declaration of constraints stated as text and, optionally, as testable Object Constraint Language (OCL) expressions, to establish "business rules", and for the assertion of default values.
Annotations provide further explanations to educate prospective users and/or implementers. These are usually used to enhance the descriptions of the elements of the base specification in order to relate them to a particular context of use.
2.1
/Appearance constraints and cloning
The appearance or presence of a model element (class, attribute or association) in a constrained model depends upon the appearance constraints that are asserted in the source model, and upon the rules for "cloning" classes from the source model to the target model.There are two forms of appearance constraints that may be set in a model: the declaration that an element is mandatory for HL7 messaging; and the assertion of a conformance indicator.
2.1.1
/Mandatory Inclusion Flag
The mandatory inclusion flag indicates whether or not a particular element must be present in each instance of an HL7 message. In HL7 designs this constraint is applied primarily to structural attributes – those attributes whose coded values are needed to fully interpret the classes that they classify. According to the HL7 Methodology, if an element is described as mandatory, all message elements that are derived from this element must contain a non-null value, except that the sending application may omit the element if the default value is not null.Values
The constraint is formally a Boolean selection. If selection is true, the element is mandatory.
Invoking the constraint
Once an element is declared mandatory, all elements that derive from it, in more deeply constrained models, must also be mandatory.
2.1.2
/Conformance indicator
This constraint has one of three values. They determine whether the element must appear in each instance of a derived model or message, must not appear in such instances, or remain optional.[LRM1] Similarly, any element designated as ‘not permitted’ in a standard HL7 message definition shall also be ‘not permitted’ in all HL7 message profiles of that standard message. The only exception are balloted realm-specific message profiles which override the standard message to accommodate realm-specific needs. (It should be noted that by overriding the standard message, the realm introduces compatibility issues when communicating outside their realm.)
Values
Required - The element must appear in all instances of derived models and must be declared as "Required" in derived models. In messages, the element must be communicated if its minimum cardinality is one, although it may be communicated with a null value, unless it is also "mandatory." Note that any element declared to be "Mandatory" must also be "Required" and have a minimum cardinality of one. If the minimum cardinality is zero, and the element is "Required," conforming applications must demonstrate their ability to communicate this element when the application holds data for this element.
A conforming sending application shall populate all required elements with a non-empty value if the data exists. Conforming receiving application shall process (save/print/archive/etc.) the information conveyed by required elements and must not raise an error due to the absence of a required element.
Any element designated as required in a standard HL7 message definition shall also be required in all HL7 message profiles of that standard message.
Not Permitted - This element shall not appear in instances of derived models or messages and must also be "Not permitted" in derived models.
Any element designated as ‘not permitted’ in a standard HL7 message definition shall also be ‘not permitted’ in all HL7 message profiles of that standard message.
Not Required - The appearance of this element in instances of derived models or messages is unconstrained. In instances of derived models or messages, an element may retain "Not Required" status, or it may be declared "Required" or "Not Permitted". This is the default value for this constraint.
Note: There will be no optionality in Implementation Profiles. If an application adheres to a profile states that supports something, it willsend/receive if it has a value.
Invoking the constraint
Although the conformance constraint is represented explicitly in the diagrams of a D-MIM or R-MIM and in the tabular representation of an HMD, the "Not Permitted" value may also be expressed in a derived D-MIM or R-MIM by simply omitting that element from the derived model. Thus, an attribute or association that is not "Required" in a D-MIM may be omitted when the class is cloned in a derived R-MIM, thereby creating a de facto declaration of "Not Permitted."
2.1.3
/Cloning classes
Whenever an information model is derived by constraining another information model, it is permissible to "clone" the classes of the base model. This is true whether one is deriving a D-MIM from the RIM, an R-MIM from a D-MIM, or an R-MIM from another R-MIM.Class cloning is the creation in the new model of one or more copies of a base class contained in the source model. The clone classes may have new extensions added to the base class name in order to assure that they have unique names within the derived model.
Cloning is the only form of model "extension" permitted under the terms of this section. In order to qualify as a valid clone of a source class, the clone must obey the following rules:
- The clone may contain only attributes that are also part of the source class
- The clone may only participate in associations that are valid for the source class
- The cardinality and mandatory constraints for elements in the clone class must be at least as rigid as the constraints for the equivalent elements in the source class
- The vocabulary domains declared for any coded attributes in the clone must be identical to, or a subset of, the domain asserted in the source class, and if the coded attribute is "CNE" the cloned attribute must also be "CNE"
- The clone need not include attributes or associations unless they are "Required" or "Mandatory" in the source model, regardless of their cardinality
- The clone may not include attributes or associations that are listed as "Not Permitted" in the source model
2.2
/Cardinality constraint
The cardinality expresses the number of times an attribute or association, may appear in a derived model or message.2.2.1
/Cardinality
ValuesCardinality is expressed as a minimum and a maximum value separated by ‘..’, e.g., ‘0..1’.
The minimum cardinality is expressed as an integer that is equal to or greater than zero. If the minimum cardinality is zero, the element need only appear in message instances when the sending application has data with which to value the element. Mandatory elements must have a minimum cardinality greater than zero.
The maximum cardinality is expressed either as a positive integer (greater than zero and greater than or equal to the minimum cardinality) or as unlimited using an asterisk ("*"). If the maximum cardinality is greater than one, the type for the associated message element must include one of the "collection types" – SET, LIST, or BAG.
Invoking the constraint
Both the minimum and maximum cardinality may be constrained in a way that narrows the range of possible occurrences. Thus, either end of the cardinality range may be set to a new value within the closed range defined by the minimum and maximum values in the source model's range. Two rules further constrain a cardinality change: (a) the minimum cardinality of the resulting range must be less than or equal to the maximum cardinality; and (b) the maximum cardinality must be greater than zero.
2.3
/Type constraints
Two forms of constraints affect the "type" or semantic structure of the element in question. One applies to attributes, which are typed by data types, and the other to associations, which may be typed by Common Message Element Types (CMETs).2.3.1
/Data types
Each attribute of the RIM is assigned a base data type that represents the values the attribute may take on. The Version 3 Data Type Specification documents a set of extension and restriction relationships among the various data types. The data type specification permits constraints to be applied to the data types by substituting a restricted data type for its more general parent.The following table displays examples of the substitutions permitted in the process of constraint. Any given constraint might move more than a single step down this hierarchy. For example, a General Timing Specification (GTS) could be constrained to a simple Time stamp (TS).
Data type in source model / Allowed constraints in derived model
Data type Any (ANY) / Any of the other data types
Encapsulated Data (ED) / String (ST)
Concept descriptor (CD) / Coded with Equivalents (CE)
...Coded with Equivalents (CE) / ...Coded Value (CV)
...Coded Value (CV) / ...Coded Simple Value (CS)
General Timing Spec (GTS) / Set of time stamp (SET<TS>)
...Set of time stamp (SET<TS>) / ...Time stamp (TS)
General Timing Spec (GTS) / Interval of time (IVL<TS>)
...Interval of time (IVL<TS>) / ...Time stamp (TS)
…
Entity Name (EN) / Person Name (PN)
Entity Name (EN) / Organization Name (ON)
Entity Name (EN) / Trivial Name (TN)
Bag of type T (BAG<T>) / List of type T (LIST<T>)
...List of type T (LIST<T>) / ...Type T (T)
Bag of type T (BAG<T>) / Set of type T (SET<T>)
...Set of type T (SET<T>) / ...Type T (T)
Note to TC: If we can generate a full list of valid data type constraints, the above table will be replace by a link to that document.
2.3.2
/Common Message Element Types (CMETs)
When an information model is converted to a serialized information structure such as a message, each association in the information model will be assigned a type based upon the class or clone to which the association connects. This is analogous to the assignment of data types to attributes of the information model.Although the type for an association may be defined solely from the R-MIM that is the source for the HMD, it is also possible to constrain the association by assigning it a formally-defined type. These formally-defined types are the Common Message Element Types or CMETs.
Each CMET is based on a specific RIM class and a particular set of codes for the structural attributes (classCode, moodCode, and/or determinerCode) that characterize the class. The CMETs themselves are defined using a restriction hierarchy allowing CMETs to be constrained as part of the overall model refinement process.
CMET substitution
When a model is being refined, a CMET may be substituted for a class or a class clone, provided that (a) the CMET is based on either the same class as the class being substituted or on a sub-type of that class, and (b) the values for the structural codes for the CMET fall within the vocabulary domains specified for those attributes in the source model.
CMET constraint hierarchy
When a model or message type is constrained, the CMETs within that model may be further constrained along the defined restriction hierarchy for CMETs.
Universal CMET is the basis for the CMET restriction hierarchy. Each other level of constraint is a proper sub-set of "Universal". Thus "Universal" may be constrained to any of the other CMET types.
Detailed CMET provides sufficient information to recognize and manage a new instance of an item by loosely coupled systems. The "Identified" CMET is a proper sub-set of "Detailed". Thus "Detailed" may be constrained to "Identified".
Identified CMET provides only enough information to allow identification of the instances between tightly coupled systems. An "Identified" CMET may not be further constrained.
Abstract CMET may be used as a modeling tool, but must be substituted with a concrete type in the final model. It can be used when only the class and structural codes for the CMET are known.
Other CMET types have also been defined as restrictions on the "Universal" type. These other types may also be further constrained.
2.4
/Vocabulary domain constraints