The Demo site for our new HL7 Version 2+ (plus) Standard
visit the hl7 website

Draft Website - For Review Purposes Only

Table of Contents

1 INTRODUCTION

2 HYBRID LOWER LAYER PROTOCOL

2.1 Introduction

2.1.1 Goals and Assumptions

2.1.2 Notation Conventions

2.2 Blocks

''C'' - character count wrong in previous data block received

''X'' - checksum wrong in previous data block received

''B'' - data too long for input buffer in previous block received

2.3 Processing Rules

2.3.1 Optional Connection and Disconnection

2.3.2 Initiating and Responding

d)If the block is acceptable and has block type ''N'', it is a negative acknowledgement. Resend the original block as many times as is specified in the NPT or return to the application with an indication of the error.

e)If the block is acceptable and has block type ''D'' it is the response. Go to the next step.

f)If the initiating system detects an error in the data block from the responding system, it has the option of retransmitting the original data block. The decision of whether to retransmit the original block is application-specific. It depends on the type of message and the ability of the receiving system to detect duplicate messages.

2.4 Carriage Return Stuffing

2.5 Flow-Through Processing

2.5.1 Inititiating System Processing

2.5.2 Responding System Processing

2.6 Implementation, System and Site-Specific Issues

2.6.1 Connect Retries (For optional transient virtual circuits)

2.6.2 Receive Timeout Errors

2.6.3 The Network Parameter Table (NPT)

Connect Retry Count - the number of times to try to connect to a destination.

Connect Pause - the amount of time to wait between connect attempts.

Receive Timeout - the amount of time to wait for a response data block.

Send Retry Count - the number of times to resend a data block after receive errors.

2.6.4 Error Reporting and Logging

3 X3.28 BASED DATA LINK PROTOCOL

3.1 Overview

3.1.1 Introduction

American National Standards Institute

1430 Broadway

New York, NY 10018

(212) 642-4900

3.1.2 Requirements and Assumptions

3.1.3 Environment Model

Figure B-1.

3.1.4 Communication Control Characters

SOH

(Start of Heading)SOH delimits the start of a message heading. If the heading is subdivided into multiple transmission blocks, SOH delimits the start of each block that continues transmission of the heading.

STX

(Start of Text)STX precedes a sequence of characters that is to be treated as an entity and entirely transmitted through to the ultimate destination. Such a sequence is referred to as "text." If a heading precedes the text, STX delimits the end of the message heading. If the text is subdivided into transmission blocks, STX delimits the start of each block that continues transmission of the text.

ETX

(End of Text)ETX delimits the end of a message text. In multi-block messages, ETX indicates the last block of the message.

ETB

(End of Block)

ETB delimits the end of a block that is not the last block of a message.

EOT

(End of Transmission)EOT indicates the conclusion of a transmission that contained one or more message texts and any associated headings.

EOT cancels any previous master/slave assignment.

EOT must never have a prefix.

EOT is sent by a master station after the completion of the message transfer phase in order to effect a normal termination of the transmission. (End current master/slave transmission relationship.)

EOT is sent by a master station prior to the completion of the message transfer phase in order to effect a sending station abort function. (Sent between blocks of a multi-block message.)

EOT is sent by a slave station in place of ACK/NAK in order to effect a termination interrupt function. It serves to NAK the current block and causes the current master/slave relationship to be ended.

ENQ

(Enquiry)ENQ is used to request master status.

ENQ is used to solicit a response from a remote station.

ENQ may be used to obtain identification of the remote station.

ENQ is the last character of a polling or selection supervisory sequence.

ENQ is used by the master station in block abort procedures.

NAK

(Negative Acknowledgement)NAK is transmitted as a negative response to the sender.

NAK is used during the establishment phase to indicate that the station is not ready to receive.

During message transfer, NAK indicates that the last message or transmission block wasnot accepted, but the station is ready to receive.

ACKN

(Acknowledgment N)

