INTRODUCTION
The HL7 protocol will be used primarily in network environments. Most of the details of error detection and correction are handled by the lower levels of any reasonable network protocol and are not appropriate for the HL7 Standard. Many mini and main-frame computer systems, however, operate in communication environments that do not provide sufficient lower layer functionality. In these cases HL7 offers several alternate lower layer protocols to suit different environments. It is not a requirement of a vendor to implement any of these protocols to be considered HL7 compliant at the encoding rule level.
a) Many environments consist of simple RS-232 circuits where flow control and error recovery issues dominate the communication design. For these environments a protocol based on the American National Standards Institute Standard X3.28 is provided. It is described in section 3 of this appendix.
b) Some LAN-based networking environments provide a reliable byte stream but insufficient session control to support HL7. Environments based on the TCP protocol of the Internet Suite are in this category. For these a very simple protocol is provided that simply delimits messages. It is described in section 4.
c) Some environments are hybrids where communications occur primarily over LANs but host connections to the LAN may be made over RS-232 ports on terminal servers. Environments such as this have some of the same problems as those operating entirely with RS-232 circuits, but the bit error rates are generally lower and flow control is available from the network. The lower layer protocol described in section B.3 of this appendix is significantly more efficient than the X3.28-based protocol for these environments.
HYBRID LOWER LAYER PROTOCOL
Introduction
Goals and Assumptions
The goal of this lower level protocol (LLP) is to provide an interface between HL7 and the network that accommodates these real-world restrictions. Since the source or destination of a message may be a terminal server, all HL7 interfaces to the network must pass through the LLP. For the sake of efficiency the protocol does not add a large amount of overhead which duplicates functions of the lower levels of the network.
It is assumed that:
1. The RS-232 interface distance between the computer and communication server is short (10'). And so will not experience a significant number of errors.
2. The computer may place line length restrictions on data coming in over the serial port.
3. The computer may not deliver serial data to the application until it has received a carriage return.
4. The computer and the communication server have adopted some common flow control protocol over the RS-232 line, such as XON-XOFF or modem control signals.
5. The application may require transient use of the LAN virtual circuit capability. In this mode a circuit will be created for each pair of messages that is exchanged and then released. This mode of operation is an option that will not always be used.
Notation Conventions
1. Single ASCII characters are enclosed in single quotes.
2. Special characters or non-printing ASCII characters are enclosed in angle brackets, <>. Special characters are the LLP Start Block and End Block characters. Non-printing ASCII characters may be written as their abbreviation, e.g., ESC for the Escape character. They also may be written as their hex value in the form 0xXX where X is a hexadecimal digit. For example in Standard ASCII,
Blocks
There are two types of blocks, data blocks and NAK blocks. HL7 messages are transmitted in single data blocks. NAK blocks are used to signal transmission errors.
Both block types have the same format:
Blocks consist of the following fields. Note that these are LLP fields and are not the same as HL7 message fields.
t = Block Type (1 byte)
'D' = data block
'N' = NAK block
vv = Protocol ID (2 bytes)
The characters '2' '1' for this version.
dddd = Data (variable number of bytes)
In a data block, this is the data content of the block. The data can contain any displayable ASCII characters and the carriage return character,
In a NAK block, this field contains a 1-byte reason code as follows:
'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
'G' - Error not covered elsewhere.
ccccc = Block Size (5 bytes)
Character count of all characters so far in the data block up to and including the last data character. For this version of the protocol this is 5 + the size of the dddd field. Note that an encoded HL7 message ends with a
xxx = Checksum (3 bytes)
Exclusive-OR checksum of all characters in the block up to and including the last data character. The checksum is expressed as a decimal number in three ASCII digits.
If the value of this field is 999, the checksum should not be computed. Processing will proceed as if it were correct. This feature is used for applications where the messages will be translated from one character set to another during transmission.
Processing Rules
Optional Connection and Disconnection
When two entities communicate in a LAN environment, they must establish a virtual circuit. The virtual circuit provides reliable, sequenced, error-free, two-directional, full-duplex data transmission over the network. The circuit is established by one of the entities performing a "call" operation and the other performing a "listen" operation. The two entities use a Network Names to identify one another. The call operation is often called an "active connection" or simply a "connection" operation. Occasionally, the listen operation may be called a "passive connection." Once the calling entity has connected to the listening entity, the circuit is established and they may exchange data. The preferred method of establishing a circuit is for the initiating system to perform the call operation and for the responding system to perform the listen operation.
When the data exchange is through, either side may perform a disconnect operation to break the circuit. Data may or may not be lost between the two systems depending on the type of disconnect performed. Some network protocols require both sides to perform a disconnect operation for the circuit to disappear completely. It is highly recommended that the system which performs the call operation be the first to perform the disconnect operation.
As stated above, some applications require that the virtual circuits be created on a transient basis. For those applications, processing rules below show steps for creating or releasing the virtual circuits. Where transient virtual circuits are used, the Network Name and certain other communications parameters are determined as discussed under Network Parameter Table (NPT) on page 8. These steps should be omitted for environments not requiring them.
Initiating and Responding
By definition, the initiating system sends the initiate message and the responding system sends back a response message. Each of these messages is formatted into a single LLP data block. In the usual case, where there are no errors, the initiating system will send a message and receive the response. The responding system will receive the initiate message and send the response.
Initiating System Processing. The following steps are performed on the initiating system, which first sends a message and then receives a response.
1. Accept initial message from encoding rule module and form into block.
2. (Optional.) Perform connection-specific initialization based on the contents of the message header and the NPT (see page 8).
3. (Optional.) Connect as required by the implementation. This may require several attempts before a circuit is made if so specified in the NPT entry.
4. Send the data block that contains the message.
5. Receive the response from the responding system. To receive the block that contains the response:
a. If a completely delimited block is not received before the receive timeout as specified in the NPT, resend the original block. If the number of timeout retries specified in the NPT has been exceeded, or return to the encoding rules module with a timeout error.
b. Ignore all incoming characters until a Start Block character is received. Any time another Start Block character is received before the end of a block, ignore all previous characters. Receive characters until
1.) Block Format,
2.) Checksum (xxx),
3.) Block Size (ccccc) or
4.) has too many characters to be received in a single block resend the original block or
return an indication of the error to the encoding rule module depending on the number of send retries and the type of error.
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.
6. (Optional.) Disconnect.
7. Return to the encoding rule module with the response message.
Responding System Processing. The responding system follows these steps.
1. (Optional.) Perform a listen function if required by the environment.
2. Receive the block that contains the initial message.
To receive a block:
a. Ignore all incoming characters until a Start Block character is received. Any time another
Start Block character is received before the end of a block, ignore all previous characters. Receive characters until
b. If a block is received that does not have the proper:
1.) Block Format,
2.) Checksum (xxx),
3.) Block Size (ccccc) or
4.) has too many characters to be received in a single block,
construct and send a NAK block (type t = 'N') that includes the appropriate reason code in the data field.
c. If the receive block is valid, go to the next step.
3. Give the initiation message to the application.
4. Application creates a response and makes a block.
5. Send the response message.
6. Disconnect if required.
Carriage Return Stuffing
The HL7 encoding rules do not place any limits on the length of a segment. Many languages or operating systems have terminal oriented input disciplines that place a limit on the number of characters that can be received before they must receive a carriage return character. To overcome this problem, Carriage Return Stuffing may be used.
If a certain number of characters have been transmitted without a carriage return, the sending system inserts a carriage return character into the output stream. The receiving system is also counting characters from the last carriage return seen. If the limit is exceeded, the receiving system knows that the next character is a stuffed carriage return and must be removed from the data. Stuffed carriage returns are not used in calculations of block length or checksum.
The line length for carriage return stuffing is configurable on a site specific basis.
As an example, consider an imaginary HL7 message with a 150 character segment and a 1000 character segment. Suppose that the maximum numbers of characters that can be received without a carriage return is 200. Then the original message will look like this:
Header
The transmitted data will look like this (stuffed
Header
The carriage returns at the end of most HL7 segments mean that most of the time, no carriage returns will need to be stuffed. Notice that at one place there are two carriage returns in a row. The first is the stuffed carriage return; the second is the carriage return that is part of the HL7 message. Even if a carriage return is stuffed where there already is a carriage return in the message, the carriage return that is part of the original message must still be transmitted.
The receiving system will receive the data and note where 200 chars in a row appear without a carriage return. It then knows that the next character is a stuffed carriage return and should be thrown out. This recreates the original block.
Flow-Through Processing
The HL7 Standard may be applied in situations where queries will be made on behalf of a user who is waiting to view the response at a terminal. In such cases, the communicating applications and implementations of the higher levels may agree to overlap transmitting the early portion of the response with the retrieving and formatting of later portions so that the user can view the initial part of the message before the entire message has been sent. This section describes an option that supports this mode of processing.
Inititiating System Processing
After sending the initial message, the initiating system awaits the response (step 5, page 5). The program must receive characters and form them into
Responding System Processing
When the encoding rules have provided the first segment of the reply, a block header (the portion from the Start Block character to the first
Implementation, System and Site-Specific Issues
This section deals with issues that do not affect the data flowing among HL7 systems. As such they are considered local matters and not subject to standardization. Nonetheless, they are important considerations in the implementation of this Lower Layer Protocol.
Connect Retries (For optional transient virtual circuits)
Although the entire problem of connecting and disconnecting to form a virtual circuit on the network is beyond the scope of this document, it should be pointed that it may require more than one call operation to complete a circuit. If the destination system is already processing a request, the called address may not be immediately available. Waiting a short time and retrying to connect may then be successful. The number of times to retry connecting will be dependent on a number of factors and should be configurable. This is covered more fully in the section Communication Parameters and the NPT.
Receive Timeout Errors
A timeout error is often a signal of a hardware problem for which retrying will not help. It may take a few seconds to tens of seconds for these errors to be returned to the program, so blindly retrying on timeout error may make an interactive system appear to lock up. Some implementations may wish not wish to retry an operation after a timeout error.
The Network Parameter Table (NPT)
Communication over the network requires establishing some parameters. The parameters for any given circuit depend on the organization of the network at the site, the type of computers running and the type of message being sent. Some common parameters are:
Network Name - the network name to call based on the destination information in the MSH segment.
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.
The values of these parameters need to be specific to a site and to message type. They should be easily configurable to allow tuning once the network has started functioning. One easy way to do this is by using a Network Parameter Table or NPT.
The NPT is a simple text table that is read in by the application. The table contains values for each of these parameters indexed by message type, receiving facility, receiving application and processing ID. In the communication step which calls for connection-specific initialization, these values are looked up in the NPT and then control the rest of the communication attempt.
The use of an NPT is recommended, but it is not a requirement for HL7.
Error Reporting and Logging
An important feature of any software package that does data interchange is its ability to log and report errors to the operator and other system administrators. These are, however, local matters since they do not affect the data formats or processing rule. They are not specified by this Standard.
X3.28 BASED DATA LINK PROTOCOL
Overview
Introduction
The communications protocol described in this section may be used to transfer HL7 messages between systems. Much of the language contained in this protocol specification is based on or reproduced from the ANSI X3.28-1976 Standards document. These portions are reproduced with permission from American National Standard X3.28, copyright 1976 by the American National Standards Institute. Copies of the complete X3.28 Standard may be purchased from:
American National Standards Institute
1430 Broadway
New York, NY 10018
(212) 642-4900
X3.28 has a collection of options to support various communications requirements. This section is mainly comprised of a selection of these options appropriate for HL7 use. Specific local implementations may require functionality that is not provided by the protocol described in this document. It is strongly recommended that any additional functionality be implemented using options from the ANSI X3.28 Standard.
Decisions to use specific X3.28 options came from the items listed in section 1.2 "Requirements and Assumptions."
The following X3.28 options are used. (Parenthesized paragraph numbers are citations to the ANSI document.)
- Establishment and Termination Subcategory 2.3: Two Way Alternating, Nonswitched Point-to-Point.
- Message Transfer Subcategory B2: Message-Associated Blocking with Alternating Acknowledgements. (ACKN is used with link block numbers as a substitution for alternating ACK0, ACK1.)
- Link Block Numbers (3.7)
- Prefixes. (3.3)
- Block abort. (3.4.1)
- Sending station abort. (3.4.2)
- Termination Interrupt. (3.4.3)
- Reverse interrupt. (3.4.4)
- Optional transparent heading and text. (Transparent block sequences are always used, but escaping of DLEs in data is left to local implementation agreement.)
Other features not covered in the X3.28 Standard, but used in this protocol:
- The BCC is converted to an ASCII hexadecimal representation.
- A single termination character follows each block and control sequence.
- A message length has been added to the block trailer to help verify block integrity.
- A line check (timer E) provides early warning of communications link problems.
This protocol does not prescribe the means for establishing a channel (signaling path) between two or more stations nor does it provide a session interface. It does prescribe control procedures used to send and receive data once a channel has been established.
Requirements and Assumptions
1. The protocol must support point-to-point connection with guaranteed delivery. (It does not require that the message be processed before it is acknowledged.)
2. Simplicity of implementation has priority over throughput.
3. The protocol software need not accept another transmission request from a higher level while it is completing a previous transmission request.
4. Only one physical line is required to accommodate the request and (application level) reply for a given remote operation.
5. The data link protocol must allow different types of remote operations to be sent over a single physical line. (Data link acknowledgement of a message must not wait for the application level reply. This would hang the link and prevent all types of messages from being delivered.) ACKs must be sent independent of application replies.
6. Data transmission may be initiated by either side (although not simultaneously).
7. One side may use a driver that recognizes only a single termination character.
8. A system may lack flow control (XON, XOFF) capabilities.
9. Blocking must be done to accommodate limitations of some systems.
10. Block transmissions must be synchronous and duplicates recognized.
11. The receiver must be able to interrupt the sender to reverse the direction of data flow when needed.
12. Error recovery should be simple. (few states)
13. The checksum algorithm must not produce arbitrary byte values. Displayable ASCII characters must be sent.
14. Support of data transparency should be an optional, but fairly trivial addition to the protocol.
15. Either side can detect when the communication link becomes inoperative (within 5-10 minutes).
16. Block size (and perhaps other parameters) can be negotiated or predetermined.
Environment Model
The following model and guidelines are used with this protocol to support the stated requirements and assumptions.
The job of the communication modules that implement this protocol is to take a message from a single source and deliver it intact to a single destination. (See Figure B-1.) The message source and destination may vary with implementation, but will frequently be a queue or spooler.
Figure B-1.
The communications protocol is a delivery mechanism only. To the communications module, an HL7 reply is just another message text. It does not know the data content of the messages it transfers. The following functions are performed at a higher level and should not be confused with the communications protocol described here:
- Queuing and prioritization of messages to be sent.
- Distributing messages received to the correct server application.
- Asynchronous storage and processing of messages.
- Relating application replies to requests.
- Guaranteed completion of remote operations.
A single communications module and physical line may support multiple applications. (Although throughput, message priorities, or fault tolerance may dictate a multi-line design.)
Communication Control Characters
The following table defines the communication control sequences. A brief description of each sequence follows the table. References to these control sequences is used in describing the protocol throughout this document.
Note that the Termination Character must be appended to the transmission sequences: EOT, ENQ, NAK, and ACKN. A Termination Character is also appended to transmission blocks after the checksum.
Control Sequences
Abbreviation Characters Actual Bytes (hex)
TERM CR 0D
SOH SOH 01
STX STX 02
ETB ETB 17
ETX ETX 03
EOT EOT 04
ENQ ENQ 05
RINT DLE < 10 3C
NAK NAK 15
ACK0 DLE 0 10 30
ACK1 DLE 1 10 31
ACK2 DLE 2 10 32
ACK3 DLE 3 10 33
ACK4 DLE 4 10 34
ACK5 DLE 5 10 35
ACK6 DLE 6 10 36
ACK7 DLE 7 10 37
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 was
not accepted, but the station is ready to receive.
ACKN (Acknowledgment N)
ACK0 is transmitted during the establishment phase as a response indicating a readiness to receive (become slave).
ACKN is transmitted by a slave station as a numbered affirmative reply to a transmission block. ACK1 is sent as a reply to the first block after the establishment phase. ACK2 is replied to the next block. Sequencing continues through ACK7 and then wraps to ACK0.
Block Number
A block number (BLK) is used to sequence message blocks. It immediately follows the first start-of-block delimiter (SOH or STX). The BLK character is a single ASCII numeric character that varies from zero through seven. The first transmission block, after establishment of master/slave is assigned the numeric character one (hex 31). Subsequent transmission blocks will use sequential numbers (2, 3, 4, 5, 6, 7, 0, 1, 2, etc.).
The BLK character is added by the transmitting station and is functionally deleted by the receiving station. It is not considered as part of the end-to-end heading or text. The BCC must be correct before BLK is used to determine proper block sequencing.
BLK is reset to "one" upon a timer-D timeout or upon transmission or reception of EOT.
Text Length
The Text Length (TL) is the number of bytes of message text that are present in the block. It immediately follows BLK and is a decimal number in ASCII characters. It is always 5 characters long, right justified, zero filled. (See the example message below.)
Block Checking Characters
Two block check characters (BCC) are added at the end of each transmission block to facilitate error detection. The BCC is generated as follows:
1. Take the Exclusive-Or of all of the characters in the block, starting with the character following the first SOH or STX in the message, and ending with the character just prior to the BCC characters. (If SOH is present, start with the character following SOH and include the STX.)
2. Convert the resulting binary value to a two character hexadecimal ASCII representation.
For example, to send the message text "HL7 is great!" as the first block after establishment of master/slave, the general message format of:
STX BLK TL Text of Message ETX BCC TERM
would be encoded as the hexadecimal byte values:
STX 01
BLK 1 31 ("1") (BCC starts with this byte)
0 30
0 30
0 30
1 31
3 33
H 48
L 4C
7 37
i 69
s 73
g 67
r 72
e 65
a 61
t 74
! 21
ETX 03 (BCC ends, including this byte)
6 36
D 44
CR 0D
The result of the exclusive-or of the checksummed bytes:
31 30 30 30 31 33 48 4C 37 20 69 73 20 67 72 65 61 74 21 03
= 6D. The ASCII characters "6D" are used as the BCC above.
Establishment of Master/Slave Relationship
(In this section, the numbers in parenthesis refer to Figure B-2.)
Prior to the establishment of transmission (1), neither station has master status (is the sender). Either station may request control of the line to become the master (sender) (2).
When a station desires to transmit a message, the station requests to be the master by sending an ENQ supervisory sequence to the remote station (2). It is possible for both stations to bid for master status simultaneously. (Indicated by receipt of an ENQ after sending an ENQ.) In this case, priority is given to the station that is designated by local agreement as the primary for contention purposes.
- The secondary station grants the line to the primary station by sending an ACK0.
- The primary station waits for receipt of ACK0. If ACK0 is received prior to expiration of Timer A, the primary has been granted master status and begins transmitting data. If Timer A expires, the primary station again requests master status by transmitting an ENQ sequence.
A station that has not sent ENQ, but has received ENQ, takes the following action:
1. Inhibits the sending of ENQ to bid for master status.
2. If ready to receive, assumes slave status and sends an optional prefix (See section on "Prefixes") followed by ACK0 (3).
3. If not ready to receive, sends an optional prefix followed by NAK (4).
Upon receipt of an affirmative reply, the bidding station assumes master status and proceeds with message transfer (12).
Upon receipt of NAK, the bidding station reinitiates a bid for master status (2). The station reinitiates its bid M times (5) and then exits to a recovery procedure (6).
Figure B-2.
In the case of an invalid or no reply to ENQ (7), the bidding station reinitiates its bid for master status (2). The station reinitiates its bid N times (8). After N unsuccessful bids, the station exits to a recovery procedure (9).
An exit to the recovery procedure (10) indicates that the remote station is not operational (busy or down). The recovery procedure may consist of a delay after which line bidding is resumed (2). Or, recovery may involve passing an error indication to a higher level to abort a connection. (As in the case of a dial-in link.)
The master station transmits EOT (11) to indicate it has no more data to transmit. EOT negates the master/slave relationship and returns the station to contention mode (1).
Message Transfer
Messages may be subdivided into blocks. A transmission block may be a complete message or a portion of a message. The master station sends each transmission block to the slave station and waits for a reply.
If the reply indicates that the block was accepted, the master station may send another block, or it may terminate. If the reply is negative, the master station immediately retransmits the block that was not accepted.
The numbers in parenthesis in the following discussion refer to Figure B-3.
Transmission Blocks
The transmission of blocks is initiated by the master after a master-slave relationship has been established. If the message has a heading (See section on "Headings"), the master station begins the transmission with SOH (2). If the message has no heading (3), the master station begins the transmission with STX (4). An intermediate block that continues a heading (7, 2) is started with SOH. An intermediate block that either begins or continues a text (7, 3, 4) is started with STX. If the last information character of a heading ends on a block boundary (ended by ETB), the subsequent block may be started by either SOH or STX.
Note that in such a case the receiver must be able to handle both situations.
Figure B-3.
A block that ends at an intermediate point within the message is ended with ETB (5). A block that ends at the end of a message is ended with ETX (6). The ETB or ETX character is immediately followed by the two block check characters (BCC). After the ETB or ETX and BCC are sent, the master station waits for a reply.
Replies
The slave station, upon detecting the ETB or ETX followed by the BCC, determines whether it will send ACKN or NAK.
The receiver verifies that a block was received correctly by checking that:
1. The message terminated with TERM.
2. The calculated BCC matches the BCC in the message.
3. The number of bytes in the message text matches the Text Length in the message.
4. The message text is followed by either an ETB or ETX.
The receiver checks the block sequence number (BLK) to detect duplicate or missing blocks. BLK of 1 is expected in the first block received after establishment of master/slave. BLK of 2 is expected in the second block received. Subsequent BLK numbers sequence up to and including 7 after which they wrap to 0 and sequence upward as before. This sequencing continues for the remainder of the master/slave relationship.
1. ACKN.
a. If the transmission block was accepted and the slave station is ready to receive another block,
it sends the appropriate ACKN (8), where N is the frame number of the block being acknowledged. Upon detecting the appropriate ACKN, the master station may either transmit the next block (7), or initiate termination (9) if the last block ended in ETX BCC (6).
b. If the received BLK character is lower than expected, a duplicate block has been received.
The receiver discards the block and sends the optional prefix followed by ACKN when ready to receive another block.
2. NAK.
a. If the transmission block was not accepted and the slave station is ready to receive another
block, it sends a NAK. (10). Upon detecting a NAK, the master station initiates retransmission of the last transmission block (11, 7). L retransmissions may be made, after which the master station exits (12) to a recovery procedure.
b. If the received BLK character is higher than expected, the receiving station discards the
received transmission block and sends an optional prefix followed by NAK when ready to receive another block.
The use of NAK does not alter the sequence of acknowledgements. The same affirmative reply (ACK0 through ACK7) is used for a successful retransmission as would have been used if the previous transmission of the unaccepted block had been successful.
If the numbered reply indicates that the slave station missed the outstanding block (receipt of ACKn-1 instead of ACKn), the master station initiates retransmission of that block as if the slave station had returned a NAK.
A message frame is acknowledged as soon as the receiving buffer is available to receive the next frame. Flow control (XON, XOFF) is not needed since a synchronous block acknowledgement scheme is used and a receiver's buffer is guaranteed to hold a block of maximum block size. (Buffer overruns do not cause loss of data.)
Aborts and Interrupts
At times during data interchange, the sending station may need to end a transmission block in an unusual manner such that the receiving station disregards that portion of the block or transmission that has been received. This procedure is called an abort.
At other times during data interchange, a receiving station may wish to cause the sending station to stop sending, either temporarily (to permit the receiving station to send) or permanently. This procedure is called an interrupt.
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.
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.
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.
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 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.
Block Headings and Acknowledgement Prefixes
Headings
An optional heading may be sent as part of a transmission block. It is a sequence of (non-communication control) characters that constitutes a machine-sensible address or routing information. A STX terminates a heading.
Prefixes
An optional prefix may precede acknowledgements. It may consist of up to 15 characters, other than communication control characters, in order to convey additional information (for example, identity or status). Note that EOT must never have a prefix. Stations must accept prefix characters without confusion. Interpretation of the prefix, however, must be by prior agreement between the implementors. A prefix must not change the meaning of the associated control character.
Timers and Recovery Procedures
Timers
Timers are primarily used to indicate when recognition of specific control characters does not occur within specified periods. It is to be noted that the timers specified in this section are functional only and do not necessarily imply a specific implementation. The action taken following a timeout is specified, but may vary for specific implementation requirements.
Logging and/or operator notification of timeouts should be done to aid in the maintenance and troubleshooting of interfaces.
Timer A (Response Timer)
Timer A is used by a sending station to protect against an invalid response or no response. Timer A is started after the transmission of the last character of a block or after sending ENQ. Timer A is stopped upon receipt of a valid reply (ACKN, NAK, or EOT).
The value for Timer A includes the response time of the receiver plus the time to transmit the acknowledgement sequence. It should be slightly longer than Timer B.
When timeout occurs while sending a block, the sending station either:
a. retransmits the block (up to N times) or
b. follows the Sending Station Abort procedures by transmitting EOT.
When timeout occurs while bidding for master status, ENQ will again be sent to request the line.
Timer B (Receive Timer)
Timer B is used by a slave station to protect against failure to recognize the end of a block (ETB or ETX). Timer B is started upon receipt of start-of-block or start-of-text (SOH or STX). Timer B is stopped upon receipt of a valid terminating character or sequence, for example, ETB, or ETX.
Since Timer B is the time to transmit a complete block, its value is a function of the baud rate, maximum message size, and any intrablock delays by the sender (if a message block is sent in pieces).
When timeout occurs:
1. Prepare to receive another transmission.
2. Discard incomplete block.
Timer D (Inter-block Timer)
Timer D serves to prevent a station from hanging in slave mode. Timer D is started when entering slave mode and restarted after replying to each block. Timer D is stopped upon receipt or transmission of EOT.
When timeout occurs:
1. Return to control mode.
Timer E (Line Check Timer)
Timer E triggers a check of the communications link when neither station has requested to be master for some time. Timer E is reset whenever a transmission is sent or received.
When timeout occurs:
1. The station triggers a bid for the line. (The line may be released as soon as master/slave is established.)
If no response is received when bidding for the line, the normal mechanism using Timer A will report problems with the communications link.
Recovery Procedures
Recovery procedures are system guidelines that should be used by all stations, as applicable. However, it is recognized that the detailed method of station mechanization, absolute value of timers, etc., may vary with applications and communication facilities. Recovery procedures should be implemented that eliminate operator intervention wherever possible.
When a timeout, invalid, or NAK response to a transmitted block is received, the master transmits the block again. This may occur up to L times. The recovery procedure after L unsuccessful retransmissions:
1. Notify the operator or the processor program, or both.
2. Transmit EOT to end the master/slave relationship.
When a timeout, invalid, or NAK response to a line bid (ENQ) is received, the sender transmits ENQ again. This may occur up to L times. The recovery procedure after M unsuccessful retransmissions:
1. Notify the operator or the processor program, or both.
2. The sender may continue to request the line by sending ENQ with an appropriate delay between requests.
Parameters and Defaults
The following parameters should be defined when implementing this protocol. Many are subject to local agreement. Some defaults are given in parenthesis, but are not mandatory.
Buffer Sizes
- Maximum Message Size
- Maximum Block Size
Timer Values
- Timer A 6 seconds
- Timer B 3 seconds
- Timer D 30 seconds
- Timer E 3 minutes
Contention
- Station designated as Primary
- Contention Retry Delay--Primary Station 1 second
- Contention Retry Delay--Secondary Station 3 seconds
Retry Counts
- L (block transmission) 5 times
- M (line bid) 10 times
- Delay between requests after M retries 30 seconds
Physical Layer Parameters for RS-232
- Baud rate Easily switched between 1200, 2400, 4800, 9600 bps.
- Start Bits (1)
- Stop Bits (1)
- Data Bits (8) Standard Extended ASCII.
(ANSI X3.41 1974 code extension techniques)
- Parity (Odd)
MINIMAL LOWER LAYER PROTOCOL
Introduction
This document describes a minimal HL7 lower level protocol to be used in a pure network environment. It is an adaptation of the hybrid lower layer protocol.
Background
It is assumed that this HL7 protocol will be used only in a network environment. Most of the details of error detection and correction are handled by the lower levels of any reasonable network protocol and do not require any supplementation.
Goals and Assumptions
The goal of this lower level protocol (LLP) is to provide an interface between HL7 and the network that uses minimal overhead while remaining compatible with other lower level protocols. By remaining compatible with other LLP's, vendors will need to make minimal changes to existing code to use this LLP.
It is assumed that there are only direct connections to the network. Any other types of links, such as RS-232 to a communication server, will require another protocol to guarantee their integrity.
Differences
This version of the LLP differs significantly from other LLP's in that it has only a single byte to signal the start of a message and two bytes to signal the end of a message. There is no other lower level header or trailer information. There are no other characters added to the HL7 message.
Notation Conventions
1. Single ASCII characters are enclosed in single quotes.
2. Special characters or non-printing ASCII characters are enclosed in angle brackets, <>. Special characters are the LLP Start Block and End Block characters. Non-printing ASCII characters may be written as their abbreviation, e.g., ESC for the Escape character. They also may be written as their hex value in the form 0xXX where X is a hexadecimal digit. For example in Standard ASCII,
Block Format
HL7 messages are enclosed by special characters to form a block. The format is as follows:
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,
Processing Rules
The rules governing circuit control and processing of messages for these blocks are the same as for Hybrid HL7 LLP blocks with the following exceptions.
1. Since there are no NAK blocks, there is no way to signal transmission errors except with higher level messages.
2. Carriage Return stuffing is not used.
Flow through processing is an allowable option.
HL7 SEQUENCE NUMBER PROTOCOL IMPLEMENTATION
In this discussion of HL7 Sequence Number protocol, there is an initiating application (sending system), and an accepting application (receiving system). It should be noted that not all messages require sequence numbers, i.e., queries, network messages, etc. When a message does require sequence numbers, the following implementation notes will apply.
Sequence Number Usage
Both parties will follow the HL7 Specification with the following clarifications. These clarifications will apply to each of the links over which the HL7 sequence number will be used.
Note: If the Sequence Number protocol is not used on the above links, the proper receipt of the messages transmitted over these links cannot be guaranteed.
Sequence numbering will not be used on display queries or network management messages.
Sequence Number Description
A sequence number is one of the following: a positive integer (from 1 to two billion), 0, or -1. No other numbers are valid.
( 1 is the smallest sequence number which can be used for normal message transactions.
( The value 0 (zero) is reserved for querying for an Expected Sequence Number.
( The value -1 is reserved for synchronizing the sequence numbers on a link.
State of the Receiving System
The receiving system will be in one of two states, depending on its Expected Sequence Number. Either the receiving system has an Expected Sequence Number or it does not. In the middle of a synchronization sequence (see 7), the receiving system does not have an Expected Sequence Number. At startup, the receiving system may or may not have an Expected Sequence Number.
Sequence Number Processing by the Receiving System
The receiving system is expected to keep track of both its Expected Sequence Number and Expected Sequence Number state in a secure manner. This is so that in the event of either side of a link going down, a link may be restarted without loss or duplication of transactions.
By saving a -1 when the Expected Sequence Number state is NONE, the receiving system can track both pieces of information with a single operation.
The receiving system sends, to the sending system, an ACK with an AA or AE acknowledgment code and the current Expected Sequence Number (MSA;4). It then increments its internal Expected Sequence Number by one and continues to process the message.
The Message Sequence Number Sent does not Equal the Expected Sequence Number
The receiving system returns an ACK with AR (Application Reject) acknowledgment code, an error message, the Expected Sequence Number (MSA;4), and message sequence number (MSH;13).
The sending system receives the reply message and checks the acknowledgment code. In the event of an Application Reject (AR), the sending system checks the Expected Sequence Number field.
The Message Sequence Number Sent Plus One is Equal to the Expected Sequence Number
It is assumed the previous acknowledgment was lost and the initial message was a duplicate. The sending system sends the next message.
The Message Sequence Number Sent is Greater Than the Expected Sequence Number
The sending system can try to recover by starting again at the lower sequence number or it can freeze the link for operator intervention.
Other Errors
The sending system freezes the link for operator intervention.
Sequence Numbering Chart
SEQUENCE NUMBER PROCESSING BY RECEIVING SYSTEM
SQ# Sequence Number
ESN Expected Sequence Number
ESN = -1
ESN State = NONE Incoming SQ# = 0?Incoming SQ# = 0?Set the following:
ESN = -1
ESN State = NONESend MSA with AA YES NO NO YESSend MSA with AASet 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 = Incoming SQ#
ESN State >= 1
MESSAGE WITH SEQUENCE NUMBERSending systemsends a message with a sequence number (SQ#) Receiving System
SQ# = ESNSQ# +1 = ESNSQ# > ESNOther ErrorsIncrements 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--
The reserved sequence number 0 is used to query the receiving system for its Expected Sequence Number (ESN). The sending system starts a query transaction by sending a message with a 0 (zero) in the Sequence Number field of the MSH segment (MSH;13).
The receiving system replies with a message which has its Expected Sequence Number (an integer greater than zero) in the Expected Sequence Number field of the MSA segment (MSA;4). If the receiving system does not have an Expected Sequence Number, it should return a -1 in the Expected Sequence Number field of the MSA segment (MSA;4).
In the event the receiving system returns a -1 in the Expected Sequence Number field of the MSA segment (MSA;4), the sending system determines the Expected Sequence Number for the link.
To Synchronize the ESN
The reserved sequence number -1 is used to synchronize the Expected Sequence Number of the receiving system.
The sending system starts a synchronization transaction by sending a message with a -1 in the sequence number field of the MSH segment (MSH;13).
The receiving system replies with a message which has -1 in the Expected Sequence Number field of the MSA segment (MSA;4). At this point, the receiving system does not have an Expected Sequence Number. The next message received which has a positive (non-zero) sequence number determines the Expected Sequence Number of the receiving system. The receiving system sets its Expected Sequence Number to the sequence number of the incoming message.
Note: If the receiving system is queried (message sequence number equals zero) after the synchronization message, but before receiving a positive non-zero sequence number, it should reply with a -1 in the Expected Sequence Number field of the MSA segment.
Overview of the Sequence Number Protocol
The following two tables provide an overview of the sequence number protocol. The first shows the state of the receiving system without an existing Expected Sequence Number, such as can occur during startup or synchronization. The second shows the state of the receiving system when an Expected Sequence Number exists.
Current State of Receiving System: Expected Sequence Number = NONEIncoming Message Seq. NumExpected Seq. Num Field of MSANext State of Receiving
The messages used to query and synchronize the link do not need to be complete messages of any particular type. The message can consist of just a valid MSH segment (with appropriate headers and trailers). Similarly, the reply message can be an acknowledgment message consisting of just the MSH and MSA segments (with appropriate headers and trailers).
Responsibility for Initiating Synchronization
The receiving system never initiates the synchronization of a link.
Note: Sequence numbers will range from 1 to two billion.
Acknowledgment Codes
The following are the acknowledgment codes for Initiating Application - Accepting Application messages using sequence number protocol.
AA - As described in the HL7 Specification.
AR - In addition to the uses described in the HL7 Specification, this code is used to signify sequence number errors.
AE - As described in the HL7 Specification, this code is used to signify that the message passed all checks which would cause an AR code, but could not be processed for some other reason.
Note: In the case of an AE or an AR, the sending system will determine the appropriate action..
PSEUDO CODE FOR HL7 TCP
The following is pseudo-code for circuit control and message passing by initiating and accepting software modules. Two types of virtual circuits are used to exchange data: transient and permanent. In the case of a transient virtual circuit, an initiating module calls an accepting module, the modules then perform one or more message transactions and the modules disconnect. In the case of a permanent virtual circuit, the initiating module has the responsibility of always maintaining a virtual circuit with another location, whether or not it currently has messages to send or not. This record-oriented results links between the initiating and accepting modules will be permanent virtual circuits.
Initiating Module
The initiating module needs at least the following information to manage a series of message transactions:
network address
number of connection retries
pause time between connect attempts
receive timeout
send timeout send retries (if NAK is received)
For best performance, these parameters may vary according to message type and receiving application. The information can be kept in text form in a Network Parameter Table (NPT) which is read by an application at run time. The NPT is keyed by the message type and receiving application. By reading this information at run time, the system can be tuned or reconfigured without coding changes.
The following pseudo-code shows the procedure that the initiating task uses to perform message transactions over a transient virtual circuit. The task calls a destination until successful or until a maximum number of attempts is reached. If the call is successful, it performs the message transactions and disconnects. If there is a send or receive error, it disconnects. Connect errors and send or receive errors must be passed back to the application in a suitable form. In particular, receive time-outs should be detected and reported.
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);
Accepting Modules
The following pseudo-code shows the procedure that the accepting task uses. The task first puts up a listen. When the listen completes successfully, it receives the initiating message. The message is passed to the application which generates a reply message. The reply message is then sent back. The accepting task receives messages until it is disconnected.
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 */
}
Permanent Virtual Circuits
A permanent virtual circuit is a virtual circuit which remains established even when there are no pending message transactions. It is the responsibility of the module which performs the network call operation to maintain the circuit. This module must be prepared to re-establish the circuit in the event it is disconnected, either accidentally or because of errors. The use of permanent virtual circuits must be agreed upon in order to avoid situations in which one module permanently ties up another module which is meant to be used on a transient basis.
Assumptions and Guidelines
The following assumptions and guidelines should be noted.
1. It is assumed that the initiating module performs the call operation. This implies that it is the initiating module's responsibility to maintain a permanent virtual circuit.
2. Network address may mean a combination of IP address and TCP port address or just a TCP port address as appropriate.
3. Error handling varies from application to application. The only requirement from a network standpoint is that circuits not be left dangling.
4. Care should be taken that a single initiating module does not monopolize an accept module over a transient virtual circuit. This may cause problems for other parts of the system trying to use the services of the accept module. This problem may occur if the initiate module has a number of messages which take the accept module a long time to process or the initiate module takes a long time to process reply messages and the initiate module does not disconnect between messages.
5. It is assumed that an initiating module may connect and perform more than one message transaction before disconnecting, but it may not have more than one outstanding message waiting for a response. In other words, the initiating task must wait for the response to a given message before sending another message.
6. The pseudo-code here is given in a C-like language. Further clarification of the pseudo-code can be given if requested.
Appendix C: Lower Layer Protocols
Appendix C: Lower Layer Protocols
Page C- PAGE 8 Health Level Seven Implementation Support Guide
Working Draft #1 - 9/95 for HL7 Standard Version 2.2 ( 1995. All rights reserved.
Health Level Seven Implementation Support Guide Page C- PAGE 7
for HL7 Standard Version 2.2 ( 1995. All rights reserved. Working Draft #1 - 9/95
Health Level Seven Implementation Support Guide Page C- PAGE 1
for HL7 Standard Version 2.2 ( 1995. All rights reserved. Working Draft #1 - 9/95
&
&
&
&
&
&
&
&
2
&
$ a
&
$ Q
&
&
&
&
&
&
2
&
&
$ l` I
&
$ UP2x
&
&
&
&
f
&
&
% b
&
&
&
&
&
&
&
p
&
&
&
&
&
>
&
&
&
&
&
&
&
&
&
&
&
&
&
S
&
% "
&
% 55
&
&
&
2
&
&
&
&
&
&
2
&
2
&
&
&
&
&
l
&
&
&
% h
&
&
&
&
&
&
&
&
&
2
&
Y
2
&
&
&
&
&
&
g
&
&
&
&
&
&
%
&
% h h `
&
2
&
2
&
2
&
&
&
&
&
&
&
&
J P U P P U
-
.
D
E
h
F /F 0F 2G 3G G G G G ,H -H vH wH H H I I CK DK K K K K L L L L L L M
% &
J K L M N O P Q
'
" ! !$MARK++$ ! ! ! ! !
! ! !
c
h
q r ! ! R! S! ! ! p" q" " " # $ $ )% +% f% g% |% % % & & & h' i' ' ' !) ") @) A) ) ) ) ) * * T* U* j* k* * |+ }+ + + + + $MARK++$, C, D, , , , , !- "- Y- Z- y- z- - - - - / / 0 0 81 91 <2 =2 J2 \2 s2 2 2 2 2 2 2 3 3 +3 ;3 K3 [3 k3 r3 3 3 c5 d5 U6 V6 n6 o6 |8 }8 8 8 ; ; ; ; = = = = > > 0? 1? A A A A C
C /C 0C 2D 3D D D D D ,E -E vE wE E E F F CH DH H H H H I I I I I I J
J K K K L L )L *L M M ?N @N N N O O O O O O O P P P =P >P aP bP P P $Q %Q sQ tQ Q Q $MARK++$R R \R ]R R R S S S S zT {T T T PU QU U U 'W (W ~W W W W X X ZX [X X X Y Y EY FY Y Y Z !Z Z Z Z Z Z Z b[ c[ ~\ \ \ ] ] ^ ^ Z^ [^ ^ ^ ^ ^ ^ ^ _ _ _ _ ` ` na oa a a a a a a a a a
b b +b ?b Sb gb {b b b b b b b c c c :e ;e Me e e e f f 8f f f f f g g cg g g 2h h h h di ei si ti i i i i !j "j pj qj j j j
k k jk sk tk k $MARK++$l l l l l l m m m m Yo Zo [p p p p p p q q q q wr xr s s s s t t t t t t t "u ,u 6u @u Ju Tu ^u hu ru {u u u u u u u u u u u v v v v Zv v v v v w w Iw Jw x x y y y y {
Q m _ t L M c k l D E G q r T ` k 5 A h ? @ _ ` # $ < { | S \ u 3 j
A B
Mary Kratz'C:\HDTEMP\HL7\HL7_IMPL\HL7_22\APP_T.DOC
Mary Kratz)C:\HDTEMP\HL7\HL7_IMPL\HL7_22\HL7APPC.DOC
Mary Kratz7M:\PDS\DATA\HL7\HL7_IMPL\IMPL_V2.2\HL7_FINL\HL7APPC.DOC
Mary Kratz7M:\PDS\DATA\HL7\HL7_IMPL\IMPL_V2.2\HL7_FINL\HL7APPC.DOCWilliam Alan Hubbard.K:\HL7\HL7_IMPL\IMPL_V2.2\HL7_FINL\HL7APPC.DOCDepartment of Pathology7M:\PDS\DATA\HL7\HL7_IMPL\IMPL_V2.2\HL7_FINL\HL7APPC.DOC@HP LaserJet 4Si/4SiMX PS 600dpi LPT2: adobeps HP LaserJet 4Si/4SiMX PS 600dpi
od X$MARK++$ X HP LaserJet 4Si/4SiMX PS 600dpi
Appendix C
Normal Operations
In normal operation of a link, the sending system sends a message with a sequence number. The receiving system checks the sequence number of the message against its Expected Sequence Number. The two possible conditions are listed as follows.
The Message Sequence Number Sent Equals the Expected Sequence Number
Saved ESNExpected Sequence Number State> = 1> = 1 (valid sequence number)- 1 NONE
To Query for the ESN
2) Waits for operator intervention. Waits for operator intervention.
Current State of Receiving System: Expected Sequence Number >= 1Incoming Message Seq. NumExpected Seq. Num Field of MSANext State of Receiving
System-1-1None0-1None>= 1Same as incoming Same as Incoming +1
Link Management Messages
System-1-1None0Expected Seq. NumExpected Seq. Num>= 1Same as incoming Same as incoming +1