Ringholm-Logo Ringholm  Whitepaper Ringholm page header
Training    Services   |   Whitepapers    Blog    Events    Links   |   About us    Partners    Clients    Contact

New features of HL7 version 2.7

The contents of this whitepaper are published under the Creative Commons Attribution-Share Alike license.
See http://www.ringholm.com/docs/00720_en.htm for the latest version of this document.
Author: René Spronk, Ringholm bv
Document status: Final, version 1.0 (2011-08-06)
Please send questions and comments to rene.spronk@ringholm.com.


Summary

HL7 version 2.7 was published early 2011. This paper discusses the most important changes, which include the introduction of a new delimiter, a set of new Collaborative Care Messages (CCM), the use of the new Participation (PRT) segment, the strengthening of requirements with regards to existing data types, and the deprecation or removal of a number of message components.

This whitepaper discusses the changes and new features in HL7 version 2.7 (published early 2011 [HL7]) compared to the previous HL7 version 2.6 release. Similar whitepapers exist for the delta between 2.4 and 2.5, and between 2.5 and 2.6. The highlights of version 2.7 in comparison to 2.6 include:

  • A new delimiter was introduced: # as the (recommended) truncation character.
  • Strengthening of the requirements for use of data type components which hold metadata (e.g. type codes, assigning authority, equipment type)
  • Use of the Participant (PRT) segment in chapters 4 and 7, e.g. leading to the deprecation of a large number of ORC/OBR/OBX fields.
  • A suite of Messages called the Collaborative Care Message (CCM) has been added to chapter 11.
  • A number of events and message components were removed from the standard publication. They had already been shown as being ‘deprecated’ for a couple of releases.

1. Chapter 2

Chapter 2 covers the syntax rules, the data types and the coding tables. In HL7 version 2.7 the process of consolidating all code-set tables in a single location in Chapter 2C was initiated. Goal after final consolidation in 2.8 is the ability to separately ballot the code-sets outside of a general 2.x ballot, i.e. the code-sets will be allowed to change without requiring an overall 2.x ballot. A number of data type definitions were further aligned with the ISO (HL7 version 3) data type specification.

1.1 Max lengths, truncation

Changes were made throughout the standard to reflect the outcomes of an ongoing discussion related to the definition of the maximum length/size of a data type, as well as the normative nature of such expressions. Two kinds of length may now be specified for data types and components:
  • Normative Length: For some data types or components, the value domain of the content leads to clearly established boundaries for minimum and/or maximum length of the content. In these cases, these known limits are specified for the item. Normative lengths are only specified for primitive data types. Examples: the DTM data type which is based on a particular format to express a date/time; or an 'identifier type code' which is based on a coding system that uses 2-character codes.
  • Conformance length: Specifies the minimum length that applications must be able to store. Conformant applications SHALL not truncate a value that is shorter than the length specified. The definition of conformance length will be mainly left to (constrainable or implementable) implementation profiles/guides.

A new delimiter has been introduced: # as the (recommended) truncation character should the data exceed any agreed upon length limitations of a field/component, or should the application not be able to store the full value. The last character of the truncated string is replaced by # to inform the receiver that truncation has taken place. The definition of MSH-2 (delimiters) has been changed accordingly: a new 5th delimiter for truncation has been introduced, and a sending application has to mandatorily list at least 4 (up to now: at least 3) delimiters. The escape sequence for the new delimiter was defined as '\L\'.

1.2 Strengthening component requirements

RE was added to the optionality table (related to the occurence of fields in a segment) “The element may be missing from the message, but should be sent by the sending application if there is relevant data. A conforming sending application should be capable of populating all "RE" elements.”

In general, HL7 version 2.7 strengthens the requirements for use of those components which hold metadata (e.g. type codes, assigning authority, equipment type). Some of the components were changed to C (conditional), others to R (Required). Type Codes are now designated as R. Examples: CNE, CX, XCN, and XPN/XCN.

  • In the XPN and XCN data types, the family name component is now “RE” – should be known and sent. Note that this is the first time ever the RE conformance code has been used in the v2.x standard. A new XPN.15 component was added: “Called By” - A called by name is the name that is preferred when a person is directly addressed.
  • The CX data type has been extended with two new components; the Identifier Type Code has been made Required.
  • Additions and updates to various Data types to improve consistent support for OIDs in HL7 v2 Data types. Effectively this comes down to an increase in the use of the HD data type instead of the ST data type.
  • The IS data type has been replaced by the CWE data type across the board.
  • The CWE/CNE data types were extended with a third “translation”, OIDs and information about value sets to bring them in alignment with the HL7 terminology model. CWE/CNE now both allow for 3 instances of the following tuple: (Identifier[code], Text, Name of Coding System, Coding System OID, Value Set OID, Value Set version ID).

The table below shows the highlights of the updates to the XPN data type:
SEQ DT OPT TBL# COMPONENT NAME SEC. REF.
1FNRE Family Name2.A.30
..     
15STO Called By 