3.1.5 Block Number

3.1.6 Text Length

3.1.7 Block Checking Characters

3.2 Establishment of Master/Slave Relationship

Figure B-2.

3.3 Message Transfer

3.3.1 Transmission Blocks

3.3.2 Replies

3.4 Aborts and Interrupts

3.5 Block Abort

Description

The sending station in the process of sending a block, but before the end of the block,decides to end the block in an unusual manner such that the receiving station will discard the block. Such a procedure is called a block abort.

Application

Block abort may be used by a sending station when, in the process of sending data, there occurs an indication that the data being sent may not be valid.

Block abort may be used in the message transfer state to cause a temporary text delay after receipt of the previous acknowledgement if the sending station is not capable of transmitting the text of the next transmission block before the predetermined time-out period. The reasons for such a delay might be the unavailability of buffer space or that the speed of the input device is considerably slower than the transmission speed and a full block has not yet been read from the media.

Procedures

Block abort is accomplished by the sending station''s ending the block (at any time) with the ENQ. The sending station then halts transmission and waits for a reply. The receiving station detects that the block was ended with ENQ rather than with a normal ending character (ETB or ETX), discards that portion of the block that had been received and sends a NAK response to the sending station and remains in the receive condition.

Following receipt of the NAK response, the sending station will normally reinitiate the transmission with the same or a new block.

In the case of a NAK response that is not received, the sending station will time out (expiration of Timer A - see section on Timers). The sending station reinitiates transmission with the same block or it may choose to initiate an appropriate termination or recovery procedure. The specific choice of operation will generally be a function of the system discipline being employed.

3.5.1 Sending Station Abort

Description

The sending station, in the process of sending several blocks per message text, decides to terminate transmission prematurely at the end of a block and after receipt of the proper acknowledgement reply. Such a procedure is called a sending station abort.

Application

Sending station abort procedures may be used by a sending station when, in the process of sending multiple blocks per message text, it determines that it should prematurely terminate transmission to the particular receiving station. Such a determination might be made if the sending process did not receive the remaining blocks in time from the higher level, needed to send a higher priority message, or was temporarily unable to continue transmission, etc.

Sending station abort procedures may be used following block abort procedures to accomplish a transmission abort condition; that is, the sending station prematurely terminates the transmission within a transmission block.

Procedures

Sending station abort procedures are accomplished by the sending station completing the transmission of a block, for example, ETB, ENQ. Then upon receipt of the proper acknowledgement reply (ACK, NAK, etc.) or a Timer-A time-out, the sending station transmits EOT to terminate the transmission to the receiving station. The receiving station detects this sending station abort procedure by recognizing receipt of EOT following ETB, or ENQ instead of ETX

3.5.2 Termination Interrupt

Description

The receiving station, after receipt of a message or transmission block, causes the sending station to cease transmission. Such a procedure is called a termination interrupt.

Application

Termination interrupt may be used by the receiving station to cause the transmission to be interrupted because it is not in a condition to receive. Cause for such inability to receive could include a hardware malfunction, loss of an additional network connection, etc.

Procedures

Termination interrupt procedures are accomplished by the receiving station''s transmitting EOT in lieu of one of its normal responses. This response indicates a negative acknowledgement of the last transmission and the conclusion of a transmission.

3.5.3 Reverse Interrupt

Description

A receiving station may request the sending station to terminate the transmission in progress prematurely in order to facilitate a reversal in the direction of data transfer. Such a procedure is called reverse interrupt.

Application

Reverse interrupt procedures may be used by a receiving station to interrupt its receiving of a message stream so that it may transmit a priority message or messages to the original sending station.

Procedures

Reverse interrup Reverce interrupt procedures may be used by a receiving station only after reception of a block with a valid BCC. Reverse interrupt procedures are accomplished by the receiving station''s transmitting a RINT sequence in lieu of the normal affirmative acknowledgement. This reply is interpreted as an affirmative reply to the last transmission, and it signals a request by the receiving station that the sending station terminate the transmission sequence in progress as soon as the sending station is in such status that it can receive a message without destroying or losing information that may have previously been stored in buffers.

