The Transit Electronic Health Record

Electronic Health Record is normally seen as repository of aggregate clinical and demographic information fed by point of source systems from different care settings. But the infrastructures associated with the EHR are being used to perform other ancillary functions such as facilitating the data exchange between the different point of the source systems. A classic example is the exchange of patient data between two systems through a project called GP2GP as a part of the UK CFH-Connecting for Health initiative.

The objective of GP2GP record transfer mechanism is to support the exchange of a GP’s (General Practitioner who is the patient primary care service provider in the context of UK) patient record electronically to a new practice when a patient registers with a new GP. In England an estimated 10% of patients change their practice each year and if the average list size of a practice is 1500 then there will be average of 150 transfers each year per practice. Most practices handle this transfer using the standard Lloyd George envelope or Medical Record envelope method for the transfer of the patient’s past care paper record.

The most common process of transfer of the electronic component of the patient record using Lloyd George envelope method is to produce a printout of the content of the medical record and to put it in the Lloyd George MRE at de-registration. Factually few doctors study such printouts and fewer practices re-enter any salient information and this information is unavailable to assist future care. Thus, an effective method which is aimed at the increased use of electronic records by GPs to improve the care of the patients is reducing the data quality of the patient record when passed to other GPs.

Currently England under CFH with history of pilot implementation of GP2GP using HL7 V3.0 by HIRI (Health Informatics Research International Ltd) consortium in 2003 is now trying to provide this transfer electronically using the national infrastructure and methodology developed under the National Programme for IT-CFH. The GP2GP messages, designed form part of the CFH Message Implementation Manual to support an automated request, acknowledgement and send of the electronic component of the record to assist in the continuation quality electronic records when a patient moves practice.

