New features of HL7 version 2.7
The contents of this whitepaper are published under the Creative Commons Attribution-Share Alike license.
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:
1. Chapter 2Chapter 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, truncationChanges 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:
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 requirementsRE 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.
The table below shows the highlights of the updates to the XPN data type:
The table below shows the highlights of the updates to the CX data type:
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).
2. Chapter 3Chapter 3 covers messages related to patient/person demographics and encounters/visits.
2.1 Encounter/VisitA 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.�
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 DemographicsIn 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 7Chapters 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 ParticipationsA 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:
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 ResultsA 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:
3.3 Specimen updatesThe 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 9Chapter 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.
5. Chapter 10Chapter 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 11Chapter 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
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, mentoring and advice in integration standards and technologies.