Appendix C: HL7 Profiling Conventions

The HL7 tables included in this document have been modified from the HL7 2.5 standard document. Such a modification is called a profile. Refer to the HL7 2.5 standard for the meanings of specific columns in the table.

The profiling tables in this document leverage the ongoing HL7 profile definition. To maintain this specification at a generic level, the following differences have been introduced:

• Message specifications do not indicate the cardinality of segments within a message.
• For fields composed of multiple components, there is no indication of the size of each component.
• Where a table containing enumerated values is referenced from within a segment profile table, the enumerated values table is not always present.
• The number of times a repeating field can repeat is not indicated.
• The conditions that would require inclusion of conditional fields are not defined when they depend on functional characteristics of the system implementing the transaction and they do not affect data consistency.

The following terms refer to the OPT column, which has been profiled:

R   Required

R2   This is an IHE extension. If the sending application has data for the field, it is required to populate the field. If the value is not known, the field may not be sent.

R+   This is an IHE extension. This is a field that IHE requires that was listed as optional within the HL7 standard.

O   Optional

C   Conditional

IHE requires that Z-segments be present in HL7 transactions only when explicitly provided for within the associated IHE message profile specification. According to the HL7 standard, if the value of a field is not present, the receiver shall not change corresponding data in its database. However, if sender includes explicit NULL value (i.e., two double-quotes “”), it shall cause removal of any values for that field in the receiver’s database.

Table C-1 provides a sample profile for an imaginary HL7 segment. Tables for real segments are copied from the HL7 2.5 standard with modifications made only to the OPT column.

Table C-1: Sample HL7 Profile

SEQ	LEN	DT	OPT	TBL#	ITEM #	ELEMENT NAME
1	1	ST	R		xx001	Element 1
2	4	ST	O		xx002	Element 2
3	180	HD	R2		xx003	Element 3
4	180	HD	C		xx004	Element 4
5	180	HD	O		xx005	Element 5
6	180	HD	R+		xx006	Element 6

 

C.1 HL7 Message Profiling Convention

The messages used by each transaction are described in this document using static definitions as described for HL7 constrainable message profiles; refer to HL7 Version 2.5, Chapter 2, Section 2.12.6. The static definition of each message is represented within tables. The message level table represents the IHE-constrained message structure with its list of usable segments. The segment level table represents the IHE-constrained content of one segment with its usable fields.

C.1.1 Static definition - Message level

The message table representing the static definition contains 5 columns:

• Segment: gives the segment name, and places the segment within the hierarchy of the message structure designed by HL7, but hiding the traditional square brackets and braces that designate optionality and repeatability in HL7 standard message tables. The beginning and end lines of a segment group (see HL7 Version 2.5, Chapter 2, Section 2.5.2 for definition) are designated in this column by --- (3 dashes).
• Meaning: Meaning of the segment as defined by HL7. The beginning of a segment group is designated by one line in this column giving the segment group name in all caps, prefixed by --- (3 dashes), and followed by the keyword “begin”. The end of a segment group is designated by one line in this column giving the segment group name in all caps, prefixed by --- (3 dashes), and followed by the keyword “end”.
• Usage : Coded usage of the segment, in the context of this IHE Integration Profile. The coded values used in this column are:

• R Required: A compliant sending application shall populate all "R" elements with a non-empty value. A compliant receiving application may ignore the information conveyed by required elements. A compliant receiving application shall not raise an error due to the presence of a required element, but may raise an error due to the absence of a required element.
• RE - Required but may be empty. The element may be missing from the message, but shall be sent by the sending application if there is relevant data. A conformant sending application shall be capable of providing all "RE" elements. If the conformant sending application knows a value for the element, then it shall send that value. If the conformant sending application does not know a value, then that element may be omitted.
  Receiving applications may ignore data contained in the element, but shall be able to successfully process the message if the element is omitted (no error message should be generated if the element is missing).