The objectives and benefits of GP2GP as per CFH website (http://www.connectingforhealth.nhs.uk/systemsandservices/gpsupport/gp2gp) are twofold – benefits the patients and benefits to the practice administration. The benefits of using GP2GP to the patients as perceived under GP2GP are

Ø The patient health record being available to the new GP a lot sooner (e.g. within 24 hours)

Ø The new GP will have knowledge of the patient’s:
o Current medication
o Drug interactions
o Current problems
o Key past medical history
o An improvement in patient safety

Ø Increase patient confidence that they will get good continuing care

Ø Prevent patients being asked information that they have previously reported

The benefits to the practice administrative support teams as perceived under GP2GP are

Ø Reduction in administrative time at the previous GP practice to find and forward on patient records to the new GP practice

Ø Reduction in administrative and clinical time at the new GP practice to review and summarize or re-key the patient record received from the previous GP practice

Ø Reduction in the time taken for the practice to receive the patient record

Ø Reduction in administrative time to chase up patient records from Health Authorities

Exchange Mechanism under CFH GP2GP

The GP2GP process under CFH starts with the registration of a new patient with a GP practice. The GP2GP explicit flows are triggered by the NHAIS Registration links acceptance message flow and the update of the GP registration on a national MPI database called PDS (Personal Demographic Services) which is a part of the national EHR called Spine.

The GP2GP process covers the electronic transfer of the patient record between primary care systems through the MHS (Message Handling Service) of the Spine supplied by the NHS Care Record (NCRS) National Application Service Provider (NASP). There is no interaction with the on-going paper process of transferring Lloyd George envelopes.

The Expected basic functionality provided as part of GP2GP by CFH is as follows

Ø Construct and process EHR Request & Acknowledgement messages
Ø Construct and transfer EHR Extract and integrate into receiving system

Figure below the GP Exchange under CFH GP2GP when a patient shifts from Practice A to Practice B. The exchange is based on intermediary ebXML exchange where the infrastructure of the national EHR called Spine is used as the intermediary MHS.

A1- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration

A2- patient requests a registration with a GP/ GP practice. The GP/GP practice decides to either accept or reject a request for registration

A3- As part of the local registration process, the PDS is queried for the patient’s up to date details e.g. demographics, NHS number and current registration details

A4-The Spine Integration infrastructure will route the query to PDS which will populate a response message with the available patient details. If no record of the patient exists on PDS then a new entry will be created and appropriate PDS update messages sent

A5- The patient demographics and NHS number content of the PDS query response is integrated in the local system.

A6- The GP system will interrogate a national directory called SDS to find out if the practice system with which the patient was previously registered is compliant for GP2GP record transfer messages. The SDS keeps a list of all compliant systems.

A7-If the SDS response is negative e.g. the practice system is unable to send/receive GP2GP record transfer messages then the GP system will alert the user to the fact that no electronic transfer of the existing patient record is available

A8- A positive SDS response will trigger a record transfer request to be sent to Spine to route it to the GP practice system.

A9 - The Spine will route it to the GP practice system with which the patient was previously registered

A10- GP system will receive the request and alert appropriate users to the request.

A11- The EHR Request will be considered by the requested GP Practice

A12- The GP system will send an acknowledgement of receipt of the request to the spine which acts as intermediary to be sent to the requesting GP system.

A13- The Spine will forward the acknowledgement of receipt of the request to the requesting GP system.

A14- The GP system will receive the acknowledgement.

A15- The GP system will alert appropriate users to the receipt of the acknowledgement.

A16- If the request can be fulfilled the GP system will send the patient’s Primary care record as an EHR extract message to the Spine

A17- The Spine will forward the EHR extract to the requesting system by acting as intermediary.

A18- The GP system will receive an EHR extract

A19- The GP system will notify appropriate users to the receipt of EHR extract

A20- The EHR extract will be considered by the requested GP Practice

A21- The EHR extract will be integrated with the appropriate patients record

PS: Iam not sure why they are called EHR messages though but again everyone have their own definitions

HL7V3 and ebXML - Part 3

I apologise for the delay in publishing the Part 3 of the ebXML and HL7V3. I see that a portion of hits to my blog are coming from the links provided by Marc de Graauw in Section 7 of his article Implementing “Web Services in Dutch Healthcare” at http://www.ringholm.de/docs/03030_en.htm. I thank him for considering my blog posts worth the mention.

What is ebXML MSH?

HL7 V3 message triggered from Sender are sent over their integration layer as HL7 Request to sender MSH (Message Service Handler). MSH is a piece of software used to send and receive ebXML messages. Figure below shows the functions of MSH.

The textual description of the services depicted above is given below

Ø MSH Service Interface – This is the abstract interface applications use to interact with MSH to send and receive messages.

Ø Header Processing – the creation of the ebXML Header elements for the messages sent from the applications. It also involves parsing of header elements and interactions with contract properties. [See below for Contract Properties]

Ø Security Services – this includes digital signature creation in the messages (which may be used in headers), verification, encryption, authentication and authorization.

Ø Message Packaging – this will perform the enveloping of an ebXML Message (ebXML header elements and payload) into its SOAP Messages with Attachments container

Ø Reliable Messaging Services – this service handles the delivery and acknowledgment of ebXML Messages. It also deals with persistence of messages, retry, error notification and acknowledgment of messages requiring reliable delivery.

Ø Transport Binding – This is the abstract interface between the MSH and the various protocol stacks.

Ø Error Handling – this handles the logging and reporting of errors encountered during MSH or Application processing of a message.

Contract Properties

To understand the exchange of messages between two MSH’s we need to understand the term “contract properties”

Each MSH processes the messages sent by the other MSH by the contracted interface properties. These properties describe Quality of Service (QoS) from reliability and security point of view. The MSH uses these properties to build the ebXML wrapper. The contract properties are defined during message definition process and agreed between two organizations or two system vendors who will exchange the messages. Contract properties are defined for each HL7 interaction. The contract properties given for each interaction are identified by a CPAId. The sender will use the CPAId that is relevant for that HL7 message interaction and agreed with the receiver.

The relevant contract properties are Service, Action, Persist Duration, RetryInterval, Retries, AckRequested, SyncReplyMode, Actor, EndPoint, IsAuthenticated etc.- See HL7V3 and ebXML – Part 1 for details about these properties.

ebXML Message Exchange :

Figure below shows the sequencing involved in ebXML message exchange

Let me explain the flow in the above sequence diagram

1. In a typical implementation the Sender builds the HL7 message with the HL7 Wrapper and passes it onto the sender MSH

2. The sender MSH looks at the message interaction id and looks up in the database for the contract properties for the message and builds the ebXML wrapper.

3. The ebXML message sent by sender MSH containing the HL7 message payload will get ebXML acknowledgement synchronously on the same connection over HTTP 202. The ebXML Acknowledgements are sent without a payload.

4. If the ebXML acknowledgement from Receiver MSH is not received within a time interval Sender MSH resends the message. The number of retries and retry time interval are dependant upon the contract properties attached with that message.

5. If the number of retries expires depending upon the message business functionality Sender MSH will report the error back to application which sent the message or enter into a HL7 slow retry method.

6. In case of ebXML errors Receiver MSH sends a message with the same end-point binding associated with ebXML acknowledgement service except that a Message Error will be sent.

7. The business responses or application acknowledgements from Receiver MSH in response to the message sent are received and processed by the Sender MSH exactly in the same fashion as Receiver MSH does on receiving a request from Sender MSH.

The above description is only for direct reliable message exchange between two MSH's ; we can have intermediary exchange with two MSH's communicating to each other using anothe MSH or we can also have direct unreliable message exchange. I have not discussed them here not i do intend to discuss them here.

HL7V3 and ebXML - Part 2

In this post we will look at the second MIME part which we mentioned in the first part as Payload Containers containing application level payloads. We will observe what exactly is contained in the Payload containers. The payload container contains HL7V3 composite messages composed of three parts

Ø Transmission or Transport Wrapper

Ø Control Act Wrapper

Ø HL7 Domain content

Figure below shows the structure of the second MIME part when expanded

The Transport wrapper includes information needed by a sending application or ebXML message handler route HL7V3 composite Message to the intended receiving application(s) and/or message handler.

As in the first post let me take an example and explain it

-------------------------------

<PRPA_IN040000UV15 xmlns="urn:hl7-org:v3" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN040000Uv15.xsd">
<id root="36E66A20-1DD2-11B2-90FA-80CE4046A4A7"/>
<creationTime value="20061123154933"/>
<versionCode code="V3PR1"/>
<interactionId root="2.16.840.1.113883" extension="PRPA_IN040000UV15"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="NE"/>
<Receiver typeCode="RCV">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="12345"/>
</device>
</Receiver>
<Sender typeCode="SND">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="67890"/>
</device>
</Sender>
<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
<----->
< ----->
</author>
<subject typeCode="SUBJ" contextConductionInd="false">
<RegistrationRequest classCode="REG" moodCode="RQO">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<addr use="H">

<postalCode>SL11NH</postalCode>
<streetAddressLine>oxform farm</streetAddressLine>
<streetAddressLine/>
<streetAddressLine/>
<streetAddressLine>Slough</streetAddressLine>
<useablePeriod>
<low value="19550101"/>
</useablePeriod>
</addr>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<family>Ashok</family>
<given>Mehra</given>
</name>
<administrativeGenderCode code="2"/>
<birthTime value="19550101"/>
</patientPerson>

<----------------->
<------------------>


</RegistrationRequest>
</subject>
</ControlActEvent>
</PRPA_IN040000UK15>

-------------------------------

1. The second MIME starts with the name of the message interaction ; name space and schema location

<PRPA_IN040000Uv15 xmlns="urn:hl7-org:v3" xmlns:fo="http://www.w3.org/1999/XSL/Format" xmlns:voc="urn:hl7-org:v3/voc" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:hl7-org:v3 PRPA_IN040000Uv15.xsd">

PRPA_IN040000Uv15 is the name of the message interaction and is the same as the one included in the Action element of ebXML wrapper.

2. The next attribute is the unique identifier for this message. It is based on the I I – Instance identifier data type. Instance identifier contains root of type UID(Unique identifier ) , extension(ST) , assigningAuthorityName(ST) and displayable(Boolean). Most of the case the root alone may be the entire instance identifier. Figure below shows a case where the identifier has a DCE UUID held in the root attribute

<id root="36E66A20-1DD2-11B2-90FA-80CE4046A4A7"/>

3. The next set of relevant attributes are given below

<creationTime value="20061123154933"/>
<versionCode code="V3PR1"/>
<interactionId root="2.16.840.1.113883" extension="PRPA_IN040000UV15"/>
<processingCode code="P"/>
<processingModeCode code="T"/>
<acceptAckCode code="NE"/&gt;

The creationTime is date and time that the sending system created the message and it uses the datatype-TS

The versionCode is the domain of HL7 version codes for the Version 3 standards. Values are to be determined by HL7 and added with each new version of the HL7 Standard. HL7V3 2006 normative edition has a default value of V3PR1. In UK-CFH land this field is used to define the version of MIM-Message Implementation Manual from to which the message interaction belongs to e.g. V3NPfIT3.1.10 indicating that this message interaction is from MIM3.1.10.

The interaction identifier is a unique reference to the message type, trigger event and application roles that send and receive the message. This is the same as the one populated in the Action element of ebXML wrapper. The root contains the OID value. An OID (object identifier) is a numeric string that is used to uniquely identify an object. OIDs are intended to be globally unique. They are formed by taking a unique numeric string (e.g. 1.3.5.7.9.24.68) and adding additional digits in a unique fashion (e.g. 1.3.5.7.9.24.68.1, 1.3.5.7.9.24.68.2, 1.3.5.7.9.24.68.1.1, etc.)

The processing code is used to identify the environment that the message must be processed in. The possible values for this are D-Debugging; P-Production and T-Training.


The processingModeCode is a code identifying the mode that this message is being sent in. The possible values for this are A-Archive Mode; I- Initial Mode ; R- Restore from Archive and T- Current Processing.

The acceptAckcode is a code identifying the conditions under which accept acknowledgements are required to be returned in response to this message. The possible values are AL- Always, ER- Error and NE- Never.


4. The transport wrapper carries information about the receiver and sender systems for the messages as shown below

<Receiver typeCode="RCV">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="12345"/>
</device>
</Receiver>
<Sender typeCode="SND">
<telecom use="WP" value="tel:+441754527301">
<device classCode="DEV" determinerCode="INSTANCE">
<id root="2.16.840.1.113883.2.4.99.1" extension="67890"/>
</device>

It starts with the typeCode; The three RIM back-bone classes -- Participation, ActRelationship and RoleLink -- are not represented by generalization-specialization hierarchies. these classes represent a variety of concepts, such as different forms of participation or different kinds of relationships between acts. These distinctions are represented by a typeCode attribute that is asserted for each of these classes. For a receiver the receiver has a typeCode value of RCV-Receiver and for Sender SND-Sender. Both sender and receiver carry the information identifying the device.

The device starts with a Classcode [w.r.t Entity ClassCode is an HL7 defined value representing the class or category that the Entity instance represents.] and for both sender and receiver has a fixed value DEV indicating that the entity is a device. It also has a determinerCode which is an HL7 defined value representing whether the Entity represents a kind-of or a specific instance. In this case it is an “INSTANCE”.

It optionally carries the telecom value – WP indicating that it is a work phone. The id is a single unique identifier of the accredited system that represents the party who is either sending or receiving the message. The root carries the OID and the extension carries the application identifier. Optionally it can also carry the Name , Manufacturer , Software name and the represented organization as shown below.

<receiver typeCode="RCV">
<telecom use="WP" value="tel:+31303248724"/>
<device classCode="DEV" determinerCode="INSTANCE">
<id extension="700856" root="2.16.840.1.113883.2.4.99.1"/>
<name use="L">
<given>CAREEX</given>
</name>
<agencyFor classCode="AGNT">
<representedOrganization classCode="ORG" determinerCode="INSTANCE">
<id extension="100100" root="2.16.840.1.113883.2.4.99.1"/>

<name use="L">
<given>Uxbridge Hospital</given>
</name>
</representedOrganization>
</agencyFor>
</device>
</receiver>

5.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

The "semantic content" of a HL7V3 message is the combination of the ControlAct and the payload. Tofully understand the trigger event you need both. The Control Act just says "Please 'do something' with 'this thing'".The payload is needed to indicate what 'this thing' is. However, the bulk of the trigger event information is attached to the Control Act.

<ControlActEvent classCode="CACT" moodCode="EVN">
<author typeCode="AUT">
< ----->
< ----->
</author>
<subject typeCode="SUBJ" contextConductionInd="false">

The message types defined in the Message Control Act Infrastructure section of the HL7V3 2006 Normative ballot are highly generic and inclusive. Message designers and implementers can further refine and constrain Trigger Event Control Acts.

6.The last part of the message is the "HL7 Domain Content" which is the primary domain content of the messaging interaction .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. For example the below is an loose example of a RegistrationRequest domain in which a extract of the message used to capture the details of patient used to register a patient are sent.

<RegistrationRequest classCode="REG" moodCode="RQO">
<subject typeCode="SBJ">
<patientRole classCode="PAT">
<addr use="H">
<postalCode>SL11NH</postalCode>
<streetAddressLine>oxform farm</streetAddressLine>
<streetAddressLine/>
<streetAddressLine/>
<streetAddressLine>Slough</streetAddressLine>
<useablePeriod>
<low value="19550101"/>
</useablePeriod>
</addr>
<patientPerson classCode="PSN" determinerCode="INSTANCE">
<name use="L">
<family>Ashok</family>
<given>Mehra</given>
</name>
<administrativeGenderCode code="2"/>
<birthTime value="19550101"/>
</patientPerson>

<----------------->
<------------------>
</RegistrationRequest>

In the final post next week in ths series i will try to explain the actual implemenation mechanics.

HL7V3 and ebXML - Part 1

In 2003 HL7 Board of Directors approved usage of ebXML for transporting HL7V3 messages as Draft Standard for Trail Use (DSTU) . The English Connecting for Health is one of the first major users of this transport and all HL7V3 asynchronous messages communications in that project is performed using ebXML. This is the first of blogs to understand the relationship between HL7v3 and ebXML . In this process we will also discuss the structure of HL7V3 message as well.


Figure below shows the general structure and composition of an ebXML message

The ebXML Message is a MIME/Multipart message envelope structured in compliance with the SOAP Messages with Attachments specification and is referred to as Message Package.

The Message Package is divided logically into two MIME parts

• A MIME part, referred to as Header Container containing one SOAP 1.1 compliant message. This message is referred to as SOAP message



• Zero or more additional MIME parts referred to as Payload Containers containing application level payloads

The SOAP Message is an XML document that consists of the SOAP Envelope element. The SOAP Envelope element consists of the following:

• SOAP Header element - This is a generic mechanism for adding features to a SOAP Message, including ebXML specific header elements.



• SOAP Body element. - This is a container for message service handler control data and information related to the payload parts of the message.

In this post let’s discuss the first MIME part containing the SOAP envelope. Let me take an example of ebXML wrapper and run through so that the context can be understood.

Now let us analyse the wrapper in detail

--------------------------------------------------------

<soap-env:Envelope

xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd" xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd" >
<soap-env:Header>
<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">
<eb:From>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1 </eb:PartyId>
</eb:From>
<eb:To>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
</eb:To>
<eb:CPAId>ABC22</eb:CPAId>
<eb:ConversationId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:ConversationId>
<eb:Service>urn:org:names:services:MPI</eb:Service>
<eb:Action>PRPA_IN040000UV15</eb:Action>
<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
</eb:MessageData>
<eb:DuplicateElimination/>
</eb:MessageHeader>
<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml-msg:actor:toPartyMSH" />
</soap-env:Header>
<soap-env:Body>
<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="cid:payload@hl7.com">
<eb:Schema eb:location="http://www.info.org.uk/schema/HL7-Message.xsd" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
</eb:Reference>
</eb:Manifest>
</soap-env:Body>
<soap-env:Envelope>

----------------------------------------------------

1. The wrapper starts with name space declaration

<soap-env:Envelope
xmlns:soap-env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
xmlns:hl7ebxml="urn:hl7-org:transport/ebXML/DSTUv1.0" xmlns:xlink="http://www.w3.org/1999/xlink" xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd >

Name space declaration for the ebXML SOAP extensions may be included in the SOAP Envelope, Header or Body elements, or directly in each of the ebXML SOAP extension elements.

The SOAP namespace: “http://schemas.xmlsoap.org/soap/envelope/ “ resolves to a W3C XML Schema specification. The ebXML OASIS ebXML Messaging TC has provided an equivalent version of the SOAP schema conforming to the W3C Recommendation version of the XML Schema specification
http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd

The XML schema-instance namespace qualified schemaLocation attribute in the SOAP envelope to indicate to validating parsers a location of the schema document should be used to validate the document is also included.
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:schemaLocation="http://schemas.xmlsoap.org/soap/envelope/ http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd


[HL7-ebXML] extends the ebXML headers within the HL7 ebXML namespace. The namespace declaration for the extensions has a required value of:
xmlns:hl7ebxml=”urn:hl7-org:transport/ebxml/DSTUv1.0”

2. The next is SOAP Header Element

<soap-env:header>

The SOAP Header element is the first child element of the SOAP Envelope element. The SOAP Header contains MessageHeader which is required element containing routing information for the message as well as other context information about the message. The other element is SyncReply which is a element indicating the required transport state to the next SOAP node.

The SOAP Header element is the first child element of the SOAP Envelope element. The SOAP Header contains MessageHeader which is required element containing routing information for the message as well as other context information about the message. The other element is SyncReply which is an element indicating the required transport state to the next SOAP node.

3. The Message Header starts with Version and SOAPUnderstand attribute as shown below

<eb:MessageHeader soap-env:mustUnderstand="1" eb:version="2.0">

The REQUIRED version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The REQUIRED SOAP mustUnderstand attribute on SOAP Header extensions, namespace qualified to the SOAP namespace (http://schemas.xmlsoap.org/soap/envelope/), indicates whether the contents of the element MUST be understood by a receiving process or else the message MUST be rejected in accordance with SOAP [SOAP]. This attribute with a value of '1' (true) indicates the element MUST be understood or rejected.

4. The next element is the From Element

<eb:From>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP1</eb:PartyId>
</eb:From>

The REQUIRED From element identifies the Party that originated the message. It can contain logical identifier such as DUNS number or other identifiers that also imply a physical location such as an email address. It contains the Party Id element. The PartyId element has a single attribute, type and the content is a string value. The type attributeindicates the domain of names to which the string in the content of the PartyId element belongs. The value of the type attribute MUST be mutually agreed and understood by each of the Parties. It is RECOMMENDED that the value of the type attribute be a URI.

5. The next element is the To Element

<eb:To>
<eb:PartyId eb:type="urn:org:names:partyIdType:xxx">HOSP2</eb:PartyId>
</eb:To>

The REQUIRED To element identifies the Party that is the intended recipient of the message. It can contain logical identifier such as DUNS number or other identifiers that also imply a physical location such as an email address. It contains the Party Id element. The PartyId element has a single attribute, type and the content is a string value. The type attribute indicates the domain of names to which the string in the content of the PartyId element belongs. The value of the type attribute MUST be mutually agreed and understood by each of the Parties. It is RECOMMENDED that the value of the type attribute be a URI.

6.The CPAId element is a string that identifies the parameters governing the exchange of messages between the parties.

<eb:CPAId>ABC22</eb:CPAId>

The recipient of a message MUST be able to resolve the CPAId to an individual set of parameters, taking into account the sender of the message. The value of a CPAId element MUST be unique within a namespace mutually agreed by the two parties. The value ABC22 reference the contract properties assigned to each service/action.

7. The ConversationId element is a string identifying the set of related messages that make up a conversation between two Parties. It MUST be unique within the context of the specified CPAId.

<eb:ConversationId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7 </eb:ConversationId>

The Party initiating a conversation determines the value of the ConversationId element that SHALL be reflected in all messages pertaining to that conversation. The ConversationId enables the recipient of a message to identify the instance of an application or process that generated or handled earlier messages within a conversation. It remains constant for all messages within a conversation. The value used for a ConversationId is implementation dependent.

8. The Service element identifies the service that acts on the message and it is specified by the designer of the service

<eb:Service>urn:org:names:services:MPI</eb:Service>

The designer of the service may be:
• a standards organization, or
• an individual or enterprise

The above value indicates that it has something to do with the Master Patient Index

9.The Action element identifies a process within a Service that processes the Message. Action SHALL be unique within the Service in which it is defined

<eb:Action>PRPA_IN040000UV15</eb:Action>

The value of the Action element is specified by the designer of the service. The above value is the message interaction that is sent with this ebXML wrapper and used for the MPI service.

10. The MessageData element provides a means of uniquely identifying an ebXML Message. It contains the following:

MessageId element
Timestamp element
RefToMessageId element

<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
</eb:MessageData>

MessageId is a globally unique identifier for each message conforming to MessageId.

Timestamp is a value representing the time that the message header was created conforming to a dateTime [XMLSchema] and MUST be expressed as UTC

RefToMessageId element has a cardinality of zero or one. When present, it MUST contain the MessageId value of an earlier ebXML Message to which this message relates. If there is no earlier related message, the element MUST NOT be present. For example if is present the Message Data will be something like

<eb:MessageData>
<eb:MessageId>36E66A20-1DD2-11B2-90FA-80CE4046A4A7</eb:MessageId>
<eb:Timestamp>2007-12-23T15:51:33.5</eb:Timestamp>
<eb:RefToMessageId>39E66A20-2DD3-22B3-91FA-81CE4147A4A7 </eb:RefToMessageId>

11.The DuplicateElimination element, if present, identifies a request by the sender for the receiving MSH to check for duplicate messages

<eb:DuplicateElimination/>

12. The AckRequested element is an OPTIONAL extension to the SOAP Header used by the Sending MSH to request a Receiving MSH, acting in the role of the actor URI identified in the SOAP actor attribute, returns an Acknowledgment Message. The AckRequested element contains the following:

• a version attribute
• a SOAP mustUnderstand attribute with a value of "1"
• a SOAP actor attribute
• a signed attribute

<eb:AckRequested soap-env:mustUnderstand="1" eb:version="2.0" eb:signed="false" soap-env:actor="urn:oasis:names:tc:ebxml- msg:actor:toPartyMHS" />

The SOAP mustUnderstand attribute on SOAP Header extensions, namespace qualified to the SOAP namespace (http://schemas.xmlsoap.org/soap/envelope/), indicates whether the contents of the element MUST be understood by a receiving process or else the message MUST be rejected in accordance with SOAP [SOAP]. This attribute with a value of '1' (true) indicates the element MUST be understood or rejected.

The version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".


The AckRequested element MUST be targeted at either the Next MSH or the To Party MSH (these are equivalent for single-hop routing). This is accomplished by including a SOAP actor with a URN value with one of the two ebXML actor URNs defined in sections 2.3.10 and 2.3.11 or by leaving this attribute out. The default actor targets the To Party MSH.


The REQUIRED signed attribute is used by a From Party to indicate whether or not a message received by the To Party MSH should result in the To Party returning a signed Acknowledgment Message – containing a [XMLDSIG] Signature element . Valid values for signed are:
true - a signed Acknowledgment Message is requested, or
false - an unsigned Acknowledgment Message is requested

13.The Manifest element identifies the payload messages that are carried with the ebXML message. Manifest is included in the SOAP:Body. These references can be:

· References to the attached MIME parts using the cid reference mechanism.
· References to remote content not included in the message but accessible via other means and referenced via a URI

<eb:Manifest eb:version="2.0">
<eb:Reference xlink:href="cid:payload@hl7.com">
<eb:Schema eb:location="http://www.info.org.uk/schema/HL7-Message.xsd" eb:version="15" />
<hl7ebxml:Payload style="HL7" encoding="XML" version="3.0" />
</eb:Reference>
</eb:Manifest>

The version attribute indicates the version of the ebXML Message Service Header Specification to which the ebXML SOAP Header extensions conform. Its purpose is to provide future versioning capabilities. For conformance to the current published specification, all of the version attributes on any SOAP extension elements defined in this specification MUST have a value of "2.0".

The Reference element is a composite element consisting of the following subordinate elements:
• zero or more Schema elements – information about the schema(s) that define the instance document identified in the parent Reference element
• zero or more Description elements – a textual description of the payload object referenced by the parent Reference element

The Reference element itself is a simple link [XLINK]. In this context it has the following attribute content

xlink:href – this REQUIRED attribute has a value that is the URI of the payload object referenced. It SHALL conform to the XLINK [XLINK] specification criteria for a simple link.

The schema element provides a means of identifying the schema and its version defining the payload object identified by the parent Reference element. The Schema element contains the following attributes:
• location – the REQUIRED URI of the schema
• version – a version identifier of the schema


The final element is the payload element. This element contains style or standard to which the message in the payload conforms. In this case it is “HL7". It contains the encoding method for the standard which is used to encode the message in the payload. For HL7v3.0 we use "XML". Finally the version of the standard to which the payload message conforms and for HL7V3.0 its 3.0.

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)