The table below shows the highlights of the updates to the CX data type:
SEQ DT OPT TBL# COMPONENT NAME SEC. REF.
1STR ID Number2.A.75
..     
5IDR0203Identifier Type Code2.A.35
..     
11STO Security Check2.A.74
12IDO0904Security Check Scheme2.A.74

1.3 name type code

Table 0200 defines the name type code, used in various data types. This table has undergone significant changes to align it with the ISO data type specification used in HL7 version 3. The table below is limited to new codes (shown in red) and codes that were assigned a new/extended definition (shown in orange).

Value Description Comment
DCustomary NameKnown as/conventional/the one you use
LOfficial Registry NameThe formal name as registered in an official (government) registry, but which name might not be commonly used. May correspond to legal name For many people, customary name is also their official name
TEMPTemporary NameA temporary name. Note that a name valid time can provide more detailed information.
NBNewborn NameA name assigned on a temporary basis at birth. i.e. “Baby of Smith”
AAssignedA name assigned to a person. Reasons some organizations assign alternate names may include not knowing the person's name, or to maintain anonymity. Some, but not necessarily all, of the name types that people call "alias" may fit into this category.
KBusiness nameA name used in a Professional or Business context. Also includes writer's pseudonym, artist’s name, stage name, street name, etc

An example of use is where a person with multiple proper names (i.e. married) uses one of the particular names in a professional

RELReligiouse.g. Sister Mary Francis, Brother John
MSKMaskedThere is information on this item available but it has not been provided by the sender due to security, privacy or other reasons. There may be an alternate mechanism for gaining access to this information.

Note: using this null flavor does provide information that may be a breach of confidentiality, even though no detail data is provided. Its primary purpose is for those circumstances where it is necessary to inform the receiver that the information does exist without providing any detail.

NAVTemporarily UnavailableInformation is not available at this time but it is expected that it will be available later.

Includes John or Jane Doe situations

PName of Partner/SpouseRetained for backward compatibility only as of v2.7.
BADBad NameA name that was wrongly used in the past and is now maintained only for the purposes of searching
NOUSENo Longer To Be UsedName not to be used anymore for personal reasons


2. Chapter 3

Chapter 3 covers messages related to patient/person demographics and encounters/visits.

2.1 Encounter/Visit

A new Find Candidates including Visit Information (Event QBP^Q32) message and Response (Event RSP^K32) pair has been added to chapter 3. These query/response messages are designed for interaction between a client system and an MPI (Master Person Index). The query consists of a set of demographic and/or visit attribute values for a person, and the response is the list of candidates (specified by a PID and by a PV1 segment) considered by the MPI to match that set. The definition of this query was inspired by the QBP^ZV1 and RSP^ZV2 messages as defined in the IHE PIX profile.

Two new fields (53 and 54) related to the concept of Service Episode were added to the PV1 segment. A Service Episode is defined as "the context in which the treatment or management of an arbitrary subset of a Patient’s medical conditions occurs. The definition of the start time, stop time, and included events of a Service Episode is entirely arbitrary; it may include a single outpatient visit or a hospitalization, or extend over significant period of time, e.g., the duration of a pregnancy, or an oncology treatment regimen, or a cardiac episode from infarction through rehabilitation. A Service Episode may involve one or more Healthcare Organizations.”
SEQ DT OPT RP/# TBL# ITEM# ELEMENT NAME
...      
53STO  02290Service Episode Description
54CXO  02291Service Episode Identifier

A new Adverse Reaction Information segment (IAR) and new fields (to IAM - Allergy Reaction) were introduced to allow for an improved management of allergy and adverse reaction information. New fields (fields 21 up to 30) were added to the IAM segment to communicate who and when an allergy was created, modified, and inactivated. The IAR segment is used to transmit information associated with this single reaction occurrence for a particular patient allergy. Each IAM segment may have zero or more IAR segments associated with it. Both segments are exclusively used in the Adverse Reaction Information message (ADT^A60).

2.2 Demographics

In prior versions of the standard two distinct fields were used to identify either the Phone number – Home or the Phone number – Business. These fields (PID-13, PID-14, NK1-5, NK1-6) have now been designated as B (for backwards compatibility only), and a new field (of data type XTN) has been added (PID-40 and NK1-40). The XTN-2 Telecommunication Use Code component can be used to indicate the use (e.g. home, workplace) of a phone number.

3. Chapters 4 and 7

Chapters 4 and 7 cover messages related to orders and observations. Prescription ordering has been enhanced; the Pharmacy and Immunization content has been moved to a new Chapter 4A.

3.1 Participations

A new Participation Information (PRT) segment was added to chapter 7. The PRT segment contains the data necessary to add, update, correct, and delete from the record persons, organizations, or locations (participants) participating in the activity being transmitted. In general, the PRT segment is used to describe a participant playing a particular role within the context of the message. The positional location of the PRT segment indicates the relationship. When the segment is used following the OBX segment, then the participations relate to the relevant participations in the result.

