Product V3 RCL

Product Brief - Refinement, Constraint, and Localization to version 3 Messages

back to Main_Page
back to Product_List

Product Name

HL7 Version 3 Standard: Refinement, Constraint, and Localization to Version 3 Messages

Standard Category

• Health Information Exchange Standards

Integration Paradigm

• Foundation

Type

Normative, ANSI Standard

Releases

ANSI/HL7 V3 RCL: R1-2003, R2-2007;

Summary

The Version 3 standard provides a rich set of messages to support communications in a variety of clinical and other health related domains. 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 more 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. This document describes the processes whereby HL7 V3 message specifications may be refined, constrained and extended to support implementation designs, conformance profiles, and realm-specific standard. This release of the document adds clarification for rules for conformance and non-conformance senders and receivers, and rules for constraining.

Description

The Constraints and Annotations (§ 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 another profile.

Profiles of the HL7 Version 3 standard must be derived, directly or indirectly, from a Version 3 specification, as balloted either by HL7 or by one of its affiliates.

A binding realm manages the bindings/substitutions of Valuesets and CMETs (and templates and data type specializations if and when substitution rules for these are agreed) to reflect local rules. The realm is communicated by InfrastructureRoot.realmCode and determines conformance rules for vocabulary, data type, etc. Each binding realm has a binding realm owner: this organization must be an Affiliate. In some exceptional cases the binding realm owner may be a group of Affiliates (if they have an agreement to share ownership), e.g. for binding realms like 'Dutch-German cross-border hospitalisation', 'European-Indian dental tourism' or 'US-Canadian Pharmacy'.

The categories and use of profiles include:

• An annotation profile is used to further explain the base document to educate prospective users and/or implementers. An annotation profile will usually enhance the descriptions of the elements of the base specification in order to relate them to a particular context. 'Annotation profiles' document the standard with more information but these profiles will not be discussed further here.
• Constraint profiles may contain unchanged and constrained elements.

  A constraint profile reduces the optionality and cardinality of the base specification (i.e., the HL7 V3 standard) in order to make the specification more exact and to approach "plug-and-play" interoperability.

• Implementable profiles are the most constrained constraint profiles.

  An implementable profile eliminates all optionality of the base specification (i.e., the HL7 V3 standard) in order to make the specification exact and to approach "plug-and-play" interoperability. Optionality for a profile is eliminated when the conformance indicator for every attribute and association is something other than Unspecified (namely Required or Not Permitted) and every vocabulary domain is bound to a value-set. (see section 2.1.2 for conformance indicator and 2.5 for vocabulary domain)

• Conformance profiles are used to articulate a system's conformance claim to a set of interactions (or optionally application roles).

  A conformance profile can be either a constrained profile or an implementable profile.

• Localization profiles may contain unchanged, constrained, or extended elements.

  A localization profile is usually designed to meet the same objectives as a constraint profile, except that the demands of the intended implementation context mandate additional elements, as represented in the extensions. Normally, extensions will represent the minimum changes to the base specification (i.e., the HL7 V3 standard) needed to meet those requirements. Furthermore, Data Type Specializations can also be used to adapt a profile to local needs.

• Conflicting profiles may contain unchanged, constrained, or extended elements as well as elements that violate the HL7 refinement, constraint, and localization rules.

  By definition, a conflicting profile represents an implementation that cannot reliably interoperate with other implementations of the same base standard or base profile. The reason for creating such a profile is to document the incompatibilities.

The specification identifies 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 the documentation of the degree to which a particular application conforms to the specification. Part of that document will be a conformance profile expressing the system's capabilities relevant to a particular standard.

The Refinement, Constraint and Localization document 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 criteria for establishing a conformance statement
• the principles guiding who may define extensions to the standards and under what circumstances

Business Case (Intended Use, Customers)

• HL7 Work Groups,
• International Affiliates

Benefits

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.

Resources

Work Groups

Implementation and Conformance

Education

• See more at http://www.hl7.org/implement/training.cfm

Relationship to/ Dependencies on, other standards

• RIM,
• HL7 Vocabulary domains

Links to current projects in development

• none