Transmission Infrastructure

Introduction

The Health Level Seven (HL7) Standard applies to the electronic exchange of data in all healthcare environments. Within the context of healthcare messaging, the HL7 standard is primarily concerned with the data content of exchanges between healthcare applications, the sequence or interrelationships in the flow of messages and the communication of significant application level exceptions or error conditions.

This domain addresses the following aspects about the communications environment that is considered common to all HL7 Version 3 messaging implementations:

1. A specification for the composite HL7 version 3 message
2. A protocol for reliable message delivery
3. Generic "Communication Roles" that support the modes of HL7 messaging
4. Message control events that describe a framework for generic HL7 messaging

Scope

Message control in the HL7 Version 3 messaging standard addresses

1. the HL7 domain content for transport
2. the identification of sending and receiving entities for an HL7 messaging interaction
3. The relationship between interactions and generic "communication roles"

Generic Communication Environment for HL7 Messaging in Version 3

The primary purpose of the HL7 messaging standard is to support the exchange of common information content between healthcare applications. As a protocol at Level Seven of the ISO Open Systems Interconnection (OSI) model, HL7 relies upon well-defined protocols at the lower layers for mechanisms that ensure correct and complete packaging and delivery of message content.A generic communication environment for HL7 messaging has the following characteristics:

1. A specification for messages that supports the routing of messages to their specified destination(s)
2. A protocol for reliable message delivery that can support
   • An acknowledgment mode indicating if a message was delivered for subsequent processing
   • An acknowledgment mode indicating if a message was delivered to a specific application that acknowledges the receipt with or without a response prepared to return to the originating application
   • An optional sequence number protocol to ensure messages are processed in a specific order when necessary
   • Error handling rules for use cases consistent with HL7 messaging
   • Security services that are consistent with the current technology capabilities

To implement HL7 Version 3 messaging, the Version 3 messaging standard must be able to

1. specify how messaging communications should be conducted
2. respond to exceptions or errors that are experienced by a generic messaging framework that is processing an HL7 messaging interaction

The following sections briefly discuss how the Version 3 messaging standard reconciles information exchange needs with a generic messaging framework.

Specification for HL7 Version 3 Composite Message

An overview of the HL7 Version 3 Composite Message is given here for the purpose of conveying where information about a Version 3 message can be found by an application or message handling service that will be responsible for implementing the transport of HL7 Version 3 messages. At the highest level, an HL7 Version 3 Composite Message is currently composed of 3 components:

1. An "HL7 Transmission wrapper" (always)
2. A "Trigger Event Control Act" (required for all messages except accept level acknowledgements, for which it is not permitted)
3. The "HL7 Domain Content" specified by an HL7 domain specific technical committee (required for each Trigger Event Control Act)

Note: Transmission Infrastructure is not to be confused with the content of Transport Specifications. Transmission infrastructure describes the information model, messages and interactions related to the assembly of an HL7 v3 composite message. The Transport Specifications address moving to message payload (the HL7 v3 composite message) from sender to receiver.

This chapter of the Infrastructure specification provides detailed structural specifications for the "HL7 Transmission Wrapper". What follows are brief overviews of the purpose and content of the above mentioned 3 components.

HL7 Transmission Wrapper

The "HL7 Transmission wrapper" includes information needed by a sending application or message handling service to package and route the V3 Composite Message to the designated receiving application(s) and/or message handling service(s). This wrapper also includes attributes that identify a generic messaging mode. This generic messaging mode has a handling behavior that is consistent with the HL7 defined messaging interaction for which the composite message instance has been created. All HL7 Version 3 messages have an appropriately configured "HL7 Transmission wrapper".

Trigger Event Control Act

The "Trigger Event Control Act" contains administrative information related to the "controlled act" which is being communicated as a messaging interaction. It is also the part of HL7 messages that can convey status or commands for logical operations being coordinated between healthcare applications, e.g., the coordination of query specification/query response interactions and registry act interactions. The Control Act does not appear in accept level acknowledgements (i.e., messages used only for conveying the status of message communications) or with messages carrying commands to coordinate the operation of message handling services.

HL7 Domain Content

