This document (HL7 Version 2 Conformance Methodology) explains the procedures and processes for constraining HL7 v2 message specifications. This encompasses both message profiles and implementation guides that contain message profiles. A message profile provides a precise and unambiguous specification of a single message definition. An implementation guide provides a broader context in which typically a set of message profiles are used to satisfy one or more use cases. A use case may include applications (actors) and the interaction between them (interaction model), and application functional requirements.
The base HL7 v2 standard is a framework that contains many message events, and for each event it provides an initial message template (starting point) that is intended to be constrained for a specific use and context. The process of placing additional constraints on a message definition is called profiling. The resulting constrained message definition is called a message profile (also referred to as a conformance profile; hereafter message profile). Message profiles provide measurable requirements that can be used to determine the degree to which implementations are conformant. Profiles reduce or eliminate the optionality (or openness) of the base standard. An example of a constraint is changing optional usage for a data element in the base standard message definition to required usage in the message profile.
Figure 1.1 (HL7 v2 Profiling Process) illustrates the process by which a standard defined message event (e.g., an ADT^A04 message) is refined for a desired use. The message profile definition can be documented in a natural language or in a computable representation.
An HL7 v2 Implementation Guide provides a broader context that may contain a detailed specification for an interoperability solution. Figure 1.2 (HL7 v2 Implementation Guide Sample Template) presents a sample outline of an implementation guide. An implementation guide can vary in the components it will contain. Some implementation guides may contain complete workflow requirements including actors and functional requirements while others will simply focus on the interoperability aspects of a set of related interactions. An implementation guide typically will contain a narrative part (upper part of Figure 1.2) and a message definition (profile) part. Section 3 provides additional insight on the content commonly given in implementation guides.
The central aspect of an implementation guide is the constrained message definitions, i.e., the message profiles. Figure 1.3 illustrates the make-up of a message profile at a high-level. The message is embodied as a structured definition. Rules for an abstract message definition are specified in the HL7 v2 message framework, which is hierarchical and consists of building blocks generically called elements. These elements are segment groups, segments, fields, and data types (i.e., components and sub-components). The requirements for a message are defined by the message definition and the constraints placed on each element. The methods and rules for applying constraints are defined by the HL7 v2 conformance constructs (constraint mechanisms). The conformance constructs include usage, cardinality, length, vocabulary, content (non-coded), data type specialization, explicit conformance statements, co-constraints, and other constraint mechanisms. Section 5 provides definitions of the conformance constructs.
The message profile also includes the associated vocabulary bindings and definitions. Certain message elements can contain coded data. The element in the structured definition is bound to a vocabulary definition. Depending on the profile level and the specification need, this binding can be to a concept domain, code system, or value set. The vocabulary definition provides an identifier and the set of allowable content. Section 6 defines the concepts and rules for vocabulary binding and profiling.
The goal of HL7 v2 is to provide a standardized protocol for exchanging healthcare related data between two systems. Figure 1.4 (Generic HL7 v2 Interaction Diagrams) provides the basic model upon which messages are used to exchange data. Two systems or applications (generically called Actors) exchange data; this conversation is referred to as an interaction. The content of what is exchanged is defined in the message profile. As such, an interaction has a one-to-one relationship with a message profile.
The lower part of Figure 1.4 illustrates a roundtrip conversation; this sequence of events is referred to as a transaction. As shown, for each interaction a corresponding message profile is associated. An example may be actor A sending a “Register a Patient” message to Actor B. Actor B responds with an “Acknowledgement” message. Interactions and transactions can be defined in a given context and documented in an implementation guide.
This specification provides the rules and documentation requirements for profiling HL7 v2 base message definitions. It also provides guidance on how to assemble a set of message profiles to satisfy the requirements of a set of use cases documented in an implementation guide. A goal is to provide specifiers and implementers the tools to define requirements in a clear and precise manner regardless of the level of specificity they seek (e.g., national level requirements or local implementation requirements).
There are many versions of the HL7 v2 standard. An explicit conformance methodology was introduced into the standard in version 2.5 and revised in subsequent versions of the standard. The conformance methodology was part of Chapter 2 initially and later became a subchapter (Chapter 2B Conformance). This document serves to replace (override) the conformance methodology in these earlier versions and it is intended to be applied to any HL7 v2 version. That is, if a specifier is seeking to constrain a version 2.5.1 message, they must use the conformance methodology prescribed in this document and not the conformance methodology given in version 2.5.1.
Figure 1.5 summarizes the profiling process and how this document is intended to be used. The specifier has at their disposal all message events for every HL7 v2 version. Based on their needs, they select a message event to constrain. Using this specification (Conformance Methodology) and use case requirements, they apply constraints to create a message profile. This document describes this process and additionally provides guidance on effective strategies for grouping message profiles for broader context and use in implementation guides.
This specification can be used in implementation guides to document constraints on messages. It is intended to be used for new interfaces and re-specification of existing interfaces. Though use of the conformance methodology in the production setting is optional, its use is recommended. For any newly balloted HL7 v2 implementation guides, however, its inclusion is required. The specifier can choose to use as many of the constructs that are defined in this specification as they deem appropriate. Additionally, they can choose to specify profiles at a highly general (considerable openness) or very detailed level (no optionality). See Figure 1.6. The choices are dependent on the intended use of the implementation guide. Implementation guides that are too specific have reduced applicability but provide detailed requirements that allow implementations to move closer to achieving interoperability if applied faithfully. Implementation guides that are defined at a high-level with many optional aspects are more amenable for wide-spread use, but they fall far short of out-of-the-box interoperability and need further profiling for specific use. This difference presents the specifier with a tradeoff decision that is based on the intended purpose of the implementation guide. Either approach, and anything in between, is correct and appropriate.
The HL7 Version 2 Conformance Methodology is intended to be used as the basis for creating implementation guides and message profiles for the following standards:
HL7 versions 2.1 and 2.2 have been purposely not included because the constructs are so immature that they are not subject to practical use of this specification and it is strongly recommended that any new implementation guide is not created using these versions. The Conformance Methodology is also applicable to the tables defined in the HL7 standard (Chapter 2C as of version 2.7) and any external vocabulary standards used in the specification of an implementation guide and message profile.
An online version of this specification, along with additional informative information, can be accessed at https://v2.hl7.org/conformance (Forthcoming). The main tabs on the web site include an exact copy of this specification. Supplemental information, such as extended examples, historical insight, and constraint assessment tables, can be found on the sub-tabs for a given section.
The terms used to express requirements in this document follow the guidelines as described in RFC 2119 (adapted). Table 1.1 provides a summary of keywords and how they are to be interpreted. The convention for keyword expression is to use non-bold lower case.
|
Keyword |
Definition |
|---|---|
|
must |
means that the definition is an absolute requirement of the specification. Synonymous with the terms “shall” and “required”. The term “required” is reserved for use within the HL7 v2 conformance constructs and will not be used as a keyword in this specification to describe requirements, e.g., “usage” uses the term “required” |
|
must not |
means that the definition is an absolute prohibition of the specification. Synonymous with the term “shall not”. |
|
should |
means that there is strong preference that a statement is applied. Valid reasons may exist to ignore a statement, but the full implications must be understood and carefully weighed before choosing a different course. Synonymous with the term “recommended”. |
|
should not |
means that there is a strong preference that a statement is not applied. Valid reasons may exist when a statement is acceptable or even useful, but the full implications should be understood, and the case carefully weighed. Synonymous with the term “not recommended”. |
|
may |
means that an item is truly optional. A specifier has the option to include or not to include the entity in the implementation guide or message profile. Synonymous with the terms “optional” and “permitted”. The terms “optional” and “permitted” are reserved for use within the HL7 v2 conformance constructs and will not be used as keywords in this specification to describe requirements, e.g., “usage” uses the term “optional” |
Note: the keywords presented in this section are used to state requirements in this document. A similar set of keywords that are recommended for use in an HL7 v2 Implementation Guide appear in Section 3.1.7. This document seeks to distinguish the keywords used herein from those that might be used in implementation guides, but that distinction is not always possible.
The following terms will assist in the definitions and interpretation of requirements for the conformance constructs such as usage and conformance statements.
Value (as a verb): To place a non-empty value (noun) in an element location. To indicate that an element must be valued the phrase “shall be valued” is used. To inquire if an element is valued, the phrase “is valued” is used (e.g., If PID-7 is valued). The equivalent inverse phrases are “shall not be valued” and “is not valued”.
Non-empty Value: A value in which at least one-character is a non-whitespace character. Two double quotes (""), which represents a “delete indicator”, qualifies as a non-empty value.
Empty Value: An element lacking content. Indicated in er7 format for a field as ||.
Known Data: Content that exists and is available for a given element.
Process: Is a general term to indicate that an action must be performed, and is an important concept for understanding receiver-side requirements. Message usage requirements alone cannot fully indicate the scope of processing requirements. Additional functional requirements for how data elements should be processed can be defined.
Exception: Is a general term to indicate that a conformance violation has occurred. The response to an exception is context-dependent.
Message elements are addressable and represented in a standardized form and are dependent on the element context. The element representation presented here is used in this specification to identify the location of elements within a context. It is important to understand this nomenclature to interpret the representation of requirements.
Element contexts include the message, group, segment, or datatype. Depending on the context, a leaf element is referred to either by name or by a name and a position number. For message or group contexts, the leaf elements are accessed by name (e.g., MSH). For segment or datatype contexts, the leaf elements are accessed by a name and a position number (e.g., MSH-7). Table 1.2 illustrates the grammar of the representation for a given context ([] indicates optional, * indicates multiple occurrences).
|
Context |
Grammar |
|---|---|
|
Data Type |
DATATYPE[.POSITION[.POSITION]] |
|
Segment |
SEGMENT[-FIELD[.COMPONENT[.SUBCOMPONENT]]] |
|
Group |
GROUP[.GROUP]*.[SEGMENT[-FIELD[.COMPONENT[.SUBCOMPONENT]]]] |
|
Message |
MESSAGE[.GROUP]*.[SEGMENT[-FIELD[.COMPONENT[.SUBCOMPONENT]]]] |
The datatype context is the name of the datatype, for example, CX. As described in the grammar, a data type element is represented by the name of the data type and position, e.g., the first component of a CX data type is CX.1 (ID Number). If the data type is complex (i.e., not primitive), then the subcomponents are represented using their position number with respect to the parent (component) element. For example, CX.4 (Assigning Authority) is a complex element. Its child elements (subcomponents) are represented as CX.4.1 (Namespace ID), CX.4.2 (Universal ID) and CX.4.3 (Universal ID Type). The location CX.4.1 refers to the first subcomponent of the fourth component of any element with a CX datatype in the message structure (i.e., the context of the element is not known).
The segment context is the name of the segment, for example, PID. As described in the grammar, a segment element and its descendants are represented by the name of the segment, field position, component position, and subcomponent position. For example, the first field of a PID segment is PID-1 (SetID). The location “PID-1” refers to the first field of any PID segment in the message structure. If the field is complex, then child (component) elements are represented using their position number with respect to the parent (field) element. For example, “PID-3” (Patient Identifier List) is a complex element. Its child elements are represented as PID-3.1 (ID Number), PID-3.2 (Check Digit), PID-3.3 (Check Digit Scheme), PID-3.4 (Assigning Authority), etc. Since PID-3.4 is a complex element, it has addressable child elements, PID-3.4.1 (Namespace ID), PID-3.4.2 (Universal ID), and PID-3.4.3 (Universal ID Type). Note that PID-3.4 is the CX data type. For the data type example of CX.4, the context was unknown. In the case of PID-3.4 the context is known at the segment level.
The group context is the name of the group, for example, PATIENT. The representation of an element from the group context is the same as the scheme for the segment context except that the group name is prepended. For example, the third field in the PID segment in the context of the PATIENT group is represented as PATIENT.PID-3. Furthermore, components and subcomponents are represented following the same pattern, e.g., PATIENT.PID-3.4 and PATIENT.PID-3.4.
Nested groups are represented by stringing together the group list separated by a dot. For example, ORDER_OBSERVATION.OBSERVATION.OBX refers to the OBX segment in the context of the OBSERVATION group in the context of ORDER_OBSERVATION group, whereas
ORDER_OBSERVATION.SPECIMEN.OBX refers to the OBX segment within the context of SPECIMEN group within the context of ORDER_OBSERVATION group.
Element location is also addressable from the context of a message. The scheme used is the same as the group context, except the message structure is prepended. Examples include ORU_R01.MSH-12 and ORU_R01.PATIENT_RESULT. ORDER_OBSERVATION.OBR-4.1.
Note that in some instances there is no way to differentiate a particular occurrence of a segment when using the location notation of MESSAGE.GROUP.SEGMENT or GROUP.SEGMENT. This circumstance occurs when the same segment can be present at multiple positions under the same parent element in the message or group context location. An example is the MFN_M04 message structure in HL7 v2.8.1. In such cases, the specifier should supplement the requirement with a narrative comment.
Several core concepts related to standards development and implementation are depicted in Figure 1.7. It is important to understand these concepts and their relationships to better apply the notions in this specification.
Profiling: is the process of placing additional constraints on a message definition in accordance with defined profiling compliance rules to meet requirements stated in a use case. The terms “derived profile” and, more generically, “derived specification” are used to denote a technical documentation that is based on another technical document. Profiling is an iterative process in which more detail is provided in each derived specification.
Compliance: is the degree to which a derived specification adheres to the requirements defined in the foundational specification (standard); in other words, are the rules for adding constraints faithfully followed? Compliance rules for each of the conformance constructs are defined in subsequent sections. An example of a usage compliance rule is that a “required” element must remain “required” in any derived specifications (profiles).
Conformance: is a relationship between a specification and an implementation and is an indication of how closely the software implements the requirements stated in the specification. The HL7 v2 standard and any subsequent profiling express the requirements, an implementation implements these requirements, and conformance is an objective measure of how closely an implementation satisfies the stated requirements. As such, conformance is associated with the recognition of formal testing to verify adherence to the standard. An example sequence is as follows, 1) an element is specified as “required”, an implementation either implements the requirement or not, and conformance is determined by a testing mechanism.
Compatibility: declares whether two specifications define sets of requirements that are harmonized with each other, allowing systems that implement them to work together, i.e., interoperate.
Interoperability: is the ability of implementations to exchange data and to use that data as intended to accomplish a desired task. In theory, compatibility is a prerequisite for interoperability.
Figure 1.8 shows the concepts and their relationships in the context of HL7 v2. A “specifier” selects the ADT^A04 message event from HL7 v2.5.1, for example, and seeks to constrain the message definition for a given use. Using the constraint mechanisms, the “specifier” defines a message profile. The “specifier” may choose to create a single profile or create a different profile for the sender and receiver. In practice, often a single profile is defined for the sender and receiver, and if separate profiles are created, the differences usually are minor. Additionally, profiles can be created independently by separate entities, and the profiles can be compared for compatibility. Implementations will then develop to a given profile.
Profiling is a refinement to a specification in the form of constraints and extensions (See Section 4.7 for a discussion on extensions). Initially, the refinement is to the base standard and subsequently to existing profiles in a layered approach. Conformance constructs are used to specify constraints on data elements and to provide a “toolbox” for authors to specify requirements. Each conformance construct (e.g., usage) has different levels of constraint specification. Profiling is the process of refining the constraint according to the rules of the conformance construct. The constraint rules provide the mechanism to make a requirement more specific (i.e., “to tighten” a requirement).
Figure 1.9 illustrates an overview of message profiling and a sample of the message constituent parts that can be constrained. A profile can be thought of as an overlay of constraints on an HL7 v2 message structure definition. On the left-hand side of the figure is a representation of a base message definition with initial element settings. On the right-hand side of the figure is a representation of the same message structure definition with additional constraints applied. Examples include changing the optional segment of NK1 to required and constraining the base standard HL70001 table to a value set and binding it to the field PID-8.
The key mechanisms for profiling are the conformance constructs that are used for constraining. A high-level overview of the general constraint types is given in Table 1.3. (See Section 5 for in-depth definition and use).
|
Constraint Type |
Description |
|---|---|
|
Usage |
Indicates requirements for the presence (appearance) of an element. |
|
Cardinality |
Indicates the number of occurrences for an element by specifying the minimum and maximum bounds. |
|
Data Type |
Defines the data element structure and, at the primitive level, the type of data it may contain. Constraints include type substitution and specialization (when combined with other constraint types). |
|
Vocabulary |
Defines the vocabulary binding and vocabulary definitions. Indicates the allowable content for a coded element. |
|
Length |
Defines a constraint on the number of characters that may be present in one occurrence of an element. Can specify a maximum length, a minimum and maximum length, or minimum for the maximum length supported (Conformance Length). |
|
Content (non-coded) |
Defines constraints on data (content), such as a fixed value or adherence to a specific format. |
|
Conformance Statement |
A method of expressing content constraints. An explicit statement expressed in text or a testable expression that defines a constraint. |
|
Co-Constraint |
Content constraints used to express dependencies among a set of data values. |
|
Slicing |
Allows for occurrences of a field to be defined with different constraints. |
|
Semantic Refinement |
Allows for refinement of the semantics of a data element based on the use case |
Note that in many ways content, conformance statements, and co-constraints are related and overlap. They provide various options to the specifier to select the best way to express constraints. For example, a co-constraints table is a convenient method to express numerous data dependencies in a set and within Observations (OBX Segments) but these constraints also could have been declared in one or more complex conformance statements.
A message profile is normally thought of as a complete message structure definition with additional constraints applied to it as a “whole”. In some circumstances, however, it is convenient and efficient to employ a modular approach to profile construction. A profile component defines a part or a certain aspect of a message definition and is used to aggregate correlated requirements and/or to differentiate requirements from another profile. It provides a mechanism to support a set of reusable requirements. A profile component can be applied to any construct or section of a message definition. A core profile is used to document the common set of requirements across the set of related profiles. A composite profile is the composition of a profile or core profile and one or more profile components. In the end, a composite profile is a profile with the distinction that the profile was created by combining a profile or a core profile and one or more profile components. Profiles and profile components can be combined to develop and manage other profiles. A profile component in a family of profiles can be used to identify different levels of requirements for the same use case or to identify the differences in requirements for different, but closely related, use cases.
One example is the case of national and local requirements. A typical domain for which localization is needed is public health, where a national-level profile is created and additional requirements (constraints) are specified at the state- or jurisdictional-level. A profile for the national level is created for a particular interaction (e.g., send immunization record). State-level requirements could be expressed in a profile component. When combined with the national-level profile, the result expresses the complete requirements for the state.
More discussion on profile construction and scenarios for its use is given in Section 7.1.
Message profiles are used to document interface capabilities of applications. The ultimate goal is to connect applications to allow exchange of data. These interactions include a sending application and a receiving application. The requirements or expectations of each application may, and often do, differ; hence, each application will take on a certain role in the interaction, e.g., the role of a sender or a receiver. As such, an interaction pair can be established in which the applications define their own message profiles depending on their role in the interaction. For a successful interface, the requirements for the sender and receiver must be compatible. Sender and receiver profiles can be paired in a variety of ways to satisfy a targeted use. The profile pairings may be closely aligned or disparate. In the case where the sender and receiver profiles are intended to be the same, the profile role is declared as “both”. Section 8 defines in detail the most common profile pairings.
There are a number of approaches for documenting profiling constraints. This specification recommends the use of segment flavors and data type flavors in which constraints are applied to a base element (e.g., a segment) and assigned an identifier (e.g., PID_01). Subsequently, the element is bound to the higher-level element (e.g., PID_01 is bound to the message definition where appropriate). This approach allows for multiple definitions of a base element type and reuse of those definitions, and, therefore, a precise definition of the construct can be assigned at the appropriate context. Use of this method eliminates comingled requirements commonly found in existing HL7 v2 implementation guides.
Implementation guides define requirements for specific use cases and are intended to be used by implementers to provide an interoperability solution. Implementation guides can also be used by testing programs to assess and certify implementations. Figure 1.9 illustrates how implementation guides (and their message profiles) can be used to facilitate implementation, implementation claims, validation, and reaction to the findings of the validation. Point (1) indicates that an implementation guide includes a conformance clause (2) that defines the requirements, criteria, or conditions that must be satisfied by the implementation to claim conformance. The conformance clause identifies what must conform and how conformance can be met. A conformance claim is a declaration by an implementer (3) of the requirements in the conformance clause that their implementation satisfies.
The conformance clause typically indicates only the high-level conformance requirements. The requirements may be stated in terms of a profile or identifiable parts of a specification. Profiles are mechanisms that provide a structured approach to specifying requirements. The detailed requirements (4) are contained and delineated in the other parts of the specification (e.g., Segment definitions). For example, a conformance clause in an HL7 v2 implementation guide could indicate a set of profiles available to the implementer, and the profiles provide the map to the specific requirements.
Implementers makes their conformance claims (3) based on their implementation (5). Implementations or aspects of an implementation (e.g., a message instance) can be validated (6) with respect to the declared implementer’s conformance claim (7) that references the requirements set forth in (2) and (4). A Tester can analyze the results of the validation (8). In a testing program, an assessment will be made, and some level of recognition may be issued (9), e.g., a certification. In a testing program the pass/fail criteria are rigid–either the implementation meets a requirement or not. In a production environment, the response to a conformance violation is at the discretion of the receiver (10). The use of message profiles to determine conformance and the response to the conformance assessment is often misunderstood. This topic is expanded upon in the next section.
The conformance methodology specification provides the procedures and mechanisms that allow specifiers to define requirements precisely in the form of profiles. Those requirements provide the basis for evaluating implementations. A conformance violation occurs when an implementation does not satisfy a requirement; and, it must be emphasized here, the identified conformance violation applies in all circumstances. How entities react to a conformance violation is separate topic.
For the sending system, conformance validation is a strict determination of the content of a message instance against the requirements stated in the message profile. Validation is used as an indicator of the degree to which the message instance conforms to the message profile. In the conformance assessment, no allowance is made for exceptions. Therefore, any content (or absence of content) not explicitly permitted by the message profile is a conformance violation. This statement is not to be confused with receiver processing rules; i.e., the conformance assessment should influence but not necessarily dictate receiver processing behavior. For example, unexpected content such as a Z-segment (not documented in the profile, and not explicitly allowed) is a conformance violation with respect to the message profile; however, the receiver may choose to ignore the violation and process the message.
To further emphasize the point, suppose a profile specifies an address field that has components for street, city, state, and zip code. All components are required. A receiver is sent a message in which the state is omitted. The message is non-conformant; specifically, the required state component is missing, and this omission is a conformance violation. A conformance tool would determine that the message is non-conformant and report the violation. A receiver, however, would act in accordance to its processing rules. Implementations may use conformance assessments in different ways, for example, as a mechanism to determine how the message content should be processed or whether a message should be processed at all. A viable choice in the case where the state is omitted from the address field would be to process the message and then deduce the correct state based on the zip code and other collaborating evidence. For this type of conformance violation, the receiver may or may not decide to send an acknowledgement with an exception back to the sender. And if the receiver does send such an acknowledgement, that receiver may choose to apply one of several different severity levels (e.g., error, warning, or informational).
Using message profiles is a powerful tool for determining conformance of message instances; however, the appropriate reaction to the conformance assessment findings is dependent on the circumstances. In certification programs, for example, a conformance violation can and should mean a failure, whereas in live interfaces the same violation may result in a spectrum of responses, from rejecting the message to no action whatsoever. Non-conformance is not necessarily an appropriate reason for not accepting usable data. On the other hand, implementations should seek to define their interface as precisely as possible and to adhere to those rules. Well-defined specifications (message profiles) and conformance to those specifications are impactful drivers towards interoperability, which is a key goal of message profiles.
Assessing receiver-side conformance is often a more difficult task, because it is determined by the consumption of the data and the actions taken on that data. In order to test receiving systems adequately, sufficient acknowledgement and functional requirements must be specified for each element. Such specifications are often out-of-scope for HL7 v2 interface specifications. Companion edge functional requirement guides can be developed to further specify what is expected by certain receiver classes when they receive the data. For example, an operational results management application may be required to store "everything", while an analytics/clinical decision support system may opt to only store select data it needs, but no more. Acknowledgement requirements may include exception responsibilities when conformance violations, such as a missing required element, are detected. Functional requirement violations can be detected by acquiring evidence that a capability is not supported by the receiving system. Capabilities may include displaying of an element, storing the data in a record, exporting the data to another system, using the data to search for a record, or some other observable processing.