---

Summary

The highlights of version 2.6 in comparison to 2.5 include:

• Two new chapters have been added.
• The specification of message profiles has been moved to a chapter 2B.
• The CE data type has been deprecated and replaced by the CNE and CWE data types.
• The TS data type has been withdrawn and removed from the standard and has been replaced by the DTM data type.
• Two new segments have been added to either all or a large subset of messages: UAC and ARV
• The concept of "Mood-Code" has been added to a number of segments.

1. Introduction

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

• The first component (the code) is required.
• The specified HL7 table or imported or externally defined coding system must be used and may not be extended with local values. Note: this means that the CNE data type cannot be used in combination with a "user-defined Table".

SEQ	LEN	DT	OPT	TBL#	COMPONENT NAME	SEC. REF.
1	20	ST	R		Identifier	2.A.74
2	199	ST	O		Text	2.A.74
3	20	ID	O	0396	Name of Coding System	2.A.35
4	20	ST	O		Alternate Identifier	2.A.74
5	199	ST	O		Alternate Text	2.A.74
6	20	ID	O	0396	Name of Alternate Coding System	2.A.35
7	10	ST	C		Coding System Version ID	2.A.74
8	10	ST	O		Alternate Coding System Version ID	2.A.74
9	199	ST	O		Original Text	2.A.74

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:

SEQ	LEN	DT	OPT	TBL#	COMPONENT NAME	SEC. REF.
1	20	ST	O		Identifier	2.A.74
2	199	ST	O		Text	2.A.74
3	20	ID	O	0396	Name of Coding System	2.A.35
4	20	ST	O		Alternate Identifier	2.A.74
5	199	ST	O		Alternate Text	2.A.74
6	20	ID	O	0396	Name of Alternate Coding System	2.A.35
7	10	ST	C		Coding System Version ID	2.A.74
8	10	ST	O		Alternate Coding System Version ID	2.A.74
9	199	ST	O		Original Text	2.A.74

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:

SEQ	LEN	DT	OPT	TBL#	COMPONENT NAME	SEC. REF.
1	1027	HD	O		Source Application	2.A.33
2	11	ID	R	0834	Type of Data	2.A.35
3	32	ID	O	0291	Data Subtype	2.A.35
4	6	ID	R	0299	Encoding	2.A.35
5	65536	TX	R		Data	2.A.78

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:

Value	Description	Comment
application	Application data
audio	Audio data
image	Image data
model	Model data	RFC 2077
text	Text data
video	Video data
multipart	MIME multipart package

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.

Value	Description	Comment
x-hl7-cda-level-one	HL7 Clinical Document Architecture Level One document	Retained for backwards compatibility only as of v2.6 and CDA R 2. Preferred value is text/xml.

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.

SEQ	LEN	DT	OPT	RP/#	TBL#	ITEM#	ELEMENT NAME
1	4	CWE	R		0615	02267	User Authentication Credential Type Code
2	65536	ED	R			02268	User Authentication Credential

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.

• ARV - Access Restriction

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

SEQ	LEN	DT	OPT	RP/#	TBL#	ITEM#	ELEMENT NAME
12	1103	XPN	O			02156	Name of Coder
13	705	CWE	O		0734	02157	Grouper Status
14	20	CWE	O		0728	02158	PCCL Value Code
15	5	NM	O			02159	Effective Weight
16	20	MO	O			02160	Monetary Amount
17	20	IS	O		0739	02161	Status Patient
18	100	ST	O			02162	Grouper Software Name and Version
19	20	IS	O		0742	02163	Status Financial Calculation
20	20	MO	O			02164	Relative Discount/Surcharge
21	20	MO	O			02165	Basic Charge
22	20	MO	O			02166	Total Charge
23	20	MO	O			02167	Discount/Surcharge
24	5	NM	O			02168	Calculated Days
25	20	IS	O		0749	02169	Status Gender
26	20	IS	O		0749	02170	Status Age
27	20	IS	O		0749	02171	Status Length of Stay
28	20	IS	O		0749	02172	Status Same Day Flag
29	20	IS	O		0749	02173	Status Separation Mode
30	20	IS	O		0755	02174	Status Weight at Birth
31	20	IS	O		0757	02175	Status Respiration Minutes
32	20	IS	O		0759	02176	Status Admission

7.2 DG1 segment

SEQ	LEN	DT	OPT	RP/#	TBL#	ITEM#	ELEMENT NAME
22	427	EI	C			02152	Parent Diagnosis
23	705	CWE	O		0728	02153	DRG CCL Value Code
24	20	IS	O		0136	02154	DRG Grouping Usage
25	20	IS	O		0731	02155	DRG Diagnosis Determination Status

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

SEQ	LEN	DT	OPT	RP/#	TBL#	ITEM#	ELEMENT NAME
21	20	IS	O		0761	02177	DRG Procedure Determination Status
22	20	IS	O		0763	02178	DRG Procedure Relevance

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.

SEQ	LEN	DT	OPT	RP/#	TBL#	ITEM#	ELEMENT NAME
1	250	CNE	O		0055	00382	Diagnostic Related Group
2	1	CNE	C		0830	00381	Major Diagnostic Category
3	7	NR	C			02231	Lower and Upper Trim Points
4	5	NM	C			02232	Average Length of Stay
5	7	NM	C			02233	Relative Weight