• O - Optional. The usage for this field within the message is not defined. The sending application may choose to populate the field; the receiving application may choose to ignore the field.
• C - Conditional. This usage has an associated condition predicate. (See HL7 Version 2.5, Chapter 2, Section 2.12.6.6, "Condition Predicate".)
  If the predicate is satisfied: A compliant sending application shall populate the element. A compliant receiving application may ignore data in the element. It may raise an error if the element is not present.
  If the predicate is NOT satisfied: A compliant sending application shall NOT populate the element. A compliant receiving application shall NOT raise an error if the condition predicate is false and the element is not present, though it may raise an error if the element IS present.
• CE - Conditional but may be empty. This usage has an associated condition predicate. (See HL7 Version 2.5, Chapter 2, Section 2.12.6.6, "Condition Predicate".)
  If the predicate is satisfied: If the conforming sending application knows the required values for the element, then the application must populate the element. If the conforming sending application does not know the values required for this element, then the element shall be omitted. The conforming sending application must be capable of populating the element (when the predicate is true) for all ‘CE’ elements. If the element is present, the conformant receiving application may ignore the values of that element. If the element is not present, the conformant receiving application shall not raise an error due to the presence or absence of the element.
  If the predicate is NOT satisfied: The conformant sending application shall not populate the element. The conformant receiving application may raise an application error if the element is present.
• X - Not supported. For conformant sending applications, the element will not be sent. Conformant receiving applications may ignore the element if it is sent, or may raise an application error.

• Cardinality: Within square brackets, minimum and maximum number of occurrences authorized for this segment in the context of this Integration Profile.
• HL7 chapter: Reference of the HL7 v2.5 chapter that describes this segment.

C.1.2 Static definition – Segment level and Data Type level

The Segment Table and the Data Type Table each contain 8 columns:

• SEQ : Position (sequence) of the field within the segment.
• LEN : Maximum length of the field
• DT : Field Data Type
• Usage : Usage of the field within this IHE Integration Profile. Same coded values as in the message level: R, RE, C, CE, O, X.
• Cardinality : Minimum and maximum number of occurrences for the field in the context of this Integration Profile.
• TBL# : Table reference (for fields using a set of defined values)
• ITEM# : HL7 unique reference for this field
• Element Name : Name of the field in a Segment table. / Component Name: Name of a subfield in a Data Type table.

Table C.1.2-1: Example: The MSH segment description

SEQ	LEN	DT	Usage	Card.	TBL#	ITEM#	Element name
1	1	ST	R	[1..1]		00001	Field Separator
2	4	ST	R	[1..1]		00002	Encoding characters
3	227	HD	R	[1..1]	0361	00003	Sending Application
…

C.2 HL7 Implementation Notes

C.2.1 Network Guidelines

The HL7 2.5 standard does not define a network communications protocol. Beginning with HL7 v2.2, the definitions of lower layer protocols were moved to the Implementation Guide, but are not HL7 requirements. The IHE Framework makes these recommendations:

1. Applications shall use the Minimal Lower Layer Protocol defined in Appendix C of the HL7 Implementation Guide.
2. An initiating application that wants to send a message (initiate a transaction) will initiate a network connection to start the transaction. The receiver application will respond with an acknowledgement or response to query over the open connection. The initiating application can initiate a new transaction on the same connection. However, the initiating application must be able to handle cases where the connection has been closed due to possible timeout by the accepting application. For example if the initiating application does not submit a request over the connection in a timely manner, the accepting application has the right to close the connection. When this condition is detected, the initiating application needs to open a new connection for subsequent requests.

C.2.2 Message Control

According to the HL7 standard, each message shall begin with the MSH (message header) segment. Table C.2.2-1 identifies all required fields in this message. This table shall be interpreted according to the HL7 Standard unless otherwise noted in Appendix C.

Table C.2.2-1: IHE Profile - MSH segment

