HL7V2.x Implementation

The key activities that need to be considered for the implementation of a HL7 version 2.x are

• Identifying the list of relevant messages from the standard documentation set


• Mapping of the fields in the messages to the attributes in the application database


• Identifying the tools and methods for construction of messages based on the triggers in the application


• Identifying the tools for message communication and validation.
  

Message Identification

The messages are identified based on the data flows required for the healthcare organization. The transactions that need to trigger these messages in the sender need to be identifier along with the list of receiving systems. The required and optional segments in each of the messages are identified. Any implementation specific data those are not available in the standard segment need to be sent in the user defined Z segments.

Message Mapping

Message mapping involves mapping of HL7 data elements to the application tables, columns and code sets. This is a crucial step of the implementation and involves specialist knowledge of the application and healthcare domain.

Message Generation

The construction and generation of version 2.x messages from healthcare systems can be done using three different approaches which are depicted in Figure and described below

Native Generation – The messages can be generated natively within the application using the same software components that makeup the core application. This approach is advantageous for enterprises with lower interfaces and a small number of departmental systems. This approach is essentially based on point-to-point integration and not suitable for organizations with complex interfaces and large number of departmental systems.

Middleware Approach – This is external to the applications and applications used different mechanisms to communicate with the middleware. These range from systems sending messages and data in a proprietary format based on the event to middleware and it building the message into HL7 format to message sending standard HL7 messages and middleware validating the message before sending the message in format understood by target system.

API Approach – This approach involves deploying readily available software components and libraries external to the application and modifying the applications source code to make a call to the libraries. This is ideal for closed legacy applications and quickens the deployment of HL7.

Messaging Communication

The most commonly used mechanism for sending HL7 Version 2.x messages is Lower Layer Transport protocol (LLP). The messages are sent over TCP/IP over the network.

The protocol is very simple to implement using the implementation setting sockets. The protocol requires that that each message should be preceded with the character 0x0B (11) and followed with the characters 0x1C (28) and 0x0D (13). This is required for communications code to be able to recognize the start and the end of each message Finally each segment is terminated by a 0x0D (13) character. This is mandated by the standard, but often HL7 log data can be received via ftp or email where the segment separators have been transformed into 0x0A characters, etc.

See my post on MLLP and HLLP for more details

Major Implementations of HL7V2.x

Several countries in the world have recognized version 2.x of HL7 as national standard for example version 2.4 is established as a German Industrial Standard. The SCIPHOX (Standardized Communication of Information Systems in Physicians Offices and Hospitals) used standard HL7V2 for communication between hospitals though it used CDA (Clinical Document Architecture; for communication between hospitals. SCIPHOX encompasses laboratory results, diagnoses, medications, procedures and referral data.

National Healthlink Project in Ireland is an electronic communications project between GPs and hospitals. Version 2.4 with XML encoding is used as the messaging standard; for example ADT A01 is used to notify GP’s of a patient visit to A&E; ADTA03 is used to notify GP’s that their patients have been discharged or died. Apart from ADT ORU R01 is used to notify Radiology and Pathology results of patients to their GP’s.

The national layer of Australian Standards documents in the AS4700.x series constrain and localise the ANSI/HL7 v2.x series of standards for use in Australian healthcare settings. Version 2.3/2.3.1 is used for Patient administration, Pathology orders and results, Electronic messages for exchange of information on drug prescription, Discharge and Referrals. Though some of the standards have not been upgraded to 2.4 with most of the sites still using version 2.4


The application vendors and Local service providers of NHS - Connecting for Health programme which are one of the frontrunners in implementation of HL7V3 are using variants of HL7Version2 (CSC: UK HL7vA.2, HL7V2.3,HL7V2.4; BT: UK HL7V2.3;Fujitsu: HL7V2.3) for intra-organisation communication.

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.