8. Mood-Code

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:

INT	Intent
APT	Appointment
ARQ	Appointment Request
PRMS	Promise
PRP	Proposal
RQO	Request-Order
EVN	Event
EVN.CRT	Event Criterion
EXP	Expectation

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:

• O37: OPL - Population/Location-Based Laboratory Order Message
• O38: OPR - Population/Location-Based Laboratory Order Acknowledgment Message

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:

• EQQ - embedded query language query
• RQQ - event replay query
• SPQ - stored procedure request
• VQQ - Virtual Table query

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:

• R25: OPU - Unsolicited Population/Location-Based Laboratory Observation Message

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

SEQ	LEN	DT	OPT	RP/#	TBL#	ITEM#	ELEMENT NAME
1	4	SI	C			02240	Set ID - REL
2	705	CWE	R			02241	Relationship Type
3	60	EI	R			02242	This Relationship Instance Identifier
4	60	EI	R			02243	Source Information Instance Identifier
5	60	EI	R			02244	Target Information Instance Identifier
6	60	EI	O			02245	Asserting Entity Instance ID
7	250	XCN	O			02246	Asserting Person
8	250	XCN	O			02247	Asserting Organization
9	250	XAD	O			02248	Assertor Address
10	250	XTN	O			02249	Assertor Contact
11	53	DR	O			02250	Assertion Date Range
12	1	ID	O		0136	02251	Negation Indicator
13	705	CWE	O			02252	Certainty
14	26	NM	O			02253	Priority No ( relative ordering, workflow: plans etc)
15	250	NM	O			02254	Priority Sequence No ( rel preference for consideration)
16	1	ID	O		0136	02255	Separability Indicator

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:

• Submit Health Services Invoice
• Edit/Adjudication Results
• Request Additional Information
• Payment/Remittance Advice
• Submit Authorization Request
• Authorization Response
• Query Eligibility

The following trigger events have been defined:

• E01: Submit Health Services Invoice
• E02: Cancel Health Services Invoice
• E03: Query Health Services Invoice Status
• E04: Re-Assess HealthCare Services Invoice
• E10: Edit/Adjudication Results
• E12: Request Additional Information
• E13: Additional Information Response
• E15: Payment/Remittance Advice
• E20: Submit Authorization Request
• E21: Cancel Authorization Request
• E22: Query Authorization Request
• E24: Authorization Response
• E45: Query Eligibility

In order to construct the above messages a number of segments have been added:

• ADJ - Adjustment
• IPR - Invoice Processing Results
• IVC - Invoice Segment
• PMT - Payment Information
• PSS - Product/Service Section
• PSG - Product/Service Group
• PSL - Product/Service Line Item
• PYE - Payee Information
• RTI - Request for Information

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.

• The inventory item master updates topic covers the exchange of common materials-related reference files, known in HL7 as master files, between applications such as materials management, scheduling, and sterilization applications.
• The sterilization and decontamination topic covers orders and order-related information between an instrument-tracking system and a sterilizer or washer.

For example, this transaction set permits for the transmission of:

• Inventory Item Master Catalog Add
• Request new Sterilization Lot
• Notification of Anti-Microbial Device Data

Inventory Item Master Updates

Eight new segments related to "Inventory Item Master":

• IIM - INVENTORY ITEM MASTER SEGMENT
• ITM - MATERIAL ITEM SEGMENT
• STZ - STERILIZATION PARAMETER SEGMENT
• VND - PURCHASING VENDOR SEGMENT
• PKG - PACKAGING SEGMENT
• PCE - PATIENT CHARGE COST CENTER EXCEPTION
• IVT - MATERIAL LOCATION SEGMENT
• ILT - MATERIAL LOT SEGMENT

Placer Request:

• SLR/SLS - REQUEST NEW STERILIZATION LOT (EVENT S28)
• SLR/SLS - REQUEST STERILIZATION LOT DELETION (EVENT S29)
• STI/STS - REQUEST ITEM (EVENT S30)
• SDR/SDS - REQUEST ANTI-MICROBIAL DEVICE DATA (EVENT S31)
• SMD/SMS - REQUEST ANTI-MICROBIAL DEVICE CYCLE DATA (EVENT S32)

Filler Request:

• STC/ACK - NOTIFICATION OF STERILIZATION CONFIGURATION (EVENT S33)
• SLN/ACK - NOTIFICATION OF NEW STERILIZATION LOT (EVENT S34)
• SLN/ACK - NOTIFICATION OF STERILIZATION LOT DELETION (EVENT S35)
• SDN/ACK - NOTIFICATION OF ANTI-MICROBIAL DEVICE DATA (EVENT S36)
• SCN/ACK - NOTIFICATION OF ANTI-MICROBIAL DEVICE CYCLE DATA (EVENT S37)

Sterilization and Decontamination

Four new segments related to "Sterilization and Decontamination":

• SCP - STERILIZER CONFIGURATION SEGMENT
• SLT - STERILIZATION LOT SEGMENT
• SDD - STERILIZATION DEVICE DATA SEGMENT
• SCD - ANTI-MICROBIAL CYCLE DATA SEGMENT

14. References

[HL7] "HL7", 2007, http://www.hl7.org/, Version 2.6.

---

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 and consulting on healthcare information exchange standards.