SEQ	LEN	DT	OPT	TBL#	ITEM #	Element Name
1	1	ST	R		00001	Field Separator
2	4	ST	R		00002	Encoding Characters
3	180	HD	R+		00003	Sending Application
4	180	HD	R+		00004	Sending Facility
5	180	HD	R+		00005	Receiving Application
6	180	HD	R+		00006	Receiving Facility
7	26	TS	R		00007	Date/Time Of Message
8	40	ST	O		00008	Security
9	13	CM	R	0076/ 0003	00009	Message Type
10	20	ST	R		00010	Message Control ID
11	3	PT	R		00011	Processing ID
12	60	VID	R	0104	00012	Version ID
13	15	NM	O		00013	Sequence Number
14	180	ST	O		00014	Continuation Pointer
15	2	ID	O	0155	00015	Accept Acknowledgment Type
16	2	ID	O	0155	00016	Application Acknowledgment Type
17	3	ID	O	0399	00017	Country Code
18	16	ID	C	0211	00692	Character Set
19	250	CE	O		00693	Principal Language Of Message
20	20	ID	O	0356	01317	Alternate Character Set Handling Scheme
21	427	EI	O		01598	Message Profile Identifier #

Adapted from the HL7 Standard, version 2.5 and version 2.3.1

Note: This element is only applicable in HL7 version 2.5 and later, and thus is only applicable for those transactions based on HL7 v2.5 and later.

The IHE IT Infrastructure Technical Framework requires that applications support HL7-recommended values for the fields MSH-1-Field Separator and MSH-2-Encoding Characters .

Field MSH-18-Character Set shall only be valued if the message utilizes character sets other than ISO IR-6, also known as ASCII.

Implementations supporting sequence number protocol (and using the field MSH-13-Sequence Number) shall be configurable to allow them to perform transactions without such protocol.

In messages conforming to an IHE Transaction using HL7 v2.5 and later, it is recommended that field MSH-21-Message Profile Identifier contain one field repetition with a value representing the IHE transaction identifier, in the form “<domain>-<transaction number>^IHE” (e.g., “ITI-10^IHE”). Other field repetitions may be present with global (HL7-registered), vendor specific, and/or realm specific message profile IDs.

C.2.3 Acknowledgment Modes

IHE supports both Acknowledgement Modes specified in HL7 standard v2.5 (see HL7 Standard, Section 2.9 “Message Processing Rules”): Original Acknowledgement Mode and Enhanced Acknowledgement Mode.

An IHE transaction which uses HL7 messages will explicitly include the requirement for enhanced mode if used. If no such statement is specified, the transaction shall use only original mode.

This section specifies the common structure of the Application Level Acknowledgement Message in the Original Mode (called Application ACK Message for short), and the Commit Acknowledgement Message in the Enhanced Mode (called Commit ACK Message for short).

The Application Level Acknowledgement Message in the Enhanced Mode contains the application-specific content, and shall be explicitly specified in the corresponding transaction which requires it. A transaction can, however, refer to the Application ACK Message specified in this section as its Application Level Acknowledgement Message in the enhanced mode if it is suitable.

Table C.2.3-1: Common ACK static definition:

Segment	Meaning	Usage	Card.	HL7 chapter
MSH	Message Header	R	[1..1]	2
MSA	Message Acknowledgement	R	[1..1]	2
ERR	Error	C	[0..*]	2

In the original mode, the ACK message conveys application errors (if any) detailed by the receiving application.

The receiving application shall reject an incoming message, if it does not recognize either the message type (MSH-9.1) or the trigger event (MSH-9.2).

In the Application ACK message, this is an application-rejection, and field MSA-1 of the acknowledgement shall contain the value AR.

In the Commit ACK message, this is a commit-rejection, and Field MSA-1 of the acknowledgement shall contain the value CR.

The components of Field ERR-2 of the acknowledgement shall be populated as follows.

The components of Field ERR-3 of the acknowledgement shall be populated as follows.

Details of field encoding of these segments are discussed in the following sections.

C.2.3.1   MSA - Message Acknowledgement segment

Standard Reference: HL7 Version 2.5, Chapter 2 (Section 2.15, “Message control”)