The "HL7 Domain Content" is the primary domain content of the messaging interaction (when it is present). It contains domain specific content that is specified by an HL7 technical committee to satisfy a use case driven requirement for an HL7 messaging interaction. Certain interactions will employ the use of Shared Messages (as defined in Shared Messages Domain) to e.g. convey status type changes and application level acknowledgements.

Protocol for Reliable Message Delivery

The HL7 messaging standard has historically maintained "Application (Level 7) Processing Rules" regardless of the lower layer protocols of the communications environment to guarantee reliable message delivery. Briefly, these rules specify

1. An accept level message acknowledgement by a message receiver
2. An application level message acknowledgement by a message receiver
3. An optional sequence number protocol

Applications using the HL7 messaging standard should observe these requirements to be guaranteed reliable message delivery. In the version 3 HL7 Message Development Framework, these rules should be specified as characteristic of Sending and Receiving Communication Roles and Receiving Application Communication Responsibilities. In the HL7 Version 3 Composite Message, these characteristics are visible in the HL7 transmission wrapper. It is the responsibility of Communication Roles that implement HL7 Version 3 Application Roles to enforce the appropriate handling for HL7 V3 messaging interactions. (Reference more discussion of Communication Roles below)

Levels of Acknowledgement

The HL7 transmission wrapper will specify what levels of acknowledgement will be provided by the receiving system and/or application. The levels are the accept-level ("commit") and the application-level. HL7 Version 3 standard added support for multiple receiving applications. In order to make this addition and still insist on the reliable delivery of messages without stalling sending applications, senders must include functionality to prevent such stalling. One approach would be to provide for a logically unique outbound message queue for each receiver. As such, a queue handler deals with only message acknowledgements from a single receiver and errors with that receiver would not stall messages being sent to other receivers.. Thus a problem with a communication link to one of many receivers should never delay a sending application. In addition, it should be noted that the HL7 Version 3 standard does not support acknowledgement protocols (such as 2-phase commit) that will suspend a sender until all receivers have acknowledged a particular message.

Accept Level Acknowledgement

The protocol software on the receiving system performs the following steps upon receiving a message:

1. Accepts the message
2. Makes an initial determination as to whether or not the message can be accepted, based on factors such as:
   • The status of the interface
   • The availability of safe storage onto which the message can be saved
   • The syntactical correctness of the message, if the design of the receiving system includes this type of validation at this phase
   • The interaction identifier, structure type identifier, version and processing code, if the design of the receiving system includes this type of validation at this phase
3. Examines the HL7 transmission wrapper to determine whether or not the initiating system requires an accept level acknowledgment. If it does, the responding system returns an accept level acknowledgment message with:
   • A commit accept (CA) acknowledgement type code if the message can be accepted for processing (this is sometimes referred to as an ACK - positive acknowledgement)
   • A commit reject (CR) in acknowledgement type code if the one of the validated values (above) is not acceptable to the receiving application (this is sometimes referred to as an NAK - negative acknowledgement)
   • A commit error (CE) in acknowledgement type code if the message cannot be accepted for any other reason (e.g., sequence number error; this is sometimes referred to as an NAK - negative acknowledgement).

Application level Acknowledgement

If the interaction, as indicated by the interaction identifier in the HL7 transmission wrapper, indicates that the initiating system also requires an application acknowledgment (sometimes referred to as a functional response), this can be returned as an immediate response or as the initial message of a later (or deferred) exchange. Accept-level Acknowledgements must be used with each transmission if the deferred Application-level option is chosen.

In this application acknowledgement mode, the application software on the destination system performs one of these functions:

1. Processes the message successfully, generating the functional response message with an AA acknowledgement type code
2. Sends a functional error response, providing error information in the domain content of the response message with an AE acknowledgement type code (sometimes referred to as an application error response)
3. Fails to process (reject) the message for reasons unrelated to its content or format (system down, internal error, etc.). For most such problems it is likely that the responding system will be able to accept the same message at a later time. The implementers must decide on an application-specific basis whether the message should be automatically sent again. The response message contains an AR acknowledgement type code (sometimes referred to as an application error response).

Certain interactions will employ the use of Shared Messages as the functional response. Refer to that section for further explanation and examples.

In the case of an application error or rejection response, the reason for the response must be communicated. Refer to the Trigger Event Control Act section for further explanation and examples.

