New features of HL7 version 2.6
Copyright Ringholm bv © 2006,2008. All Rights Reserved.
HL7 version 2.6 has been published in April 2007. A number of new events, segments, messages and two entirely new chapters have been added in HL7 version 2.6 (chapters 16 -Claims and Reimbursement- and 17 -Materials Management-).
The highlights of version 2.6 in comparison to 2.5 include:
With the release of version 2.6 the number of artefacts has increased yet again.
The standard has increased in size. This is especially notable when we look at the number of trigger events (over 300) and fields (over 2000). There are indications that harmonization has taken place as well: the number of static message definitions increases at a lower rate than the number of trigger events.
2. Data types (chapter 2A)
The CE data type has been withdrawn in HL7V2.6, and has been replaced by CNE and CWE.
The specification of the maximum lengths of data types and components thereof has been further harmonized between chapter 2A (the chapter that defines the data types) and the other chapters. Maximum lengths may be removed from the standard altogether given that the maximum lengths as specified in the standard are informative - and not normative. The specification of maximum lengths will be limited to message profiles and conformances statements. It would therefore be up to individual vendors to determine what field lengths their applications should support.
2.1 CNE and CWE replace the CE data type
The CE data type has been deprecated, and has been replaced by CNE and CWE. All fields that used the CE data type have been redefined to either use the CNE or the CWE data type.
The first 6 components of the CE, CNE and CWE data types are identical. When compared to CE, the CNE and CWE data types have additional components and requirements.
CNE - Coded with no exceptions
The most relevant characteristics of the CNE data type (when compared with the characteristics of the CE data type) are
CWE - Coded with Exceptions
The most relevant characteristics of the CWE data type (when compared with the characteristics of the CE data type) are the use of versionIDs to convey the version of the coding system, and the introduction of OriginalText to convey the original text that was available to an automated process or a human before a specific code was assigned.
The specification of the CWE data type is as follows:
2.2 DTM data type replaces TS
The DTM (date and time) data type replaces TS. The TS data type consisted of 2 components. The second component of TS had the aim of conveying the precision of the date and time value contained in the first component.
The definition of DTM is equal to that of TS - without the second component. The DTM data type allows for a 4-digit year and optional 2-digit and further additional 2-digit day; further optional hours and minutes (n.b., not hours alone); further optional (fractional) seconds, with or without time zone.
2.3 ED data type
The ED (encapsulated data) data type uses a new table (table 0834) to identify what type of data it encapsulates. The coding table contains a subset of the W3C MIME types.
This data type contains the following components:
The tables referenced by this data type definition have been redefined:
Imported Table 0834 - MIME Types
This is a new table. Its values consist of a subset of W3C MIME types:
HL7 Table 0191 - Type of referenced data
This table (replaced by 0834) has been designated as being "for Backward Compatibility only":
HL7 External Table 0291 - Subtype of referenced data
All values but one have been removed from the table.
3. UAC segment (chapter 2)
The UAC segment (User Authentication Credential Segment) has been added as an optional segment to all messages. T his segment provides user authentication credentials, e.g. a Kerberos Service Ticket or SAML assertion, to be used by the receiving system to obtain user identification data.
The UAC segment consists of 2 fields, UAC-1, Credential Type Code, and UAC-2, User Authentication Credential. The UAC segment is defined for use within simple protocols, such as MLLP, that do not have user authentication semantics. Implementations that use WSDL/SOAP, or similar protocols, to envelope HL7 should employ the user authentication semantics and data structures available within the scope of those protocols rather than the UAC segment.
4. Repeating segments and fields (chapter 2)
The use of repeating segments and fields in update message has been clarified using examples.
5. Conformance: Message profiles (chapter 2B)
The definition of message profiles has been extended to included vocabularies. Annotations can now be used to add information to a message profile. Additional constraints, involving single or multiple message elements, can be specified using the Object Constraint Language (OCL), regular expressions (RegEx) or XPath expressions.
6. Patient Administration (chapter 3)
A new segment has been added to all messages in chapter 3.
The ARV segment (Access Restrictions) segment has been added to all ADT messages (defined in chapter 3). The ARV segment is used to specify access restrictions to data related to persons, patients or visits. This segment replaces PD1-12 and PV2-22, which have been deprecated in V2.6.
Example: A person/patient may have the right to object to any or all of his/her information to be disclosed. In addition, the patient may request that protected information not be disclosed to family members or friends who may be involved in their care or for notification purposes.
The ARV segment consists of 6 fields. Key fields include ARV-2, Action Code (Add/Delete/Update) and ARV-3, Access Restriction Value, which identifies the information to which access is restricted.
7. DRG related data (chapter 6)
Those using a DRG (Diagnoses Related Groups) based reimbursement system have extended various DRG related segments to include the necessary details. The DMI segment has been added for the exchange of master files.
The segment definitions shown below are limited to new fields.
7.1 DRG segment
7.2 DG1 segment
The Parent Diagnosis field can be used to link parent and child diagnosis. This field has effectively already been replaced by the new REL segment. The other fields are used to link the diagnosis to a particular DRG.
7.3 PR1 segment
Both these fields are used to link the procedure to a particular DRG.
7.4 DRG Master Files
DRG related master files are sent using the new M17 trigger event.
DMI - DRG Master File Information
Each DRG has a number of fixed characteristics. These are only sent as part of a Master File message.
The Mood Code (a HL7 v3 concept) has been added to HL7 v2. The Mood Code can be used to specify how the data in a segment should be processed by the receiver. For example: if one sends an OBX segment, this field can be used to specify whether that OBX contains a result, or whether the sender expects the receiver to perform the observation. Especially in referral messages there is a requirement to explicitly specify the context of a segment.
Possible MoodCode values are:
The MoodCode field has been added to the OBX, RXO, PRB, GOL, PTH and PRD segments. Given that the MoodCode can be used to change the semantic interpretation of a segment its use is only allowed in new messages. There is therefore no impact on messages that have been defined prior to the release of HL7 v2.6.
9. Order Entry/Result Reporting (chapter 4)
Two new messages have been added for use in the laboratory domain:
These messages are intended to be used in veterinary medicine. Next to these messages a table has been added to further clarify the use of Order Control Codes.
9. Queries (chapter 5)
The misleading term "Query Conformance Statement" has been replaced by "Query Profile". A number of query messages has been removed from the standard:
10. Observations (chapter 7)
In order to identify all those involved in an observation the ROL segment has been added to a couple of observation messages.
One new message has been added:
This observation message is related to the two new veterinary order messages that have been added to chapter 4.
11. Patient Care (Chapter 12)
The Mood Code has been added to the GOL, PTH and PRB segments.
The new REL segment (Relationship) allows for the identification of the relationship between objects - between objects contained within a message, but also to objects. The objects are diagnosis, procedure and observations. The relationship type can be explicitly identified. This can be used to state that a diagnose is based on a particular observation.
The REL segment isn't used in any messages at the moment.
11.1 REL segment
The above table may appear in a slightly different form in the standard itself. At the time of writing some of the last minute changes weren't known yet.
12. Claims and Reimbursement (chapter 16)
The claims and reimbursement transaction set supports the communication of claims information from a healthcare provider to a claims reimbursement authority. This chapter of the standard isn’t used in the USA – X.12 has to be used instead.
For example, this transaction set permits for the transmission of:
The following trigger events have been defined:
In order to construct the above messages a number of segments have been added:
13. Materials Management (chapter 17)
The materials management transaction set supports supply chain management within a healthcare facility. Two distinct topics are covered by the transaction set: inventory item master file updates, and supply item sterilization.
For example, this transaction set permits for the transmission of:
Inventory Item Master Updates
Eight new segments related to "Inventory Item Master":
Sterilization and Decontamination
Four new segments related to "Sterilization and Decontamination":
[HL7] "HL7", 2007, http://www.hl7.org/, Version 2.6.
About Ringholm bvRingholm bv is a group of European experts in the field of messaging standards and systems integration in healthcare IT. We provide the industry's most advanced training courses and consulting on healthcare information exchange standards.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.