This segment contains information sent while acknowledging another message.

Table C.2.3.1-1: MSA - Message Acknowledgement

SEQ	LEN	DT	Usage	Card.	TBL#	ITEM#	Element name
1	2	ID	R	[1..1]	0008	00018	Acknowledgement code
2	20	ST	R	[1..1]		00010	Message Control Id
3	80	ST	X	[0..0]		00020	Text Message
4	15	NM	O	[0..1]		00021	Expected Sequence Number
5			X	[0..0]		00022	Delayed Acknowledgment Type
6	250	CE	X	[0..0]	0357	00023	Error Condition

MSA-1 Acknowledgment Code (ID) , required.

As is the case throughout IHE, original mode acknowledgement is in use. IHE ITI authorizes two value sets of the acknowledgement codes, both taken from HL7 Table 0008 - Acknowledgement code for the Application and Commit ACK messages, respectively.

In the original mode, the Application ACK message shall use one of the following three codes to populate Field MSA-1:

Table C.2.3.1-2: HL7 Table 0008 - Acknowledgement codes in Application ACK message

Value	Description	Comment
AA	Original mode: Application Accept	The message has been accepted and integrated by the receiving application
AE	Original mode: Application Error	The message contains errors. It SHALL not be sent again without correcting the error.
AR	Original mode: Application Reject	The message has been rejected by the receiving application. If the rejection is not related to an invalid value in the MSH segment, the sender may try again to send the message later.

In the enhanced mode, the Commit ACK message shall use one of the following three codes to populate Field MSA-1:

Table C.2.3.1-3: HL7 Table 0008 - Acknowledgement codes in Commit ACK message

Value	Description	Comment
CA	Enhanced mode: Commit Accept	The message has been received and safe-kept in the receiving application for processing. No resend is required.
CE	Enhanced mode: Commit Error	The message contains errors. It SHALL not be sent again without correcting the error.
CR	Enhanced mode: Commit Reject	The message has been rejected by the receiving application. If the rejection is not related to an invalid value in the MSH segment, the sender may try again to send the message later.

MSA-2 Message Control ID (ST) , required.

Definition: This field contains the message control ID from Field MSH-10-Message Control ID of the incoming message for which the acknowledgement is sent.

MSA-3 Text Message (ST) , not supported. See the ERR segment.

MSA-6 Error Condition (CE) , not supported. See the ERR segment.  

C.2.3.2   ERR - Error segment

Standard Reference: HL7 Version 2.5, Chapter 2 (Section 2.15, “Message control”)

This segment is used to add error comments to acknowledgment messages.

Table C.2.3.2-1: ERR – Error segment

SEQ	LEN	DT	Usage	Card.	TBL#	ITEM#	Element name
1	493	ELD	X	[0..0]		00024	Error Code and Location
2	18	ERL	RE	[0..*]		01812	Error Location
3	705	CWE	R	[1..1]	0357	01813	HL7 Error Code
4	2	ID	R	[1..1]	0516	01814	Severity
5	705	CWE	O	[0..1]	0533	01815	Application Error Code
6	80	ST	O	[0..10]		01816	Application Error Parameter
7	2048	TX	O	[0..1]		01817	Diagnostic Information
8	250	TX	O	[0..1]		01818	User Message
9	20	IS	O	[0..*]	0517	01819	Inform Person Indicator
10	705	CWE	O	[0..1]	0518	01820	Override Type
11	705	CWE	O	[0..*]	0519	01821	Override Reason Code
12	652	XTN	O	[0..*]		01822	Help Desk Contact Point

ERR-1 is deprecated in HL7 Version 2.5 (i.e., retained for backward compatibility only) and therefore not supported by IHE.

ERR-2 is populated except when the error is not within an HL7 field, component or subcomponent. For example, if the receiver returns an acknowledgement containing MSA-2-acknowledgement code value AR or CR to indicate that the receiving application was unavailable, ERR-2 is not populated.