The definition of the PRT segment is inspired by the 'managed participation' as present in HL7 version 3. The PRT segment is defined as follows:
SEQ DT OPT RP/# TBL# ITEM# ELEMENT NAME
1EICN 02379Participation Instance ID
2IDR 028700816Action Code
3CWEO  02380Action Reason
4CWER 091202381Participation
5XCNCY 02382Participation Person
6CWEC  02383Participation Person Provider Type
7CWEC 040602384Participant Organization Unit Type
8XONCY 02385Participation Organization
9PLCY 02386Participant Location
10EICY 02348Participation Device
11DTMO  02387Participation Begin Date/Time (arrival time)
12DTMO  02388Participation End Date/Time (departure time)
13CWEO  02389Participation Qualitative Duration
14XADCY 02390Participation Address
15XTNOY 02391Participant Telecommunication Address
Field PRT-4 contains a code (from table 0912) to indicate the participation type. Examples include: AT - attending provider, AUT - Author/Event Initiator, OP - Ordering Provider, CP - Consulting Provider.

The PRT segment was added to the message definitions in chapters 4 and 7. A large number of ORC/OBR/OBX fields which indicate involved parties/persons were designated 'for backwards compatibility only'. The fields concerned are ORC-10,11,12,17,18,19,21,22,23,24; OBR-10,16,28, and OBX-15,16,18,23,24,25.

3.2 Parent Results

A couple of new fields were added to OBR (OBR-51, 52, 53) to enable linking a result to a parent result. The prior approach to link results was based on fields ORC-31 and OBR-50 (Parent Universal Service ID); those fields have now been designated as 'for backwards compatibility only'.

The highlights of the changes to OBR are shown below:
SEQ DT OPT RP/# TBL# ITEM# ELEMENT NAME
...      
50CWEB  02286Parent Universal Service Identifier
51EIO  02307Observation Group ID
52EIO  02308Parent Observation Group ID
53CXYY 03303Alternate Placer Order Number

3.3 Specimen updates

The Specimen (SPM) segment has been extended with a number of fields, of which SPM-30 (Accession Id) is the most noteworthy. This field contains unique accession identifier(s) associated with the specimen. In many cases, applications involved in the collection, transportation or testing of the specimen will assign their own accession identifiers. This field allows communication of these accession identifiers. An accession id may or may not, depending up laboratory practice, identify a single specimen.

Two new specimen shipment messages were added to chapter 4: Specimen shipment centric laboratory order (OML^O39) - to apply an order to all specimens in a shipment or a package within a shipment; and a Specimen shipment centric laboratory order response (ORL^O40). In order to support this use case a new field Shipment ID was added to the SPM segment as field SPM-32.

A Specimen Shipment manifest message (OSM^R26) with associated new segments was added to chapter 7. This message serves to communicate the contents of a specimen shipment to a specimen receiver (typically a laboratory). The use of this message is linked to the use of OML^O39, ORL^O40. Newly defined segments for this message type are SHP (Shipment) and PAC (Shipping Package).

4. Chapter 9

Chapter 9 covers messages related to the (transcription/archival of) medical documents. The TXA segment was extended with new fields (see below). TXA-24 is based on a use case similar to that in the IHE XDS profile: a document may either be part of none or several folders. In practice this can be used to separate the documents into domain specific types (e.g., cardiology reports, radiology reports), organizational types (e.g., administrational document, billing document), body region types (e.g., chest CT, leg CT), or something else.
SEQ DT OPT RP/# TBL# ITEM# ELEMENT NAME
...      
24CWEOY 02378Folder Assignment
25STOY 02301Document Title
26DTMO  03302Agreed Due Date/Time

5. Chapter 10

Chapter 10 covers messages related to the scheduling of scarce resources. A new broadcast notification of scheduled appointments message (SIU^S27) was added in version 2.7 to send a snapshot of a schedule.

The event is triggered on the filler application in advance of upcoming, active, scheduled appointments according to preset time considerations. Given those configured time considerations (e.g. the trigger is configured to take place every 24 hours), the trigger event includes information for any/all scheduled appointments for the preset event processing period (e.g. all scheduled events for 'today').

An example use case is the 'Patient appointment reminder' scenario whereby a patient is notified by text/SMS/e-mail of an upcoming appointment.

6. Chapter 11

Chapter 11 covers messages related to referrals. A suite of Messages called the Collaborative Care Message (CCM) was added in version 2.7. These message definitions and event codes define the collaborative care exchanges, including patient referral, discharge summary and infectious diseases notifications.

These messages include the aspects of

  • being able to share information without requiring a transfer of care and
  • can pertain to a group of people rather than just individuals and are therefore suitable for public health notifications/request as well as patient centric care.
The new messages are: CCM^I21, CCR^I16, CCR^I17, CCR^I18, CCU^I20, CCQ^I19, CQU^I19, CCF^I22 and CCI^I22.

7. References/Sources


About Ringholm bv

Ringholm 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, mentoring and advice in integration standards and technologies.
See http://www.ringholm.com or call +31 33 7 630 636 for additional information.