The application acknowledgment (functional response) message is passed by the destination system to the initiating system, whose protocol software passes the response message to the initiating application.

For this message, the receiving system acts as the initiator. Since the message the receiving system sends is application-specific, the models of these application-level response messages are defined in the relevant application-specific domain. If needed, this application acknowledgment message can itself require an accept acknowledgment message. Whether an application response may request another application acknowledgment message, is dependent on the design of the message interaction sequence as defined in the relevant application-specific domain.

At this point, the application acknowledgment portion of this message exchange is considered complete.

If the processing on the receiving system goes through multiple stages, domain-defined messages may be used to relay status or informational changes to other systems (including the original initiating system). Such messages are not part of the acknowledgment scheme for the original message, but are considered to be independent messages triggered by events on the (original) responding system.

Sequence Number Protocol

For certain types of data transactions between systems the issue of keeping databases synchronized is critical. HL7 offers the option of a sequence number protocol. Although it is true that a simple one-to-one acknowledgement scheme can prevent out of sequence transactions, only the use of sequence numbers can prevent duplicate transactions.

When the sequence number protocol is implemented, the sequence number will be conveyed as an attribute of the Message class. The expected sequence number will be appropriately valued for acknowledgements when the sequence number protocol is in use.

Although this sequence number protocol is limited to the use of sequence numbers on a single transaction stream between two applications, this sequencing protocol is sufficiently robust to allow the design of HL7-compatible store-and-forward applications. Note that the implementation of HL7 Version 3 messaging may use a message transmission infrastructure that guarantees message delivery without duplicates. In such implementations, the use of the sequence number protocol as described in the following paragraphs is not needed.

The rules for managing the sequence number protocol are noted as follows:

1. Initial conditions:
   • The system receiving the data stream is expected to store the sequence number of the most recently accepted transaction in a secure fashion before acknowledging that transaction. This stored sequence number allows comparison with the next transaction's sequence number, and the implementation of fault-tolerant restart capabilities.
   • The initiating system keeps a queue of outgoing transactions indexed by the sequence number. The length of this queue must be negotiated as part of the design process for a given link. The minimum length for this queue is one.
   • The sequence number is a positive (non-zero) integer; and it is incremented by one (by the initiating system) for each successive transaction.
2. Starting the link:
   • The value of 0 (zero) for a sequence number is reserved: it is allowed only when the initiating system (re-)starts the link.
   • If the receiving system gets a transaction with a 0 (zero) sequence number, it should respond with an accept acknowledgment message whose expected sequence number element contains a sequence number one greater than the sequence number of the last transaction it accepted. If this value does not exist (as on the first startup of a given link), the expected sequence number element should contain a sequence number of -1, meaning that the receiving system will use the positive, non-zero sequence number of the first transaction it accepts as its initial sequence number (see re-synching the link, item e below).
   • The initiating system then sends the transaction indexed by the expected sequence number (if that expected transaction is still on its queue). Otherwise the link is frozen for a manual intervention.
3. Normal operation of the link: As it accepts each transaction, the receiving system:
   • securely stores the sequence number (which agrees with its expected sequence number)
   • acknowledges the correct sequencing of the message by sending the expected sequence number of the next message in Acknowledgement.expectedSequenceNumber
4. Error conditions (from point of view of initiating system):These are generated by the receiving system, by its comparison of the sequence number sent out with the expected sequence number received with the message acknowledgement.
   • "expected sequence number is one greater than current value": The previous acknowledgment was lost. That transaction was sent again. Correct by sending next transaction.
   • "expected sequence number less than current value": Initiating system can try starting again by issuing a transaction with a sequence number of zero; or freeze the link for manual intervention.
   • "any other error": freeze the link for manual intervention.
5. Forcing re-synchronization of sequence numbers across the link:The value of -1 for a sequence number is reserved; it is allowed only when the initiating system is re-synching the link. Thus if the receiving system gets a value of -1 for the sequence number, it should return an accept acknowledgment message with a -1 for the expected sequence number. The receiving system then resets its sequence number, using the non-zero positive sequence number of the next transaction it accepts.
6. Notes:When the initiating system sends a message with a sequence number of 0 or -1 (see 2 or 5 above), the contents beyond the Message element need not be present in the message. In terms of the responding system, for these two cases, only an accept acknowledgment message is needed.