ERR-3 HL7 Error Code (CWE) is required. It identifies the HL7 (communication) error code. Valid values are given by HL7 Table 0357:

HL7 Table 0357: Message error condition codes

Value	Description	Comment
0	Message accepted	Success. Optional, as the AA conveys success. Used for systems that must always return a status code.
100	Segment sequence error	Error: The message segments were not in the proper order, or required segments are missing.
101	Required field missing	Error: A required field is missing from a segment
102	Data type error	Error: The field contained data of the wrong data type, e.g., an NM field contained "FOO".
103	Table value not found	Error: A field of data type ID or IS was compared against the corresponding table, and no match was found.
200	Unsupported message type	Rejection: The Message Type is not supported.
201	Unsupported event code	Rejection: The Event Code is not supported.
202	Unsupported processing id	Rejection: The Processing ID is not supported.
203	Unsupported version id	Rejection: The Version ID is not supported.
204	Unknown key identifier	Rejection: The ID of the patient, order, etc., was not found. Used for transactions other than additions, e.g., transfer of a non-existent patient.
205	Duplicate key identifier	Rejection: The ID of the patient, order, etc., already exists. Used in response to addition transactions (Admit, New Order, etc.).
206	Application record locked	Rejection: The transaction could not be performed at the application storage level, e.g., database locked.
207	Application internal error	Rejection: A catchall for internal errors not explicitly covered by other codes.

ERR-4 Severity (ID) is required. It identifies the severity of an application error. Valid values are given by HL7 Table 0516:

HL7 Table 0516: Error severity

Value	Description	Comment
W	Warning	Transaction successful, but there may be issues
I	Information	Transaction was successful but includes information, e.g., inform patient
E	Error	Transaction was unsuccessful

C.2.4 Common Segment Definitions

The following table specifies the contents of the EVN segment that is common to several HL7-based messages defined in ITI TF-2.

Table C.2.4-1: IHE Profile - EVN segment

SEQ	LEN	DT	OPT	TBL#	ITEM#	ELEMENT NAME
1	3	ID	O	0003	00099	Event Type Code
2	26	TS	R		00100	Recorded Date/Time
3	26	TS	O		00101	Date/Time Planned Event
4	3	IS	O	0062	00102	Event Reason Code
5	60	XCN	O	0188	00103	Operator ID
6	26	TS	R2		01278	Event Occurred
7	180	HD	O (Note 1)		01534	Event Facility #

Adapted from the HL7 Standard, version 2.5 and version 2.3.1

Note 1: This element is only applicable in HL7 version 2.5 and thus is only applicable for those transactions based on HL7 v2.5

Field EVN-1-Event Type Code is optional; however, if present, its value shall be equal to the second component of the field MSH-9-Message Type .

C.2.5 Message granularity

The sending application shall send as many messages as there are events recorded. For instance, if at the same time there is a change both to the patient’s location (from emergency room to GI surgery ward) and to the patient’s attending doctor (from Dr. Eric Emergency to Dr. John Appendectomy), the sending application will transmit two movements using HL7 messages ADT^A02 (transfer) and ADT^A54 (change attending doctor). Both events will have the same effective date/time (EVN-6 – Event Occurred). If the Historic Movement Option is in use, each of these movements will have a unique identifier.

The exceptions to this fine granularity are:

• The Admit Inpatient (A01) and Register Outpatient (A04) events can also assign a location and an attending doctor to the patient, known when the event is recorded.
• A change of patient class (A06 or A07) also assigns at the same time a new location to the patient.
• The Cancel Discharge/End Visit event also includes at the same time the patient location after the cancellation has been processed.

C.2.6 HL7 empty field convention

According to the HL7 standard, if the value of a field is not present, the receiver shall not change corresponding data in its database. However, if the sender defines the field value to be the explicit NULL value (i.e., two double quotes ""), it shall cause removal of any values for that field in the receiver's database. This convention is fully applied by IHE profiles based on HL7 v2.x messages.