For inclusion into the HL7 v2 Conformance Methodology Specification
Draft 4: November 28, 2018 R. Snelick
Sponsoring Workgroups: Conformance, HL7 v2 Management
Purpose: For inclusion into the HL7 v2 Conformance Methodology Specification.
Many versions of the HL7 v2 base standard exist. Each version contains message definitions that are constrained by implementers for a given use case. The process of placing constraints on message definitions is called profiling. Typically, constraints are placed on a message definition defined entirely in a given version of the standard. In some cases, however, specifiers and implementers may want to use as a foundation a given version of the standard (e.g., 2.5.1) while selecting certain features offered by another version of the standard (e.g., 2.8.2). In essence, all HL7 v2 base standard versions can be viewed as a single collection of objects from which specifiers and implementers can pick and choose to construct message profiles. Implementation guides can contain message definitions from different versions of the standard and also could contain message definitions that contain objects from more than one version of the standard. Several methods may be used to accomplish the latter circumstance:
- Selective Pre-adoption
- Selective Post-adoption
- Selective Post-adoption from the current HL7 v2+ edition
This document describes:
- how to construct a message profile using objects from different versions of the standard
- the different methods for selective adoption
- the granularity of the object that can be adopted
- how non-indigenous (adopted) objects are specified and identified in the computable message profile
The HL7 v2 message profile is the governing artifact for specifying requirements for a message interface. Regardless of the base standard version designation, the profile modifies the standard- level definition to satisfy use case requirements. Such modifications can selectively include objects from different versions of the standard. Therefore, implementers must interpret the requirements based on the message profile (indicated in MSH-21) and not merely rely on the message version (indicated in MSH-12). This premise is true regardless of whether the message profile contains objects from a version other than the foundational version. The message profile declares a foundational version and, for every adopted object, the HL7 v2 version of that object.
Object – an object from the HL7 v2 standard, this can be any element (group, segment, field, component, or sub-component ), data type, or table. Probably not these.
Adopted Object – an object from another version of the standard that is imported into a message profile. The adopted object will be designated with the adoptedVersion attribute.
Indigenous Object – an object from the foundational version of the message profile. Indigenous objects do not have an explicit version attribute. The version of the object is the version of the Foundational Version.
Foundational Version – this is the version of the base standard that serves as the core (starting) version of the message definition. All objects in the message profile will comply to this version unless explicitly overridden by an adopted object.
Adopted Version – this is the HL7 v2 version from which an object was adopted.
HL7 v2 has a very large installed base of implementations that are built on earlier versions of the standard. As use cases and needs evolved, so did the standard. For a given use case some, but not all, features of the newer standard are needed or wanted. In such circumstances, specifiers and implementers may want to add only the features needed (and not be impacted by other features that are not needed). Therefore, instead of requiring implementers to upgrade to a newer version of the standard, selective adoption allows them to upgrade only the parts needed for their use. For example, if a domain or a large installed base of interfaces already exists in version 2.5.1 of the standard, and if in an update to an implementation guide a few fields from version 2.8.2 are desired, then only those fields from version 2.8.2 need be included in the message profile definition. This approach likely will have the least impact on implementers. In any project, however, implementers must consider the pros and cons of each approach.
Methods for Selective Inclusion
Three methods by which objects can be adopted into a message profile are available:
- Selective Pre-adoption
- Selective Post-adoption
- Selective Post-adoption from the current HL7 v2+ edition
The details of each method are given in the sections to follow.
The selective pre-adoption method allows a profile definition to be created using a version of the standard while allowing adoption of objects from a later (newer) version (or versions) of the standard. This method is suitable when a specifier or implementer wishes to keep an implementation guide or implementation at the current version level while taking advantage of features from later (newer) versions of the standard. This approach has minimal impact on installed implementations.
Figure 1: Selective Pre-adoption
Figure 1 shows an example of Selective Pre-adoption. An implementation guide is produced in which the foundation profiles are created with version 2.5.1 message definitions. The figure also shows that a segment, field, and table are pre-adopted from version 2.8.2 and a data type is pre-adopted from version 2.7. The pre-adopted objects are used to replace or extend existing objects in the foundational profile (message) definition. Note, the figure does not show the relationship of the pre-adopted objects in the message profiles, because, depending on how the implementation guide is constructed, this relationship can vary.
One example of a table pre-adoption comes from the laboratory results interface (LRI) implementation guide in which the foundational version of the message profile is 2.5.1, but an updated table definition from version 2.8.2 is sought. Table HL70078 (abnormal flags) in version 2.5.1 contains codes L (below low normal), LL (below lower panic limits), H (above high normal), and HH (above upper panic limits). For table HL70078 (named changed to “interpretation codes”) in version 2.8.2, another level of granularity was added to the code set: LU (very low) and HU (very high), which are levels between L and LL, and, H and HH, respectively. Additionally, the definitions of L, LL, H, and HH were refined. The LRI implementation guide pre-adopted the 2.8.2 version of the table, and this table replaced the 2.5.1 version of the table.
Candidate Example: LOI example #1: OBX-26 through OBX-29 are pre-adopted from 2.8.1. Foundational version is 2.5.1. In that case the whole field is pre-adopted. That means OBX-26 to 29 did not exist in HL7v 2.5.1
Candidate Example: LOI example #2: for PID-10, the use of CWE is pre-adopted from HL7 v2.7.1. In that case, only the datatype is different as PID-10 already existed in v2.5.1. Note that CWE could be either 2.5.1 or 2.7.1(this has to be specified at the datatype level). In the LOI IG a “hybrid” CWE datatype was created—this is questionable as whether or not this should be allowed, alternatives need to be explored.
Candidate Example: TQ1 segment instead of OBR-7 or PRT segment instead of OBR-16 as example.
Candidate Example: LOI example #1: the use of PRT segment (pre-adopted from 2.7.1) in conjunction with OBR-28 (Result Copies To). The PRT segment contains additional information describing the address or other contact information of the copy-to provider(s). In that case PRT does not replace the use of OBR-28, they “work together”. The pre-adoption of PRT impacts the AMD as well.
Candidate Example: LOI example #2: pre-adoption of the SGH and SGT segments in the message structure.
The selective post-adoption method allows a profile definition to be created using a version of the standard while allowing adoption of objects from an earlier (older) version (or versions) of the standard. This method is suitable when a specifier or implementer wishes to take advantage of the capabilities of a newer version of the standard but doesn’t want to use all upgrades . There may be aspects of the newer standard that the community (or established base) is not ready for, or the cost of such changes is prohibitive, or the earlier functionality suits the use case better.
Figure 2 shows an example of Selective Post-adoption. An implementation guide is produced in which the foundation profiles are created with version 2.8.2 message definitions. The figure also shows that two fields, a data type, and table are all post-adopted from version 2.5.1. The post-adopted objects are used to roll back capabilities to previous definitions of concepts. Note, the figure does not show the relationship of the post-adopted objects in the message profiles, because, depending on how the implementation guide is constructed, this relationship can vary.
Figure 2: Selective Post-adoption
TODO: Use table 0163 instead of 0550 (example from Immunization IG).
TODO: OBR-7 instead of TQ1 segment. OBR-16 instead of PRT segment.
Observations and Questions:
- Exactly where would selective post-adoption be applicable? Does it only apply to withdrawn elements and potentially to element semantics (if they have changed)?
- For backwards compatibility, post-adoption is not necessary. The specifier can simply profile the elements from B to R, RE, C, or O. The unwanted/unneeded new functionality can be profiled to X.
Selective Post-adoption from the current HL7 v2+ edition
The Selective Post-adoption from the current HL7 v2+ edition is fundamentally the same as the previously explained selective post-adoption. The key difference is that specifiers are limited to using the current v2+ edition as the foundational version.
Figure 3: Selective Post-adoption from the current HL7 v2+ edition
Observation and Questions
- Even if you start with the latest version, over time various IGs will have different foundational versions (so not sure how much will be gained by limiting to current v2+)
The type and granularity of the objects (and their attributes) that can be adopted are limited. Below is a list of candidate objects to consider:
Abstract Message Definition (AMD)—What does this mean? If using the entire abstract message, then this is not pre-adoption (you just have a guide that uses a different foundational version for the profile). So, AMDs can’t be pre-adopted, but what about partial or mixed adoption? Consider:
- What if you have a 2.5.1 profile and pre-adopt certain but not all segments in the AMD for a newer version? Lab pre-adopted part of the AMD of the group but not the whole message structure. In essence, they created their own customized message structure, which should be acceptable as long as the rules of message structures are followed, e.g., the first segment in the group must be required. What is the event type? Is it the same? Should it be a Z-event/structure? In this case, a group or segment(s) is being added to an existing message structure—and a new abstract message definition is created (using the same event type). The combination of MSH-9 and MSH-12 is not reflecting the AMD correctly; is this satisfactory since MSH-21 can be included with the profile definition? What are the ramifications on implementers? Should this be allowed?
- If this route is taken, then MSH-9 and MSH-12 cannot be trusted for defining messages. AMDs in the chapters are, in essence, examples of event types and there is really no control on AMDs. The profile provided in MSH-21 is the only reliable source to determine requirements.
- Could the alternative have been to use the 2.8.2 AMD and to post-adopt segments and profile unwanted segments as X (and post adopt objects that the specifier did not want to change)?
Segment (Segment Replacement) with a newer/older version of the same segment.
- This practice is reasonable and straightforward.
- The segment would carry along with it the fields and all associated attributes (e.g., vocabulary bindings, tables, usage) from the adopted version.
- The segment would carry along with it the data types and all associated attributes (e.g., vocabulary bindings, tables, usage) from the adopted version.
Fields (adding Fields to the end of a segment).
- Fields that are added must maintain the order integrity of the fields in the adopted segments even though all fields may not be added. For example, if the foundational version of the segment has 11 fields, and the specifier wants to add fields 14 and 15 from another version, then fields 12 and 13 must “come along” in the adoption process.
- In 3a, if there are more fields, say 16 and 17, then these fields need not come along.
- The fields would carry along with them the data types and all associated attributes (e.g., vocabulary bindings, tables, usage) from the adopted version. Therefore, the segment would have a mix of objects from various versions.
- Caution: for fields that have dependencies, all associated fields should (must?) be adopted.
- Should we limit to only adding fields and not replacing? That is, does it make sense to replace a field with the definition from another version, meaning the associated attributes, semantics, and field definition would be replaced? Not sure how much this buys us.
This practice is reasonable and straightforward (at the field level—i.e., the data type is wholly adopted).
- Complex data types would contain complex data types of the same version (e.g., an XAC data type shouldn’t have a version of 2.5.1 and also have a sub-component data type of 2.8).
- Components can’t be added to data types (all or partial). Reason: Data types are fundamental building blocks and should not be implemented piecemeal. Data types are analogous to data types in programming languages. A data type is a “cohesive” concept.
- Lab may have used this method, i.e., added some, but not all, components to a data type and also changed usages. Data types may change the semantics/interpretations of element meanings from version to version. This type of adoption is debatable, and alternatives considered and likely available.
- Fields can replace data types (wholly) of the same root or a with compatible data type. Rules for data type substitution apply.
- This practice is reasonable and straightforward (at the field level—i.e., the data type is wholly adopted).
- Tables (code sets) are adopted wholly. Modifications can be made through profiling to create value sets. No single codes can be adopted; the addition or removal of a single can be accomplished via profiling and creating a value set to which codes are added or are removed via exclusion. So, in essence, individual codes can be “adopted” via value set creation—which is a process practiced today.
- Anything else?
- Conformance rules must be carried forward; e.g., if the adopted element is R in the base, it can’t be made O in the message profile definition.
- Data Type substitution. Adopted data types can be used in field definitions where the root must be the same, or is it, an allowable data type promotion—the same as the profiling rules for DT substitution (e.g., CWE version 2.7.1 for ID version 2.5.1). Seems this would be OK.
- What about components in a complex data type—if allowed, what would be the version of the complex data type? Here we have a “mixed” version data type.
The message profile contains an attribute for the base standard version (HL7Version) upon which the profile is based. This version is considered the foundational version when selective adoption is employed. Each adopted object will include an adoptedVersion. The adoptedVersion is not applicable for indigenous objects but is a required attribute for adopted objects. Therefore, indigenous objects will have the version of the HL7 version (foundational version) of the profile. Adopted objects will contain an explicit version designated with the adoptedVersion attribute. Message elements (child) contained within another message element (parent) subsumes the adopted version of the parent. For example, if a segment is adopted, then all fields within the segments are adopted and have the adoptedVersion of the segment.
Question: Should we also include profile level meta data indicating that the profile is using selective adoption?
<ConformanceProfile HL7Version="2.5.1" …/>
<Segment Name="PID" LongName="Patient Identification" Usage="R" Min="1" Max="1" AdoptedVersion=”2.8.2”/>
<Field Name="Performing Organization Medical Director" Usage="O" Min="0" Max="1" Datatype="XCN" MinLength="1" MaxLength="3002" ItemNo="02285" AdoptedVersion=”2.8.2”/>
Question: What about the data type here, we may want to use a data type from a different version. In the case above the data type would be XCN from version 2.8.2, but how is this indicated. See next section (by default IGAMT assigns the HL7 version when importing data types from other versions, e.g., XCN-2.8.2).
Adopted Data Type
<Datatype ID="CWE" Label="CWE" Name="CWE" Description="Coded with Exceptions" AdoptedVersion=”2.8.2”/>
NEED to investigate for data types —I think we (NIST) do automatic assignment in IGAMT. HD-2.5.1 or something like that. Similar naming to that of data type flavors.
Tables are independent and should have a version as metadata regardless of adopted or not.
OPTION 2: Just have an optional version attribute that can be applied to any object. If the version attribute is present, then the version of the object is indicated in the version attribute; if not, then the object has the version of the profile HL7Version (foundational version). Note that the distinction has two aspects: (1) the version attribute can be applied to any object in the profile, including indigenous objects (which would be redundant if used); (2) the attribute does not make an explicit distinction that the object is adopted (it just contains a generic version attribute).
- The selective adoption only applies to the base version from which the message profiles originate. Selective adoption does not apply to implementation guides. Aspects that need to be included from implementation guides can be included by using the profile component mechanism.