Error Handling

Error handling within HL7 messaging is confined to reporting errors in message structure, semantic content or failure on the communication link with the receiving system. Other issues such as packet framing and transport integrity are addressed at lower layers of the OSI framework and are outside the scope of this Standard.

For these other issues that are considered outside the scope of the HL7 messaging standard, Appendix C of the HL7 Standard Implementation Guide (available from the HL7 Library) provides informative guidance in the use of such protocols as the ANSI X3.28 Data Link Protocol and the HL7 Minimal Lower Layer Protocol (MLLP). Although this reference addresses the HL7 version 2 standard, it offers guidance in the configuration of lower level mechanisms for implementing messages conforming to any HL7 messaging standard. Also refer to the V3 Transport - MLLP which brings the Version 2 material into Version 3. Technology specific support for error handling will be provided by the HL7 organization through normative Implementation Technology Specifications (ITS) that will be development through a consensus of implementers committed to offering solutions using a given technology.

Security

HL7 messages may be transmitted within a framework that allows for secure communications. The framework in use for a particular implementation can be referenced in one of the messaging profile identifiers included.

While HL7 does not mandate the use of a particular framework, informative guidance and suggestions are available in two documents:

• Standard Guide for Implementing EDI (HL7) Communication Security, Version 1.1 (July 1999)
• Health Level Seven Security Services Framework, draft (July 1999)

Security mechanisms in the references above apply to securing a communication link or securely communicating composite domain content. The support of non-reputable digital signatures on the granular application level information content is planned. Currently, the coordination of this support has not been fully completed for implementation. The implementation of this capability will be dependent on an encoding technology such as XML and will be specified in an HL7 ITS with this focus.

Overview of HL7 Communication Roles for Message Control

The justification for HL7 Communication Roles for Version 3 message control comes from a need to formalize the expectations of HL7 Application Roles for messaging communication services. Application Roles specify the expected message handling behavior for a set of interactions. The HL7 Message Development Framework has led to the creation of numerous Application Roles by the technical committees that are developing HL7 Version 3 messaging interactions. Communication Roles are intended to specify a core set of messaging communication services that can support the messaging communication requirements of HL7 Application Roles. Given a generic messaging communications infrastructure, an implementer can claim support for a sub-set or all of the HL7 Communication Roles and the set of HL7 Application Roles that can be supported can be readily identified. HL7 Application Roles represent abstract specifications for implementation interfaces to healthcare applications for the purpose of conducting HL7 Version 3 message interactions. If a healthcare application system (e.g. a pharmacy order entry and dispensing application system) does not exist in the target-messaging environment, the corresponding HL7 Application Roles cannot be implemented to conduct messaging interactions even if the messaging communications infrastructure has implementations of the required HL7 Communication Roles.

The HL7 Communication Roles can be considered to exist in 1 to 1 pairs or 1 to n relationships (e.g. one Notification Message Sender may send to many Notification Message Receivers that do not implement any form of Acknowledgement).

The messaging communication services that are provided by these Communication Roles will be described in storyboard section of each topic area in this domain. Events that these Communication Roles manage are initially described in the application roles section of each topic area in this domain. They are enumerated in greater detail in the trigger event sections.

There are events that for the control of both Generic Message Transmission and Polling Message Transmission message send sequences. HL7 Communication Roles handles these latter events by providing a remote message queue polling service.

Note: The interactions in which each HL7 Communication Role participates are documented in the message control storyboards section for each topic area. Each interaction is initiated by a message control state transition that is assigned a Message Control Trigger Event. Reference the trigger events section for each topic area for detailed descriptions of the Version 3 Message Control Trigger Events.

Note: The Transmission Infrastructure domain will include storyboards, application roles, trigger events, interactions, and message types shared by any of the healthcare domains. Some of these will be for example purposes only. The examples will not be used in their own right but as a reusable Transmission Wrapper in various domains. When used in this fashion, the message is transmitted as a result of a domain interaction and between two domain application roles. In the case where the artifacts can be used in their own right, the reader will be informed of that as well.

Go To Top