HL7 Operation Forms

HL7 message exchange behaviour is governed by two forms of operation
· State Exchange Form(SEF)
· Remote Invocation Form(RIF)

State Exchange Form (SEF) is used to synchronise business processes running in separate systems usually across organisations. That is a business process engine in one organisation aligns the state of its process with a business process engine in another. SEF is usually performed through HL7 messages using reliable asynchronous ebXML pattern. Examples where SEF is used is in case of updates to patient demographics or creation of a new patient in a local system. The changes are initially done in the local application and then the external systems are notified of the changes through update or create messages. The external systems then use the data in these messages and update the data to keep in sync with the sending system.

Remote Invocation Form (RIF) is derived from standard client-server methods. The model is inherently synchronous from the perspective of the human actor in that the actor is “blocked” waiting for a response. RIF is usually performed through HL7 messages using synchronous Web service pattern or unreliable asynchronous ebXML pattern. Examples where RIF is used is in case of queries and retrievals of data from other systems. The sender system sends a query to the receiving system which maintains the MPI for the organisation and uses that data for further processing.

HL7/ebXML Slow Retry

ebXML Retries


According to ebXML Message Service Specification Version 2.0 a MSH (Message Service Handler) will perform multiple retries to send a message if it(sender) does not receive an Acknowledgement from the receiving MSH. The number of retries is one of parameters used by the sending MSH to confirm that a message is sent reliably.

According to ebMS2.0

Ø The Retries parameter is an integer value specifying the maximum number of times a Sending MSH SHOULD attempt to redeliver an unacknowledged message using the same Communications protocol

Ø If the Sending MSH does not receive an Acknowledgment Message after the maximum number of retries, the Sending MSH shall notify the application and/or system administrator function of the failure to receive an Acknowledgment Message.

From the second bullet point it is clear about what ebMS2.0 suggests us to do.

According to the classic Enterprise Integration Patterns "messaging" ensures that message will be guaranteely delivered but does not guarantee when it will be delivered. If the infrastructure supporting the conversation between sender and receiver is down for considerable time the sender will ensure that the receiver gets the message when the infrastructure is back. However when the message is delivered the context of the message may not be valid anymore. Generally systems implement message expiration that is if they receive a message which is quite old they discard the message and the “oldness” of the message usually is implementation specific. In some cases the messaging middleware implements the message expiration policy where it specifies how long a particular message type will live or when it will expire. The expired messages are written into dead letter queues for service management activities.

But ebMS2.0 does not specifically talk about what to do after the number of reties expire other than letting the layers above the messaging layer know of the failure to deliver the message. It also does not talk of the slow retry mode (or is it called long retry mode?) or about message expiration at all except for the number of retries as per the contract property.

In one of the large HL7V3.0 implementation where ebXML is implemented for asynchronous messaging it was recommended that systems use HL7 retry mode when sender MSH retries expire without an ACK being received from the receiver. In this particular implementation the system provider suggested that all systems which communicate with a particular sender should implement the “Slow retry” as exponential retry behavior that is, after each ebXML request sequence has failed, the Sender must retry with an increasing time interval. This might run into a problem for outages of longer duration as the persistent duration of the message might expire if at all the message has been received by the receiver but the acknowledgment has not reached the sender from the receiver.

According to ebMS2.0 persistent duration is a parameter which is defined as the minimum length of time data expressed as "duration" from a reliably sent message is kept in persistent storage by a Receiving MHS node. If the persistent duration has passed since the message was first sent, the Sending MSH SHOULD NOT resend the message with the same ebXML MessageId though the HL7 Message Id should be the same.

If response is not returned even after ebXML retries and “slow retry” there is no other way other than handling the problem manually. In case of Multi-Hop using a intermediary slow retry is not suggested at all it has to be handled manually as Multi-Hop do not conform to eith SEF or RIF(See my post on HL7 Forms of Operation)

EHR White Paper

Nation and Region Wide Electronic Health Records are currently deployed or are being deployed in several countries around the world to enable sharing of care records within an organization and between different organizations. This sharing of health records would enable the patient's medical history and other details to be available at the point of care and would enable effective treatment of patients. This is further discussed in a paper which was published on TCS web site where i work in which the need for Electronic Health Records (EHR) andthe key design principles for EHR are described.


The link for the white paper is at

http://www.tcs.com/SiteCollectionDocuments/White%20Papers/TCS_WP_NatHealth.pdf