The RINT sequence may not be repeated by the receiving station to successive transmission blocks without transmitting intervening affirmative acknowledgements (ACKN).

Upon receipt of RINT, the sending station should terminate the transmission by transmitting EOT after it has completed transmitting all data that would prevent it from receiving a message. The number of transmission blocks to be transmitted prior to termination is variable and dependent upon station design.

The receipt of RINT as a response to a sending station''s ENQ should be treated as a repeated (duplicate) response if the last valid response received was ACKN. The sending station should continue by transmitting the next block, or EOT. If the last valid response was RINT, the sending station must assume that the last transmitted block was garbled. The sending station should retransmit the previous block.

3.6 Block Headings and Acknowledgement Prefixes

3.6.1 Headings

3.6.2 Prefixes

3.7 Timers and Recovery Procedures

3.7.1 Timers

3.7.2 Recovery Procedures

3.7.3 Parameters and Defaults

4 MINIMAL LOWER LAYER PROTOCOL

4.1 Introduction

4.1.1 Background

4.1.2 Goals and Assumptions

4.1.3 Differences

4.1.4 Notation Conventions

4.2 Block Format

<SB>dddd<EB><CR>

<SB> =

Start Block character (1 byte)ASCII <VT>, i.e., <0x0B>. This should not be confused with the ASCII characters SOH or STX.

dddd =

Data (variable number of bytes)

This is the HL7 data content of the block. The data can contain any displayable ASCII characters and the carriage return character, <CR>.

<EB> =

End Block character (1 byte)ASCII <FS>, i.e., <0x1C>. This should not be confused with the ASCII characters ETX or EOT.

<CR> =

Carriage Return (1 byte)The ASCII carriage return character, i.e., <0x0D>.

4.3 Processing Rules

5 HL7 SEQUENCE NUMBER PROTOCOL IMPLEMENTATION

5.1 Sequence Number Usage

5.2 Sequence Number Description

5.3 State of the Receiving System

5.3.1 Sequence Number Processing by the Receiving System

Saved ESN

Expected Sequence Number State

> = 1

> = 1 (valid sequence number)

- 1

NONE

5.4 Normal Operations

5.4.1 The Message Sequence Number Sent Equals the Expected Sequence Number

5.4.2 The Message Sequence Number Sent does not Equal the Expected Sequence Number

5.4.2.0 The Message Sequence Number Sent Plus One is Equal to the Expected Sequence Number

5.4.2.1 The Message Sequence Number Sent is Greater Than the Expected Sequence Number

5.4.2.2 Other Errors

5.5 Sequence Numbering Chart

SEQUENCE NUMBER PROCESSING BY RECEIVING SYSTEM

SQ#Sequence Number

ESNExpected Sequence Number

ESN StateExpected Sequence Number State

Is this a type of message that requires SQ#s?

NO

YES

Process according to that type and ignore sequence numbers. Do not change either the ESN State or the ESN. Example: If this message is a network management message from receiving system, ignore sequence numbers altogether.

Incoming is an integer SQ# > = -1?

NO

YES

Send an MSA with an AR. Example: The right message, but the wrong sequence number format.

Continue

?

What is the ESN State (Expected Sequence Number State)?

ESN State >= 1

An Expected Sequence Number exists or is defined.

ESN State = NONE

An Expected Sequence Number does not exist or is not defined.

Incoming SQ# = -1?

Incoming SQ# = -1?

YES

NO

NO

YES

Set the following:

? ESN = -1

? ESN State = NONE

Incoming SQ# = 0?

Incoming SQ# = 0?

Set the following:

? ESN = -1

? ESN State = NONE

Send MSA with AA

YES

NO

NO

YES

Send MSA with AA

Set the following:

? ESN = Existing ESN

? ESN State = "ESN >= 1"

SQ# must be >= 1

Set the following:

ESN = Existing ESN

ESN State = "ESN

>= 1"

Incoming SQ# >= 1?

Set the following:

? ESN = -1

? ESN State = NONE

Send MSA with AA

Refer to the Message with Sequence Number Chart.

NO

YES

Send MSA with AA

error

Set the following:

? ESN = Incoming SQ#

? ESN State >= 1

This must be a full message and the assumption is that its been preceded by a SQ# control message of 0 or -1. Thus, this is a "start of sequencing, actual message, and the receiving system is synchronized to this incoming SQ# as its ESN (and ESN State is "ESN >= 1"). No further SQ# checking, but do regular application processing on this message.

Send MSA with AA or AE accordingly

This chart is a continuation from the Sequence Number Processing Chart on the previous page. It details the Sequence Number Process when there is an ESN and the ESN state = "ESN >= 1."

MESSAGE WITH SEQUENCE NUMBER

Sending system

sends a message with a sequence number (SQ#)?

Receiving System

tracks Expected Sequence Number (ESN) and ESN state

compares SQ# with ESN?

SQ# = ESN

SQ# ? ESN

Sends MSA with AA or AE acknowledgment code, and contains the SQ# = ESN.

Sends MSA with AR acknowledgment code, an error message, the Expected Sequence Number (ESN), and the message sequence number (SQ#) received.

Sending system

?

SQ# = ESN

SQ# +1 = ESN

SQ# > ESN

Other Errors

Increments SQ# by 1.

Assumes the previous acknowledgment is lost. The message sent is a duplication. Increments SQ# by 1.

1) ADT tries to recover by starting at the ESN in the MSA.

--or--

2) Freezes the link.

Freezes the link.

Processes the next message.

Processes the next message.

1) Sends messages from log beginning with ESN in MSA.

--or--

2) Waits for operator intervention.

Waits for operator intervention.

5.6 To Query for the ESN

5.7 To Synchronize the ESN

5.8 Overview of the Sequence Number Protocol

Current State of Receiving System: Expected Sequence Number = NONE

Incoming Message Seq. Num

Expected Seq. Num Field of MSA

Next State of Receiving

System

-1

-1

None

0

-1

None

>= 1

Same as incoming

Same as Incoming +1

Current State of Receiving System: Expected Sequence Number >= 1

Incoming Message Seq. Num

Expected Seq. Num Field of MSA

Next State of Receiving

System

-1

-1

None

0

Expected Seq. Num

Expected Seq. Num

>= 1

Same as incoming

Same as incoming +1

5.9 Link Management Messages

5.10 Responsibility for Initiating Synchronization

5.11 Acknowledgment Codes

6 PSEUDO CODE FOR HL7 TCP

6.1 Initiating Module

do/* call until successful or too many retries */

{ status = call(network address);

if ( status == OK )/* break out of loop if successful */

break;

retries = retries - 1;

sleep for configurable # of seconds (1 sec?) ;

} while ( retries >= 0 );

if ( status != OK )/* return if calls failed */

return(status);

while messages to send to this destination

{ status = send(next message);/* send the message */

if ( status != OK )

goto disconnect;

status = receive(reply);/* get the reply */

if ( status != OK )

goto disconnect;

application code to process reply

}

disconnect:

disconnect();/* disconnect if error or done */

return(status);

6.2 Accepting Modules

for ( ; ; )/* do forever */

{ do/* wait for listen to complete successfully */

{status = listen(port);}

while ( status != OK );

for ( ; ; )/* loop until disconnected */

{ status = receive(message);

if ( status == OK )

{ application_code(message,reply);

send(reply);

}

else if ( status == DISCONNECTED )

break;/* break out of inner loop */

else ERROR/* some other error */

}

disconnect();/* disconnect if error or done */

}

6.3 Permanent Virtual Circuits

6.4 Assumptions and Guidelines