HL7 Version 3 Standard: Transport Specification - ebXML, Release 1

ANSI
ANSI/HL7 V3 ebXML, R1-2008
HL7 Version 3 Standard: Transport Specification – ebXML, Release 1
7/3/2008
Responsible Group Infrastructure and Messaging Work Group
HL7
Infrastructure and Messaging TC Co-Chair Grahame Grieve
grahame@kestral.com.au
Infrastructure and Messaging TC Co-Chair Anthony Julian
ajulian@mayo.edu
Infrastructure and Messaging TC Co-Chair Douglas Pratt
Douglass.Pratt@siemens.com
Infrastructure and Messaging TC Co-Chair Scott Robertson
scott.m.robertson@kp.org
Infrastructure and Messaging TC Co-Chair Rene Spronk
rene.spronk@ringholm.com
Implementable Technology Specifications SIG Co-Chair Charlie McCay
charlie@ramseysystems.co.uk
Implementable Technology Specifications SIG Co-Chair Paul Knapp
pknapp@continovation.com
Implementable Technology Specifications SIG Co-Chair Dale Nelson
dale@zed-logic.com
Editor Paul Knapp
pknapp@continovation.com

HTML Generated: 2012-09-06T09:05:05

HL7® Version 3 Standard, © 2008 Health Level Seven® International  All Rights Reserved.

HL7 and Health Level Seven are registered trademarks of Health Level Seven International. Reg. U.S. Pat & TM Off.
Use of these materials is governed by HL7 International's IP Compliance Policy.


Table of Contents


1 ebXML Message Delivery & Message Wrapper
    1.1 Preface
        1.1.1 Current Status
        1.1.2 Key Changes
2 Introduction & Scope
    2.1 Purpose
    2.2 References
    2.3 Lower Level Transports
3 Message Construction
    3.1 Packaging Specification
        3.1.1 example
        3.1.2 example
        3.1.3 example
        3.1.4 example
    3.2 Message Exchange Patterns
    3.3 Restrictions and extensions to the OASIS ebXML Specification
        3.3.1 example
        3.3.2 example
    3.4 Message Delivery
    3.5 Duplicate Message Handling
    3.6 Errors
    3.7 Intermediaries
    3.8 Security
    3.9 ebXML Message Elements
    3.10 ebXML Element and Attribute Sources
    3.11 Document Notes
4 Sample Messages
    4.1 Notes on Sample Messages
        4.1.1 HL7 Version 2 Sample Message
        4.1.2 HL7 Version 2 Sample WSR Acknowledgment
        4.1.3 HL7 Version 2 Sample Application Response Message
        4.1.4 HL7 Version 3 Sample Message
        4.1.5 HL7 Sample ebXML Message with Error
Annexes
A Appendix A
    A.1 HTTP(s) Transport
    A.2 SMTP Transport
B Appendix B
    B.1 Business-Level Requirements
    B.2 -Technical-Level Requirements
C New HL7 Specific Uniform Resource Names
    C.1 HL7II URN
 1ebXML Message Delivery & Message Wrapper
 1.1Preface
 1.1.1Current Status

This document passed the Membership ballot December 2007. The one technical correction from balloters has been applied and some of the sample still need to be updated to current message content. Thank you to all contributors to this specification, and to those organizations which are currently implementing this standard and through that effort will contribute to the evolution of this specification.

 1.1.2Key Changes

This document incorporates the following material changes from the prior version:

  • May 2007: Removal of the Simple TCP Protocol.
  • May 2007: Upgrading of the document to align with "Oasis ebXML Messaging Services Version 3.0: Part 1, Core Features, Working Draft 16, 14 December 2006".
  • May 2007: Addition of a new HL7 URN for HL7 II identifiers.
  • August 2007: Relaxation of the requirement to use a reliable messaging mechanism.
  • August 2007: Addition of WS Reliable Messaging as one of the choices of reliable messaging mechanisms.
  • August 2007: Relaxation of the choice of where the payload to be exchanged is located - SOAP:Body of a simple SOAP message, or MIME Part of a MultiPart MIME message.
  • August 2007: Update references to align with "Oasis ebXML Messaging Services Version 3.0: Part 1, Core Features, Committee Specification 02, 12 July 2007".
  • August 2007: Added comments to address Error detection and processing.
  • August 2007: Correction of conformance verbs.
  • November 2007: Added figures to illustrate the Simple SOAP and Multiplart MIME message structure styles.
  • November 2007: Added guidance on matching Response to Request messages for Intermediaries and removed "(...Routers...)" from the title for this section.
  • November 2007: Added explanitory text to Intermediary and Security sections.
 2Introduction & Scope
 2.1Purpose

The purpose of the ebXML message wrapper is to provide a secure, flexible transport for exchanging HL7 messages and other content, and potentially other message formats, between message handling interfaces or ebXML Message Service Handlers (ebXML MSH). This document describes a specific implementation of the ebXML Message Service Standard as described in "Oasis ebXML Messaging Services Version 3.0: Part 1, Core Features, Committee Specification 02, 12 July 2007" (ebXML Specification).

 2.2References

ebXML – Electronic Business Extensible Markup Language

The ebXML Message Service (ebMS), developed by The Organization for the Advancement of Structured Information Standards [OASIS] January 2002, defines the message enveloping and header document schema used to transfer ebXML messages over a communications protocol such as HTTP or SMTP and the behavior of software sending and receiving ebXML messages. The ebMS is defined as a set of layered extensions to the base Simple Object Access Protocol [SOAP] and SOAP Messages with Attachments [SOAPAttach] specifications. ebMS provides security and reliability features, based on WS Reliability and WSS Security, necessary to support international electronic business. These security and reliability features are not provided in the SOAP or SOAP with Attachments specifications.

ebXML Specification documents may be found at: "http://www.oasis-open.org/committees/documents.php?wg_abbrev=ebxml-msg"

WS Reliability 1.1 documents may be found at: "http://docs.oasis-open.org/wsrm/ws-reliability/v1.1/wsrm-ws_reliability-1.1-spec-os.pdf"

WS Reliable Messaging 1.1 documents may be found at: "http://docs.oasis-open.org/ws-rx/wsrm//v1.1/wsrm.pdf"

WS Security: SOAP Message Security 1.0, 2004 documents may be found at: "http://www.oasis-open.org/wss/2004/01/oasis-200401-wss-soap-message-security-1.0.pdf"

ebXML IIC Technical Committee web site may be found at "http://www.oasis-open.org/committees/ebxml-iic/"

SOAP – Simple Object Access Protocol

SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses.

SOAP documents may be found at "http://www.w3.org/TR/SOAP/".
SOAP with Attachments documents may be found at "http://www.w3.org/TR/SOAP-attachments"
MIME (Multipurpose Internet Mail Extensions) documents may be found at "http://www.ietf.org/rfc/rfc2045.txt".
Internet Message Format documents may be found at "http://www.ietf.org/rfc/rfc2822.txt".
IETF RFC 2392: Content-Id (cid:) and Message-Id (mid:) Uniform Resource Locators scheme document may be found at "http://www.ietf.org/rfc/rfc2392.txt".

 2.3Lower Level Transports

The ebXML message wrappers and transport architecture as described in this document may be used to exchange messages over a variety of lower level transports such as HTTP, SMTP and others. The ebXML Specification includes appendices describing the requirements for transport of the messages and wrappers over HTTP and SMTP. See section 3.3 of this specfication for restrictions and extensions to the base ebXMS specification.

The specific transport used to exchange messages is a matter for trading partner agreement, and MAY require additional transport specific content, such as headers, and/or host routing information, e.g. URL, DNS name, service name etc. The messages themselves and the message handling architecture, what messages are to be exchanged and when, will be consistent regardless of the means used to exchange messages between two message handling interfaces, the Initiating and Responding ebXML MSHs.

 3Message Construction
 3.1Packaging Specification

An ebXML Message is a lower level communication protocol-independent message envelope which may be constructed either as a simple SOAP message, in which case the payload to be exchanged is contained within the SOAP Body element, or as a MIME/Multipart message structured in compliance with the SOAP Messages with Attachments [SOAPATTACH] specification, referred to as a Message Package.

When using the MIME/Multipart style, there are two logical MIME parts within the Message Package:

  • A MIME part, referred to as the Header Container, containing one SOAP 1.1 compliant message. This XML document is referred to as a SOAP Message for the remainder of this specification.
  • One or more 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. This is the root element of the XML document representing the SOAP Message. The SOAP Envelope element consists of the following:

  • One SOAP Header element. This is a generic mechanism for adding features to a SOAP Message, including ebXML specific header elements. This is a container for message service handler control data and information related to the payload parts of the message.
  • One SOAP Body element. This element is only used to store the XML payload when using simple SOAP styled messages exchanges.

The ebXML Specification uses two types of messages: Application User Messages, to convey an application payload; and, Signal Messages to convey errors. WS Reliability messages are used to convey transport level acknowlegements and delivery errors. The ebXML Specification includes support for stand-alone Signal Messages for Message Pull requests, however this feature is not used with this document.

The general structure and composition of an ebXML User Message is described in the following figure. ebXMLfig1_4.jpg
Figure 1 ebXML Message Structure (Copyright OASIS 2006)

Two message structure styles are supported within this specification: Simple SOAP Style, where MIME headers are not present and the message payload is placed in the SOAP Body element; and, Multipart MIME Style, where the MIME headers are present, the SOAP headers are placed in the first MIME part and the payload in the second MIME part.

The Simple SOAP Style message structure is described in the following figure. ebXMLfig1b.jpg
Figure 1a Simple SOAP Style Message Structure (Copyright OASIS 2006)

The Multipart MIME Style message structure is described in the following figure. ebXMLfig1a.jpg
Figure 1b Multipart MIME Style Message Structure (Copyright OASIS 2006)

Sample User Message - Simple SOAP Style

 3.1.1example
SOAPAction: "ebXML"
Content-Type: text/xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>

		<eb:Messaging xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-3_0.xsd" eb:version="3.0" SOAP:mustUnderstand="1">

			<eb:UserMessage>

				<eb:MessageInfo>
					<eb:TimeStamp>2007-03-15T10:02:00</eb:TimeStamp>
					<eb:MessageId>2.1.34567.43.2.5:12345</eb:MessageId>
				</eb:MessageInfo>

				<eb:PartyInfo>
					<eb:From>
						<eb:PartyId eb:type="urn:hl7ii">2.1.34567.43:2</eb:PartyId>
					</eb:From>

					<eb:To>
						<eb:PartyId eb:type="urn:hl7ii">1.2.3.4:5</eb:PartyId>
					</eb:To>
				</eb:PartyInfo>
				
				<eb:CollaborationInfo>
					<eb:AgreementRef>HL7ebxmlV3.0</eb:AgreementRef>
					<eb:Service>urn:services:HL7Request</eb:Service>
					<eb:Action>HL7InteractionId</eb:Action>
					<eb:ConversationId>1.2.3.4.5:2345</eb:ConversationId>
				</eb:CollaborationInfo>

				<eb:MessageProperties>
					<eb:property name="Intermediary">uri:transactionsRus.com</eb:property>
				</eb:MessageProperties>

				<eb:PayloadInfo>
					<eb:PartProperties>
						<eb:property name="Standard">HL7</eb:property>
						<eb:property name="Version">3.0</eb:property>
						<eb:property name="Encoding">XML</eb:property>
					</eb:PartProperties>
				</eb:PayloadInfo>

			</eb:UserMessage>
		</eb::Messaging>
		
		<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsssecurity-secext-1.0.xsd"
		xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsssecurity-utility-1.0.xsd" SOAP:mustUnderstand="1">
		</wsse:Security>

		<wsr:Request xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:MessageId groupId="2.1.34567.43.2.5:12345"></wsr:MessageId>			
			<wsr:ExpiryTime>2007-03-15T10:02:00</wsr:ExpiryTime>
			<wsr:ReplyPattern>
				<wsr:Value>Response</wsr:Value>
			</wsr:ReplyPattern>
			<wsr:AckRequested/>
			<wsr:DuplicateElimination/>
		</wsr:Request>
	</SOAP:Header>

	<SOAP:Body>
		Payload
	</SOAP:Body>
</SOAP:Envelope>

Sample User Message - MultiPart MIME Style

 3.1.2example
MIME-Version: 1.0
SOAPAction: "ebXML"
Content-Type: multipart/related; type ="text/xml"; boundary="MIME_boundary"; start="messagepackage"

--MIME_boundary
Content-ID: <messagepackage>
Content-Type: text/xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>

		<eb:Messaging xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-3_0.xsd" eb:version="3.0" SOAP:mustUnderstand="1">

			<eb:UserMessage>

				<eb:MessageInfo>
					<eb:TimeStamp>2007-03-15T10:02:00</eb:TimeStamp>
					<eb:MessageId>2.1.34567.43.2.5:12345</eb:MessageId>
				</eb:MessageInfo>

				<eb:PartyInfo>
					<eb:From>
						<eb:PartyId eb:type="urn:hl7ii">2.1.34567.43:2</eb:PartyId>
					</eb:From>

					<eb:To>
						<eb:PartyId eb:type="urn:hl7ii">1.2.3.4:5</eb:PartyId>
					</eb:To>
				</eb:PartyInfo>
				
				<eb:CollaborationInfo>
					<eb:AgreementRef>HL7ebxmlV3.0</eb:AgreementRef>
					<eb:Service>urn:services:HL7Request</eb:Service>
					<eb:Action>HL7InteractionId</eb:Action>
					<eb:ConversationId>1.2.3.4.5:2345</eb:ConversationId>
				</eb:CollaborationInfo>

				<eb:MessageProperties>
					<eb:property name="Intermediary">uri:transactionsRus.com</eb:property>
				</eb:MessageProperties>

				<eb:PayloadInfo>
					<eb:PartInfo href="cid:messagePart_1"></eb:PartInfo>
					<eb:PartProperties>
						<eb:property name="Standard">HL7</eb:property>
						<eb:property name="Version">3.0</eb:property>
						<eb:property name="Encoding">XML</eb:property>
					</eb:PartProperties>
				</eb:PayloadInfo>

			</eb:UserMessage>
		</eb::Messaging>
		
		<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsssecurity-secext-1.0.xsd"
		xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsssecurity-utility-1.0.xsd" SOAP:mustUnderstand="1">
		</wsse:Security>

		<wsr:Request xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:MessageId groupId="2.1.34567.43.2.5:12345"></wsr:MessageId>			
			<wsr:ExpiryTime>2007-03-15T10:02:00</wsr:ExpiryTime>
			<wsr:ReplyPattern>
				<wsr:Value>Response</wsr:Value>
			</wsr:ReplyPattern>
			<wsr:AckRequested/>
			<wsr:DuplicateElimination/>
		</wsr:Request>
	</SOAP:Header>

	<SOAP:Body>
	</SOAP:Body>
</SOAP:Envelope>
--MIME_boundary
	Payload
--MIME_boundary--

Sample Reliability Acknowledgement via HTTP

 3.1.3example
HTTP/1.1 200 OK
Server: WS-ReliabilityServer
SOAPAction: ""
Content-Language: en
Content-Type: text/xml; charset="UTF-8"
Content-Length: 412

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>
		<wsr:Response xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:NonSequenceReply groupId="2.1.34567.43.2.5:12345"></wsr:NonSequenceReply>			
		</wsr:Response>
	</SOAP:Header>
	<SOAP:Body/>
</SOAP:Envelope>

Sample Signal Error Message - MultiPart MIME Style

 3.1.4example
MIME-Version: 1.0
SOAPAction: "ebXML"
Content-Type: multipart/related; type ="text/xml"; boundary="MIME_boundary"; start="messagepackage"

--MIME_boundary
Content-ID: <messagepackage>
Content-Type: text/xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>

		<eb:Messaging xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-3_0.xsd" eb:version="3.0" SOAP:mustUnderstand="1">

			<eb:SignalMessage>

				<eb:MessageInfo>
					<eb:TimeStamp>2007-03-15T11:02:00</eb:TimeStamp>
					<eb:MessageId>1.2.3.4.5:2345</eb:MessageId>
					<eb:RefToMessageId>2.1.34567.43.2.5:12345</eb:RefToMessageId>
				</eb:MessageInfo>

				<eb:Error eb:origin="ebMS" eb:category="Communication" 
						eb:errorcode="EBMS:0123" eb:severity="failure" eb:shortdescription="Undeliverable">
						<eb:Description>To Party address not known</eb:Description>
				</eb:Error>
			
			</eb:SignalMessage>
		</eb::Messaging>
		
		<wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsssecurity-secext-1.0.xsd"
		xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wsssecurity-utility-1.0.xsd" SOAP:mustUnderstand="1">
		</wsse:Security>

		<wsr:Request xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:MessageId groupId="1.2.3.4.5:2345"></wsr:MessageId>			
			<wsr:ExpiryTime>2007-03-15T12:02:00</wsr:ExpiryTime>
			<wsr:ReplyPattern>
				<wsr:Value>Response</wsr:Value>
			</wsr:ReplyPattern>
			<wsr:AckRequested/>
			<wsr:DuplicateElimination/>
		</wsr:Request>
	</SOAP:Header>
	<SOAP:Body/>
</SOAP:Envelope>

--MIME_boundary--
 3.2Message Exchange Patterns

Two Message Exchange Patterns are supported:

  • Notify - where the Initiating connection has an application payload to send reliably to the Responder but does not expect an application response.
  • Request/Response - where the Initiating connection has an application payload to send reliably to the Responder and expects an application payload as the response.

In both cases the application messages are exchanged reliably based on WS-Reliability. Also, errors may be reported via: the HTTP response code; a WSR:Response message; an ebXML SignalMessage; or the response application UserMessage.

The Notify Message Exchange Pattern is described in the following figure. ebXMLfig2a_3.jpg
Figure 2a Notify Message Exchange Pattern

The Request/Response Message Exchange Pattern is described in the following figure. ebXMLfig2b_3.jpg
Figure 2b Request/Response Message Exchange Pattern

 3.3Restrictions and extensions to the OASIS ebXML Specification

In order to reduce complexity and maximize interoperability, this specification is more prescriptive than prior versions. It either RECOMMENDS or REQUIRES certain restrictions or extensions to the ebMS specification.

Restrictions

While ebMS MAY support both SOAP 1.1 and SOAP 1.2, this specification REQUIRES the use of SOAP 1.1. A later version of this specification may alter the SOAP version as support for SOAP 1.2 become more widely available.

While the ebMS specification allows for multiple lower level transports, such as HTTP(s) and SMTP, this specification REQUIRES HTTP(s) for synchronous message exchanges, eg. Request-Response.

While the ebMS specification allows for many different Message Exchange Patterns: One-Way/Push, One-Way/Pull, Two-Way/Sync, and potentially others, this specification RESTRICTS message exchange patterns to: One-Way/Push for Notification style messages; and, Two-Way/Sync for Request-Response exchange.

While the ebMS specification allows for Senders and Receivers to orchestrate a suite of Message Partition Flows (MPF), or prioritized message streams, for User Messages, this specification expects all User Messages to be exchanged on the Default MPF.

While the ebMS specification supports defining many Processing Modes (P-Mode) for different message types, which include the: transport; ebMS packaging; reliability; and, security requirements, only two Processing Modes are defined in this specification: one each for the Notify and Request/Response patterns.

This specification REQUIRES the SOAP message to have an XML Prolog, and it MUST have the encoding UTF-8.

Schema hints SHOULD NOT be included in the wire format of messages. If message processors find schema hints in messages they SHOULD ignore them or use them only to reference locally stored schemas.

Extensions

One eb:property element has been added to the /SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:MessageProperties to hold identification information for Intermediaries through which messages pass, eg:

 3.3.1example
<eb:MessageProperties>
	<eb:property name="Intermediary">uri:transactionsRus.com</eb:property>
</eb:MessageProperties>

Three eb:property elements have been added to the /SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties to hold descriptive information on the message to simplify message processing, eg:

 3.3.2example
<eb:PayloadInfo>
	<eb:PartInfo href="cid:messagePart_1"></eb:PartInfo>
		<eb:PartProperties>
			<eb:property name="Standard">HL7</eb:property>
			<eb:property name="Version">3.0</eb:property>
			<eb:property name="Encoding">XML</eb:property>
	</eb:PartProperties>
</eb:PayloadInfo>
 3.4Message Delivery

WS Reliability (WSR) or WS Reliable Messaging (WSRM) MAY be used to support the once-and-only-once delivery of messages, and to provide a positive indication to the Sender of the success or failure of the delivery of the message. The Message Order features of WSR or WSRM is NOT REQUIRED, but may be used by the implementer in agreement with trading partners.

 3.5Duplicate Message Handling

All nodes involved in the transport of the message from the originator to the ultimate receiver SHALL implement a persistent storage mechanism in order to detect and suppress the forwarding of duplicate messages if duplicate suppression is requested. The presence of a /SOAP:Envelope/SOAP:Header/wsr:Request/wsr:DuplicateElimination element in the SOAP Header indicates that duplicate messages SHALL be eliminated and not passed on to the Receiving Application or next message interface. In the context of this specification:

  • an "identical message" is a message that contains the same ebXML SOAP Header, Body and ebXML Payload as the earlier message that was sent.
  • a "duplicate message" is a message that contains the same MessageId as an earlier message that was received.
  • the "first message" is the message with the earliest Timestamp in the MessageData element that has the same RefToMessageId as the duplicate message.
  • for the purpose of this specification an identical message SHALL always be a Duplicate Message

ebXMLfig3_3.jpg

Figure 4 Resending Unacknowledged Messages (Copyright OASIS 2002)

The diagram above shows the behavior that SHALL be followed by the Sending and Receiving ebXML MSHs when Duplicate Elimination is specified. Specifically:

  1. The sender of the message (e.g. Sending ebXML MSH) SHALL resend the "identical message" if no WSR Acknowledgment Message is received.
  2. When the recipient (Receiving ebXML MSH) of the message receives a "duplicate message", it SHALL resend to the sender (Sending ebXML MSH) a message identical to the first message that was sent to the sender (Sending ebXML MSH).
  3. The recipient of the message (Receiving ebXML MSH) SHALL NOT forward the message a second time to the application/process.

The length of time for which message information SHOULD be retained in persistent storage to effectively eliminate duplicates is a an issue for trading partners to determine based upon the nature of the messages being exchanged.

 3.6Errors

Errors may be detected by a Receiving MSH at the HTTP(s), SOAP and ebXML levels. They SHALL be reported back to the Sending MSH only once and at the level and in the style appropriate for the level at which the error was detected. See the HTTP(s), SOAP and ebXML 3.0 specifications for error codes and handling. A Receiving MSH which detects an error SHALL not pass the payload on to a receiving application for processing. When an application detects an error it SHALL handle the error in the manner prescribed by the applicable standard for the payload.

 3.7Intermediaries

An Intermediary (Message Router, Bridge, Gateway) is a system or service which accepts connections and messages on behalf of Sending MSHs which do not know the actual connection route to a given Receiving MSH which serves to route messages between Sending and Receiving MSHs. Intermediaries are mediating elements that act as proxies for the business semantics of the message exchange. They receive messages from message Initiators or other Intermediaries; process, and/or translate, and/or validate messages; and finally, if no errors in the received message are detected, forward the message to the target host or another intermediary which facilitates getting the message to the target host.

The Intermediary SHALL receive and acknowledge Client messages in the same manner as a Receiving ebXML MSH, and perform the same duplicate suppression as would a Receiving ebXML MSH. Once a message is passed to an Intermediary and acknowledged by the Intermediary, the Intermediary assumes responsibility to get the message to the intended target Receiving ebXML MSH.

Intermediaries may correlate Response messages from downstream target hosts to the original Request message from the message initiator via the RefToMessageId element of the Response message which MUST match the MessageId element of the Request message. Also, Request and Response messages MUST use the same contents for their respective ConversationId elements, however the ConversationId element may not be unique to a single Request/Response message pair.

Receiving ebXML MSHs SHALL accept and authenticate connections from Intermediary and otherwise deal with Intermediaries as if they were the Sending ebXML MSH.

All Intermediary MSHs, that is all MSHs but the last, SHALL add an Intermediary Property element to the bottom of the list of eb:MessageProperties containing a string URI which uniquely identifies the Intermediary.

Note: synchronous request-response through an intermediary or through a direct connection to the target host will create a blocked thread on the initiating system.

 3.8Security

Security: authentication, encryption, non-repudiation; signing, are addressed through the WS Security Specification and a wss:Security element in the SOAP:Header. The requirements and use of this capability is a trading partner issue and beyond the scope of this document.

Note: The actual application of security in any form is out of scope for this specification. Security implementors should take note that the use of non-payload persistent security MAY cause issues for Intermediaries or those located behind Intermediaries.

 3.9ebXML Message Elements

Only the elements of specific interest to this implementation are described below, for a description of all elements please refer to the ebXML Specification.. The Src (Source) column below indicates whether the element or attribute is populated from the Message Contents (Msg) or the Message Service Handler (MSH). All items (attributes, elements, parameters and headers) specified below are required unless specified below. All other ebXML elements and attributes not specified below are permitted but MAY be ignored by the receiver.

Location Src Description/Notes
SOAP with Attachments MIME Envelope    
SOAPAction header MSH SHALL be "ebXML"
Content-Type header MSH SHALL be multipart/related
Content-Type header, @type MSH SHALL be text/xml, charset="UTF-8"
Content-Type header, @boundary MSH The string which is used to mark boundaries between MIME parts and terminate the multipart MIME message.
Content-Type header, @start MSH This attribute maps to the Content-ID of the SOAP Envelope MIME part.
SOAP Message    
Content-ID header MSH Maps to the SOAP with Attachments MIME Envelope Content-Type start attribute.
Content-Type header MSH SHALL be text/xml.
Content-Type header, @charset Msg SHALL be UTF-8.
/?xml/@encoding MSH SHALL be UTF-8.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:MessageInfo/eb:MessageId Msg A unique message identifier generated by the sender, either a concatenation of message elements, to create a globally unique identifier, or a single message element if that element is globally unique.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:MessageInfo/eb:Timestamp MSH The timestamp for the message determined by the ebXML MSH when the actual message to be sent is created. Note that the format for this element uses xs:dateTime format while HL7 V3 TS type does not.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:MessageInfo/eb:RefToMessageId Msg Used only in response messages, a copy of the original message MessageId.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:From/eb:PartyId Msg Identification of the message sender.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:From/eb:PartyId@type MSH Domain of the contents if not a uri, eg. "urn:hl7ii' for HL7 V3 Instance Identifiers.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:To/eb:PartyId Msg Identification of the message receiver.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:To/eb:PartyId@type MSH Domain of the contents if not a uri, eg. "urn:hl7ii' for HL7 V3 Instance Identifiers.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:CollaborationInfo/eb:AgreementRef MSH Identification of a Collaboration Protocol Agreement between the sender and receiver. This SHALL contain the trading partner agreed CPA text reference, or HL7ebxmlV3.0.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:CollaborationInfo/eb:Service MSH Identification of the message processing service on the receiver’s end of the conversation. For Notification MEP use urn:services:HL7Notify, for Request/Response MEP use urn:services:HL7Request on request messages and urn:services:HL7Response on response messages.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:CollaborationInfo/eb:Action Msg Identification of the action process within the message processing service on the receiver’s end of the conversation.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:CollaborationInfo/eb:ConversationId MSH For request messages: the message hl7:QueryId in the case of queries, the eb:MessageId otherwise. For response message: the eb:ConversationID from the original request message.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:MessageProperties/eb:property MSH The unique URI for an Intermediate which handles a message. Each Intermediary but the last SHALL add a new Intermediary property element to the end of the list.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:MessageProperties/eb:property@name MSH SHALL be Intermediary..
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartInfo@href MSH Not used in SOAP style messages. For MIME style Messages: A URI that identifies the particular MIME part in the Message Package that corresponds to this payload. The URI SHALL identify the MIME part by its content-id using the cid URI scheme.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:property@name="Standard" Msg The style or standard to which the message in the payload conforms. For HL7 messages use "HL7". Other implementations MAY define additional values such as "X12", "NCPDP", "CDAnet".
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:property@name="Version" Msg The version of the standard to which the payload message conforms.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:property@name="Encoding" Msg The encoding method for the standard which is used to encode the message in the payload. For HL7 use "Delimited" or "XML". Other implementations may define additional values such as "Fixed" .
/SOAP:Envelope/SOAP:Header/wsse:Security MSH This element stores WS Security information. It may be omitted if WS Security is not used.
/SOAP:Envelope/SOAP:Header/wsr:Request/wsr:MessageId@groupId MSH The value of eb:MessageId.
/SOAP:Envelope/SOAP:Header/wsr:Request/wsr:ExpiryTime MSH REQUIRED. Indicates to the ebXML MSHs at what time they should abandon delivering a message.
/SOAP:Envelope/SOAP:Header/wsr:Request/wsr:ReplyPattern/wsr:Value MSH REQUIRED. SHALL be Response.
/SOAP:Envelope/SOAP:Header/wsr:Request/wsr:AckRequested MSH REQUIRED.The presence of this element indicates that a WSR Acknowledgment is required from the next MSH.
/SOAP:Envelope/SOAP:Header/wsr:Request/wsr:DuplicateElimination MSH REQUIRED. Indicates to the Receiving ebXML MSH that it SHALL eliminate duplicate messages.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:SignalMessage/eb:MessageInfo/eb:MessageId Msg A unique message identifier generated by the sender, either a concatenation of message elements, to create a globally unique identifier, or a single message element if that element is globally unique.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:SignalMessage/eb:MessageInfo/eb:Timestamp MSH The timestamp for the message determined by the ebXML MSH when the actual message to be sent is created. Note that the format for this element uses xs:dateTime format while HL7 V3 TS type does not.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:SignalMessage/eb:MessageInfo/eb:RefToMessageId Msg A copy of the original message MessageId.
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:SignalMessage/eb:Error MSH There MAY be multiple ebError elements which contain processing, reception, reliability and other error codes and contents - see the ebXML Specification for details.
Payload    
/SOAP:Envelope/SOAP:Body Msg For simple SOAP style messages, the payload SHALL be a UTF-8 encoded xml document which is placed within the SOAP:Body. For MIME style messsages the payload may be any MIME supported content type and encoding and is placed wthin a MIME part.
Content-ID header MSH Maps to the /SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartInfo@href attribute.
Content-Type header MSH SHALL be application/xml when the payload is cast in xml, for example HL7 V2 and V3 xml encoded, and text/plain when cast as text, for example HL7 V2 VBAR.
Content-Type header, @charset Msg Trading partner specified and or message content specific.
 3.10ebXML Element and Attribute Sources

The tables below detail where in the messages element and attribute contents are sourced. When the payload (HL7 message, CDA document, other content) does not contain the elements and/or attributes below, for example when using reduced wrappers or no transport wrapper, then it is the responsibility of the sending application to convey the required content to the messaging application so that the SOAP headers are correctly populated. When the payload does contain the elements enumerated below, the sending application SHALL use the following mappings.

HL7 version 2 Messages

Location Message Source Notes
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:MessageInfo/eb:MessageId MSH.4 + ":" + MSH.10 Message Control ID MSH.4 + ":" + MSH.10 concatenated
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:From/eb:PartyId MSH.4 Sending Facility  
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:To/eb:PartyId MSH.6 Receiving Facility  
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:CollaborationInfo/eb:Action MSH.9.3 Message Type Third part of the field
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:PartInfo@name="Standard" "HL7"  
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:PartInfo@name="Version" MSH.12 Version ID  
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:PartInfo@name="Encoding" "Delimited" or "XML" Based on actual encoding.

HL7 Version 3 Messages. Note all elements are direct children of the hl7:Message element.

Element/Attribute Message Source Notes
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:MessageInfo/eb:MessageId <id> root attribute [+ ":" + extension attribute] eg: "2.1.456.8:100123"
SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:From/eb:PartyId <sender><device><id> root attribute [+ ":" + extension attribute] eg: ":2.1.456.4:ABC123"
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PartyInfo/eb:To/eb:PartyId <receiver><device><id> root attribute [+ ":" + extension attribute] eg: "2.1.456.4:123"
/SOAP:Envelope/SOAP:Header/eb:MessageHeader/eb:Action Root name String, e.g. "POLB_IN004410"
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:PartInfo@name="Standard" "HL7"  
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:PartInfo@name="Version" <versionCode> code attribute  
/SOAP:Envelope/SOAP:Header/eb:Messaging/eb:UserMessage/eb:PayloadInfo/eb:PartProperties/eb:PartInfo@name="Encoding" "XML" Based on actual encoding.
 3.11Document Notes

Reliance upon schema location hints when provided in the message may present a potential security risk therefore message senders SHOULD not include them in messages and SOAP and ebXML processors are encouraged to ignore them unless the URI provided matches the URI specified in their respective specifications.

The examples provided are based on HL7 ballot #6 (December 2003) and therefore do not necessarily reflect the current message standard.

 4Sample Messages
 4.1Notes on Sample Messages

The following sections contain sample messages to illustrate the construction of ebXML messages with both HL7 version 2 and version 3 payloads, as well as with xml and non-xml payloads. The samples below may contain non-current HL7 message formats and wrappers, these will be brought to current formats as the document progresses. Note that these samples are non-normative exemplars provided only to illustrate the appearance of the final messages.

Example Title Notes
1 HL7 Version 2 Sample Message HL7 Version 2 Admit Notification application message.
2 HL7 Version 2 Sample WSR Acknowledgment The WSR Acknowlegement message from the receiver of the above message.
3 HL7 Version 2 Sample Application Response Message HL7 Version 2 Lab response application message.
4 HL7 Version 3 Sample Message HL7 Version 3 Admit Notification application message.
5 HL7 Sample ebXML Message wiith Error An ebXML message which reports errors in the received message.
 4.1.1HL7 Version 2 Sample Message

MIME-Version: 1.0
SOAPAction: "ebXML"
Content-Type: multipart/related; type ="text/xml"; boundary="MIME_boundary"; start="messagepackage"

--MIME_boundary
Content-ID: <messagepackage>
Content-Type: text/xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>

		<eb:Messaging xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-3_0.xsd" eb:version="3.0" SOAP:mustUnderstand="1">

			<eb:UserMessage>

				<eb:MessageInfo>
					<eb:TimeStamp>2001-02-15T11:17:00Z</eb:TimeStamp>
					<eb:MessageId>MCM:MSG00001</eb:MessageId>
				</eb:MessageInfo>

				<eb:PartyInfo>
					<eb:From>
						<eb:PartyId eb:type="localid">MCM</eb:PartyId>
					</eb:From>

					<eb:To>
						<eb:PartyId eb:type="localid">XYZ</eb:PartyId>
					</eb:To>
				</eb:PartyInfo>
				
				<eb:CollaborationInfo>
					<eb:AgreementRef>HL7ebxmlV3.0</eb:AgreementRef>
					<eb:Service>urn:services:HL7Notify</eb:Service>
					<eb:Action>ADT_A01</eb:Action>
					<eb:ConversationId>MCM:MSG00001</eb:ConversationId>
				</eb:CollaborationInfo>

				<eb:PayloadInfo>
					<eb:PartInfo href="cid:messagePart_1"></eb:PartInfo>
					<eb:PartProperties>
						<eb:property name="Standard">HL7</eb:property>
						<eb:property name="Version">2.4</eb:property>
						<eb:property name="Encoding">Delimited</eb:property>
					</eb:PartProperties>
				</eb:PayloadInfo>

			</eb:UserMessage>
		</eb::Messaging>
		
		<wsr:Request xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:MessageId groupId="MCM:MSG00001"></wsr:MessageId>			
			<wsr:ExpiryTime>2001-02-15T13:17:00Z</wsr:ExpiryTime>
			<wsr:ReplyPattern>
				<wsr:Value>Response</wsr:Value>
			</wsr:ReplyPattern>
			<wsr:AckRequested/>
			<wsr:DuplicateElimination/>
		</wsr:Request>
	</SOAP:Header>

	<SOAP:Body/>
</SOAP:Envelope>
--MIME_boundary
Content-ID: <messagePart_1>
Content-Type: text/plain; charset="UTF-8"

MSH|^~\&|ADT1|MCM|LABADT|XYZ|200102151112|SECURITY|ADT^A01^ADT_A01|MSG00001­|P|2.4|12345678||AL|NE<cr>
EVN|A01|200102091109||<cr>
PID|1||PATID1234^5^M11^ADT1^MR^MCM~123456789^^^USSSA^SS||JONES^WILLIAM^A^III||19610615|M­||C|
1200 N ELM STREET^^GREENSBORO^NC^27401-1020|GL|(919)379-1212|(919)271-3434||S||
PATID12345001^2^M10^ADT1^AN^A|123456789|9­87654^NC|<cr>
NK1|1|JONES^BARBARA^K|WI^WIFE||||NK^NEXT OF KIN<cr>
PV1|1|I|2000^2012^01||||004777^LEBAUER^SIDNEY^J.|||SUR||­||ADM|A0­|<cr>
								
--MIME_boundary--

 4.1.2HL7 Version 2 Sample WSR Acknowledgment

SOAPAction: ""
Content-Language: en
Content-Type: text/xml; charset="UTF-8"
Content-Length: 412

<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>
		<wsr:Response xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:NonSequenceReply groupId="MCM:MSG00001"></wsr:NonSequenceReply>			
		</wsr:Response>
	</SOAP:Header>
	<SOAP:Body/>
</SOAP:Envelope>

 4.1.3HL7 Version 2 Sample Application Response Message

MIME-Version: 1.0
SOAPAction: "ebXML"
Content-Type: multipart/related; type ="text/xml"; boundary="MIME_boundary"; start="messagepackage"

--MIME_boundary
Content-ID: <messagepackage>
Content-Type: text/xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>

		<eb:Messaging xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-3_0.xsd" eb:version="3.0" SOAP:mustUnderstand="1">

			<eb:UserMessage>

				<eb:MessageInfo>
					<eb:TimeStamp>2001-02-15T12:16:00Z</eb:TimeStamp>
					<eb:MessageId>XYZ:LAB00001</eb:MessageId>
					<eb:RefToMessageId>MCM:MSG00051</eb:MessageId>
				</eb:MessageInfo>

				<eb:PartyInfo>
					<eb:From>
						<eb:PartyId eb:type="localid">XYZ</eb:PartyId>
					</eb:From>

					<eb:To>
						<eb:PartyId eb:type="localid">MCM</eb:PartyId>
					</eb:To>
				</eb:PartyInfo>
				
				<eb:CollaborationInfo>
					<eb:AgreementRef>HL7ebxmlV3.0</eb:AgreementRef>
					<eb:Service>urn:services:HL7Response</eb:Service>
					<eb:Action>ACK_A01</eb:Action>
					<eb:ConversationId>MCM:MSG00051</eb:ConversationId>
				</eb:CollaborationInfo>

				<eb:PayloadInfo>
					<eb:PartInfo href="cid:messagePart_1"></eb:PartInfo>
					<eb:PartProperties>
						<eb:property name="Standard">HL7</eb:property>
						<eb:property name="Version">2.4</eb:property>
						<eb:property name="Encoding">Delimited</eb:property>
					</eb:PartProperties>
				</eb:PayloadInfo>

			</eb:UserMessage>
		</eb::Messaging>
		
		<wsr:Request xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:MessageId groupId="XYZ:LAB00001"></wsr:MessageId>			
			<wsr:ExpiryTime>2001-02-15T14:16:00Z</wsr:ExpiryTime>
			<wsr:ReplyPattern>
				<wsr:Value>Response</wsr:Value>
			</wsr:ReplyPattern>
			<wsr:AckRequested/>
			<wsr:DuplicateElimination/>
		</wsr:Request>
	</SOAP:Header>

	<SOAP:Body/>
</SOAP:Envelope>
--MIME_boundary
Content-ID: <messagePart_1>
Content-Type: text/plain; charset="UTF-8"

MSH|^~\&|LABADT|XYZ|ADT1|MCM|200102151213|SECURITY|ACK^A01^ACK|LAB00001­|P|2.4|12345678||NE|NE<cr>
MSA|CA|MSG00051<cr>
								
--MIME_boundary--

 4.1.4HL7 Version 3 Sample Message

MIME-Version: 1.0
SOAPAction: "ebXML"
Content-Type: multipart/related; type ="text/xml"; boundary="MIME_boundary"; start="messagepackage"

--MIME_boundary
Content-ID: <messagepackage>
Content-Type: text/xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>

		<eb:Messaging xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-3_0.xsd" eb:version="3.0" SOAP:mustUnderstand="1">

			<eb:UserMessage>

				<eb:MessageInfo>
					<eb:TimeStamp>2003-07-18T16:10:00.16Z+01</eb:TimeStamp>
					<eb:MessageId>2.16.840.1.113883.2.4.99.1.700222.1:34234</eb:MessageId>
				</eb:MessageInfo>

				<eb:PartyInfo>
					<eb:From>
						<eb:PartyId eb:type="urn:hl7ii">2.16.840.1.113883.2.4.99.1:700222</eb:PartyId>
					</eb:From>

					<eb:To>
						<eb:PartyId eb:type="urn:hl7ii">2.16.840.1.113883.2.4.99.1:700856</eb:PartyId>
					</eb:To>
				</eb:PartyInfo>
				
				<eb:CollaborationInfo>
					<eb:AgreementRef>HL7ebxmlV3.0</eb:AgreementRef>
					<eb:Service>urn:services:HL7Request</eb:Service>
					<eb:Action>PORX_IN932000NL</eb:Action>
					<eb:ConversationId>2.16.840.1.113883.2.4.99.1.700222.1:34234</eb:ConversationId>
				</eb:CollaborationInfo>

				<eb:PayloadInfo>
					<eb:PartInfo href="cid:messagePart_1"></eb:PartInfo>
					<eb:PartProperties>
						<eb:property name="Standard">HL7</eb:property>
						<eb:property name="Version">V3PR1</eb:property>
						<eb:property name="Encoding">XML</eb:property>
					</eb:PartProperties>
				</eb:PayloadInfo>

			</eb:UserMessage>
		</eb::Messaging>
		
		<wsr:Request xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:MessageId groupId="2.16.840.1.113883.2.4.99.1.700222.1:34234"></wsr:MessageId>			
			<wsr:ExpiryTime>2003-07-18T18:10:00.16Z+01</wsr:ExpiryTime>
			<wsr:ReplyPattern>
				<wsr:Value>Response</wsr:Value>
			</wsr:ReplyPattern>
			<wsr:AckRequested/>
			<wsr:DuplicateElimination/>
		</wsr:Request>
	</SOAP:Header>

	<SOAP:Body/>
</SOAP:Envelope>
--MIME_boundary
Content-ID: <messagePart_1>
Content-Type: application/xml; charset = "UTF-8"
								
<?xml version="1.0" encoding="UTF-8"?>
<PORX_IN932000NL xmlns="urn:hl7-org:v3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="urn:hl7-org:v3 PORX_IN932000NL.xsd">
	<id extension="34234" root="2.16.840.1.113883.2.4.99.1.700222.1"/>
	<creationTime value="20030718161000"/>
	<versionCode code="V3PR1"/>
	<interactionId extension="PORX_IN932000NL" root="2.16.840.1.113883"/>
	<processingCode code="P"/>
	<processingModeCode code="T"/>
	<acceptAckCode code="NE"/>	
	<controlActProcess moodCode="RQO">
		<!-- message payload -->
		...
	</controlActProcess>
								
	<receiver typeCode="RCV">
		<telecom use="WP" value="tel:+31303248724"/>	
		<device classCode="DEV" determinerCode="INSTANCE">
			<!-- receiving application, ID of receiving system -->
			<id  extension="700856" root="2.16.840.1.113883.2.4.99.1"/>
			<name use="L">
				<given>ZIM</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>ZIM Beheersorganisatie Regio Utrecht</given>
					</name>
				</representedOrganization>
			</agencyFor>
		</device>
	</receiver>
								
	<sender typeCode="SND">
		<telecom use="WP" value="tel:+31307236354"/>
		<device classCode="DEV" determinerCode="INSTANCE">
			<!-- sending application, ID of sending system -->
			<id extension="700222" root="2.16.840.1.113883.2.4.99.1"/>
			<name use="L">
				<given>ABC-ZIS/St.Jozef Ziekenhuis</given>
			</name>
			<agencyFor classCode="AGNT">
				<representedOrganization classCode="ORG" determinerCode="INSTANCE">
					<id extension="600862" root="2.16.840.1.113883.2.4.99.1"/>
						<name use="L">
							<given>St.Jozef Ziekenhuis</given>
						</name>
				</representedOrganization>
			</agencyFor>
		</device>
	</sender>
								
</PORX_IN932000NL>
								
--MIME_boundary--

 4.1.5HL7 Sample ebXML Message with Error

MIME-Version: 1.0
SOAPAction: "ebXML"
Content-Type: multipart/related; type ="text/xml"; boundary="MIME_boundary"; start="messagepackage"

--MIME_boundary
Content-ID: <messagepackage>
Content-Type: text/xml; charset="UTF-8"
<?xml version="1.0" encoding="UTF-8"?>
<SOAP:Envelope xmlns:SOAP="http://schemas.xlmsoap.org/soap/envelope/">
	<SOAP:Header>

		<eb:Messaging xmlns:eb="http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-3_0.xsd" eb:version="3.0" SOAP:mustUnderstand="1">

			<eb:SignalMessage>

				<eb:MessageInfo>
					<eb:TimeStamp>2001-02-15T11:12:00Z</eb:TimeStamp>
					<eb:MessageId>XYZ.20010215.111800.12345</eb:MessageId>
					<eb:RefToMessageId>MCM:MSG00001</eb:RefToMessageId>
				</eb:MessageInfo>

				<eb:Error eb:origin="ebMS" eb:category="Communication" 
						eb:errorcode="EBMS:0123" eb:severity="failure" eb:shortdescription="Undeliverable">
						<eb:Description>URI of eb:From not known</eb:Description>
				</eb:Error>
			
			</eb:SignalMessage>
		</eb::Messaging>
		
		<wsr:Request xmlns:wsr="http://docs.oasis-open.org/wsrm/2004/06/ws-reliability-1.1.xsd" SOAP:mustUnderstand="1">
			<wsr:MessageId groupId="XYZ.20010215.111800.12345"></wsr:MessageId>			
			<wsr:ExpiryTime>2001-02-15T12:12:00Z</wsr:ExpiryTime>
			<wsr:ReplyPattern>
				<wsr:Value>Response</wsr:Value>
			</wsr:ReplyPattern>
			<wsr:AckRequested/>
			<wsr:DuplicateElimination/>
		</wsr:Request>
	</SOAP:Header>
	<SOAP:Body/>
</SOAP:Envelope>

--MIME_boundary--

Annexes for: HL7 Version 3 Standard: Transport Specification - ebXML, Release 1

appnA:  Appendix A

Trading partners MAY select from any of the lower level transports detailed in this section to exchange ebXML messages.

A.1   HTTP(s) Transport

For specifications on the use of HTTP(s) for the exchange of ebXML messages refer to the "Oasis ebXML Messaging Services Version 3.0: Part 1, Core Features, Working Draft 16, 14 December 2006" Appendix C.

A.2   SMTP Transport

For specifications on the use of SMTP for the exchange of ebXML messages refer to the "Oasis ebXML Messaging Services Version 3.0: Part 1, Core Features, Working Draft 16, 14 December 2006" Appendix C.

appnB:  Appendix B

This section will need to be revised to match the new ebXML requirements as available.

The format of this document is based on the [Deployment Guide Template for ebXML] developed by the OASIS ebXML Interoperability, Implementation and Conformance TC. This template was developed for the purpose of describing business interoperability profiles for the use of ebXML Messaging in specific communities. It separates two types of requirements: 1. Business-level requirements 2. Technical-level requirements

B.1   Business-Level Requirements
B.1.1   3.1.1.1 PartyId Element
Specification Value
Is a specific standard used for party identification? Provide details. Party Identification is a local issue not specifically addressed by HL7.
B.1.2   3.1.1.2 Role Element
Specification Value
Are Roles defined for each party of each business process? List them, or provide a reference to the source of these values. The Role element is optional. The ebXML processor SHALL NOT rely on its presence or contents or validate any of its values.
B.1.3   3.1.2 CPA Access
Specification Value
Is a specific registry for storing CPAs required? If so, provide details. This profile does not require the use of CPAs, and does not require a specific registry for storing CPAs.
Is there a set of predefined CPA templates that can be used to create given Parties’ CPAs? CPAs where locally used may be derived from a local base CPA to encourage consistency.
B.1.4   3.1.4 Services
Specification Value
Are Services (related groups of Actions) defined for each party of each business process? List them, or provide a reference to the source of these values. There are two allowed services:· For HL7 processing, the Service to be used is (source: [HL7 ebMS]): urn:services:HL7MessageProcessing· For ebXML reliable messaging and error messaging, the service is (source: [ISO 15000-2]): urn:oasis:names:tc:ebxml-msg:service
B.1.5   3.1.5 Action Element
Specification Value
Are Actions defined for each party to each business process? List them, or provide a reference to the source of these values. For the HL7 service, a fine-grained set of actions is defined that correspond to the HL7 interaction codes. This allows ebXML message processors to provide quality of service appropriate to the service and more efficient routing.For the ebXML service (source: [ISO 15000-2]):· Acknowledgment· MessageError
B.1.6   Appendix C: Supported Security Services
Specification Value
Which security profile(s) are used, and under what circumstances (for which Business Processes)? ebXML Messaging Security Profile 3: non-persistent authentication and non-persistent confidentiality is REQUIRED. ebXML Messaging-level persistent authentication MAY be used. At HL7 application and XML payload level, additional (persistent) security measures MAY also be applied. The latter are outside the scope of ebXML messaging processors.
B.1.7   4.1.2 Security and Management
Specification Value
What security and management policies and practices are recommended? Security policies are beyond the scope of HL7. Local jurisdiction may provide guidance or regulation on security.
B.1.8   6.6 Reliable Messaging Combinations
Specification Value
Which Reliable Messaging feature combinations are required? [Refer to Section 6.6 of Message Service Specification.] Reliable Messaging Pattern 2:· Duplication Elimination Y· AckRequested toPartyMSH Y· AckRequested nextMSH N. Reliable Messaging at the end-to-end level only based upon end-to-end retransmission.
B.2   -Technical-Level Requirements
B.2.1   2.1.3.2 ebXML with SOAP, Packaging Specification, Header Container, charset attribute
Specification Value
Is the "charset" parameter of Content-Type header necessary? If so, what is the (sub)set of allowed values? The charset parameter MUST be present and MUST have the value "UTF-8".
B.2.2   2.1.4 Payload Container
Specification Value
How many Payload Containers must be present? What is the structure and content of each container? How is each container distinguished from the others? Simple SOAP Style messages do not have a MIME Payload Container. For Multipart MIME Style messages, all messages other than standalone error messages and acknowledgments SHALL have a single payload container. In this version of the specification, the single allowed MIME type for xml payloads is application/xml, the single allowed MIME type for VBar encoded payloads is text/plain. Future versions of this specification MAY require additional functionality, such as supporting attachments containing DICOM or other multimedia data. The ebXML processor SHOULD therefore support large message sizes.
B.2.3   2.3.6 ebXML SOAP Envelope extensions #wildcard Element Content
Specification Value
Are additional namespace-qualified extension elements required? If so, specify. No.
B.2.4   2.3.7 id attribute
Specification Value
Is a unique “id” attribute required for each (or any) ebXML SOAP extension elements, for the purpose of referencing it alone in a digital signature? Unique “id” attributes SHOULD NOT be used on ebXML SOAP extension elements. This version of this specification provides no functionality that requires “id” attributes.
B.2.5   2.3.8 version attribute
Specification Value
Is a version other than "2.0" allowed or required for any extension elements? Extension elements with versions other than “2.0” SHOULD NOT be used.
B.2.6   3.1.1.1 PartyId Element
Specification Value
Should multiple PartyId elements be present in From and To elements? A single PartyId element SHOULD be present in both From and To elements.
Is the type attribute needed for each PartyId, and if so, what must it contain? The type attribute should be present and when present SHALL reflect the type of the Id provided.
B.2.7   3.1.2 CPAId Element
Specification Value
What identification scheme is used for the CPAId, and what form should it take? [If a URI, how is it constructed? Does it reference a real CPA, or is it just a symbolic identifier? See section 3.1.2 of Business-Level Requirements for repository information. Appears as CollaborationProtocolAgreement/@cpaid in CPA.] The use of a CPA is optional. When local CPA specification exist they MAY dictate a naming style.
B.2.8   3.1.3 ConversationId Element
Specification Value
What notation is used for ConversationId, and what form should it take? In queries, query continuations and query responses, the ConversationId SHOULD be used to track the ID of the query. In other messages, in the request message that starts a new ebXML conversation, the value for ConversationId SHOULD be set to the value of MessageId. This allows the responding system (which may not have a “conversation” concept) to recover the value for ConversationId from the value of the RefToMessageId element.
B.2.9   3.1.4 Service Element
Specification Value
Is there a defined "type" for Service elements? If so, what value must the type attribute contain? [Appears as Service/@type in CPA.] The “type” attribute for Service elements SHOULD NOT be used. A single Service element is provided for all HL7 communication.
B.2.10   3.1.6.2 MessageData Element, Timestamp Element
Specification Value
Must Timestamp include the 'Z' (UTC) identifier? [Also for Timestamp elements described in ebMS sections 6.3.2.2, 6.4.5, 7.3.2.] Application SHOULD include the ‘Z’ (UTC) identifier.
B.2.11   3.1.8 Description Element
Specification Value
Are one or more Message Header Description elements required? In what language(s)? Is there a convention for its contents? Description elements MAY be used for debugging purposes. ebXML message handlers MAY ignore the content of this attribute.
B.2.12   3.2.1 Reference Element
Specification Value
Is the xlink:role attribute required? What is its value? The xlink:role attribute SHOULD NOT be present. Its value and meaning is undefined in this specifications.
Are any other namespace-qualified attributes required? No other namespace-qualified attributes are required.
B.2.13   3.2.1.1 Schema Element
Specification Value
Are any Schema elements required? If so, what are their location and version attributes? Schema elements SHOULD NOT be used. All payload processing including validation is handled at application level, not at ebXML messaging level.
B.2.14   3.2.1.2 Description Element
Specification Value
Are any Description elements required? If so, what are their contents? Description elements MAY be present, but may be ignored by the ebXML Message processor. Any and all semantics or metadata about payload is application-level functionality.
B.2.15   3.2.2 Manifest Validation
Specification Value
How many Manifest elements must be present, and what must they reference? In this version of this specification, messages other than standalone acknowledgment and error messages SHALL contain a single Manifest element. All Manifest elements SHALL reference payloads transported as MIME payloads using the cid URI. Future versions of this specifications MAY reference (potentially large) payloads using other URI references.
Must a URI that cannot be resolved be reported as an error? Any URI that cannot be resolved SHALL be reported as an error.
B.2.16   4.1.5 Security Module Security Considerations
Specification Value
Are any recommendations given, with respect to protection or proper handling of MIME headers within an ebXML Message? No recommendation made.
B.2.17   4.1.4.1 Persistent Digital Signature
Specification Value
Must messages be digitally signed? [Yes, for Security Services Profiles 1, 6-21. Appears as BusinessTransactionCharacteristics/@isAuthenticated=persistent and BusinessTransactionCharacteristics/@isTamperProof=persistent in CPA] Not applicable. Persistent digital signatures are not supported in this version of this specfication.
B.2.18   4.1.1 Signature Element
Specification Value
Are additional Signature elements required, by whom, and what should they reference? Not applicable.
B.2.19   4.1.3 Signature Generation
Specification Value
What canonicalization method(s) must be applied to the data to be signed? [Recommended method is "http://www.w3.org/TR/2001/REC-xml-c14n-20010315".] Not applicable.
What canonicalization method(s) must be applied to each payload object, if different from above? Not applicable.
What signature method(s) must be applied? Not applicable.
What Certificate Authorities (issuers) are allowed or required for signing certificates? Not applicable.
Are direct-trusted (or self-signed) signing certificates allowed? Not applicable.
What certificate verification policies and procedures must be followed? Not applicable.
B.2.20   4.1.4.2 Persistent Signed Receipt
Specification Value
Is a digitally signed Acknowledgment message required? [Yes, for Security Services Profiles 7, 8, 10, 12, 14, 15, 17, 19-21. See the items beginning with Section 4.1.4.1 for specific Signature requirements. Appears as BusinessTransactionCharacteristics/@isNonRepudiationReceiptRequired=persistent in CPA.] Not applicable.
If so, what is the Acknowledgment or Receipt schema? Not applicable.
B.2.21   4.1.4.3 Non-persistent Authentication
Specification Value
Are communication channel authentication methods required? [Yes, for Security Services Profiles 2-5.] Which methods are allowed or required?[Appears as BusinessTransactionCharacteristics/@isAuthenticated=transient in CPA.] None specified in this document, locally defined.
B.2.22   4.1.4.4 Non-persistent Integrity
Specification Value
Are communication channel integrity methods required? [Yes, for Security Services Profile 4.]Which methods are allowed or required?[Appears as BusinessTransactionCharacteristics/@isTamperproof=transient in CPA.] None specified in this document, locally defined.
B.2.23   4.1.4.5 Persistent Confidentialty
Specification Value
Is selective confidentiality of elements within an ebXML Message SOAP Header required? If so, how is this to be accomplished? [Not addressed by Messaging Specification 2.0.] Not applicable.
Is payload confidentiality (encryption) required? [Yes, for Security Services Profiles 13, 14, 16, 17, 21, 22.]Which methods are allowed or required?[Appears as BusinessTransactionCharacteristics/@isConfidential=persistent in CPA.] Not applicable.
B.2.24   4.1.4.6 Non-persistent Confidentiality
Specification Value
Are communication channel confidentiality methods required? [Yes, for Security Services Profiles 3, 6, 8, 11, 12.]Which methods are allowed or required?[Appears as BusinessTransactionCharacteristics/@isConfidential=transient in CPA.] None specified in this document, locally defined.
B.2.25   4.1.4.7 Persistent Authorization
Specification Value
Are persistent authorization methods required? [Yes, for Security Services Profiles 18-21.]Which methods are allowed or required?[Appears as BusinessTransactionCharacteristics/@isAuthorizationRequired=persistent in CPA.] Not applicable.
B.2.26   4.1.4.8 Non-persistent Authorization
Specification Value
Are communication channel authorization methods required? [Yes, for Security Services Profile 2.] Which methods are allowed or required?[Appears as BusinessTransactionCharacteristics/@isAuthorizationRequired=transient in CPA.] None specified in this ndocument, locally defined.
B.2.27   4.1.4.9 Trusted Timestamp
Specification Value
Is a trusted timestamp required? [Yes, for Security Services Profiles 9-12, 15-17, 20, 21.] If so, provide details regarding its usage. Not applicable.
B.2.28   4.2.3.2.2 Error Handling Module, Errorlist Element, Error Element, codeContext attribute
Specification Value
Is an alternative codeContext used? If so, specify. An alternative codeContext SHOULD NOT be used.
B.2.29   4.2.3.2.3 errorCode attribute
Specification Value
If an alternative codeContext is used, what is its errorCode list? Not applicable.
When errors should be reported to the sending application, how should this notification be performed (e.g. using a logging mechanism or a proactive callback)? Errors SHOULD be propagated to the HL7 application layer. This allows for uniform processing of errors at the HL7 application level.
B.2.30   4.2.4.2 Identifying the Error Reporting Location
Specification Value
Should errors be reported to a URI that is different from that identified within the From element? What are the requirements for the error reporting URI and the policy for defining it? No recommendation made.
What is the policy for error reporting? No recommendation made.
B.2.31   4.3 SyncReply Module
Specification Value
Is SyncReply mode allowed, disallowed, or required, and under what circumstances? [May be process-specific.] SyncReply mode is REQUIRED.
If SyncReply mode is used, are MSH signals, business messages or both expected synchronously? [Affects setting of 6.4.7 syncReplyMode element. Appears as MessagingCharacteristics/@syncReplyMode in CPA.] All Actions of the HL7 Service SHALL be accessible in mshSignalsOnly mode, thus providing efficient synchronous acknowledgment and error messages while achieving scalability by asynchronous business responses.Specific Actions MAY also be available (using a different CPAId setting) in a signalsAndResponse mode.
B.2.32   6.2 Methods of Implementing Reliable Messaging
Specification Value
If reliable messaging is required, by which method(s) may it be implemented? [The ebXML Reliable Messaging protocol, or an alternative reliable messaging or transfer protocol.] Reliable messaging MAY be implemented via the WS Reliability protocol.
B.2.33   6.3.1.1 Reliable Messaging SOAP Header, AckRequested Element, SOAP actor attribute
Specification Value
Are point-to-point (nextMSH) MSH Acknowledgments to be requested? [Yes, for RM Combinations 1, 3, 5, 7; refer to ebMS section 6.6. Appears as MessagingCharacteristics/@ackRequested with @actor=nextMSH in CPA.] First Value: No. Second Value: Yes.
Are end-to-end (toParty) MSH Acknowledgments to be requested? [Yes, for RM Combinations 1, 2, 5, 6. Appears as MessagingCharacteristics/@ackRequested with @actor=toPartyMSH in CPA.] No recommendation made.
B.2.34   6.3.1.2 signed attribute
Specification Value
Must MSH Acknowledgments be (requested to be) signed? [Appears as MessagingCharacteristics/@ackSignatureRequested in CPA.] Not applicable.
B.2.35   6.4.1 Reliable Messaging Parameters, DuplicateElimination
Specification Value
Is elimination of duplicate messages required? [Yes, for RM Combinations 1-4. Appears as MessagingCharacteristics/@duplicateElimination in CPA.] Duplicate elimination SHALL be performed by all ebMS endpoints when requested.
What is the expected scope in time of duplicate elimination? In other words, how long should messages or message Ids be kept in persistent storage for this purpose? No recommendation made, however, this interval SHOULD be selected to accomodate the Quality of Service required, or locally specified.
B.2.36   6.4.3 Retries
Specification Value
If reliable messaging is used, how many times must an MSH attempt to redeliver an unacknowledged message? [Appears as ReliableMessaging/Retries in CPA.] No recommendation made.
B.2.37   6.4.4 RetryInterval
Specification Value
What is the minimum time a Sending MSH should wait between retries of an unacknowledged message? [Appears as ReliableMessaging/RetryInterval in CPA.] No recommendation made.
B.2.38   6.4.6 PersistDuration
Specification Value
How long must data from a reliably sent message be kept in persistent storage by a receiving MSH, for the purpose of retransmission? [Appears as ReliableMessaging/PersistDuration in CPA.] No recommendation made.
B.2.39   6.5.3 ebXML Reliable Messaging Protocol, Generating an Acknowledgment Message
Specification Value
Must a response to a received message be included with the acknowledgment of the received message, are they to be separate, or are both forms allowed? Acknowledgments are sent synchronously as standalone messages and business replies are delivered asynchronously on a separate connection with Actions offered in mshSignalsOnly mode. If a particular Service/Action is available in a signalsAndResponse mode, the Acknowledgment and the Business Response are bundled in a single synchronous reply message.
B.2.40   6.5.7 Failed Message Delivery
Specification Value
If a DeliveryFailure error message cannot be delivered successfully, how must the error message's destination party be informed of the problem? The delivery failure notification message SHALL set the severity attribute to Error. No recommendation as to how the destination party may be informed is made.
B.2.41   7 Message Status Service
Specification Value
Is the Message Status Service required for reliable and/or best-effort messaging? Message Status Services is NOT REQUIRED.
B.2.42   7.1.1 Message Status Request Message
Specification Value
If used, must Message Status Request Messages be digitally signed? Not applicable.
B.2.43   7.1.2 Message Status Response Message
Specification Value
If used, must Message Status Response Messages be digitally signed? Not applicable
B.2.44   7.1.3 Security Considerations
Specification Value
Must unauthorized Message Status Request messages be ignored, rather than responded to, due to security concerns? Not applicable.
B.2.45   8 Message Service Handler Ping Service
Specification Value
Is the Ping Service required? Ping service is NOT REQUIRED.
B.2.46   8.1 Message Service Handler Ping Message
Specification Value
If used, must Ping Messages be digitally signed? Not applicable.
B.2.47   8.2 Message Service Handler Pong Message
Specification Value
If used, must Pong Messages be digitally signed? Not applicable.
Under what circumstances must a Pong Message not be sent? Not applicable.
B.2.48   8.3 Security Considerations
Specification Value
If not supported or unauthorized, must the MSH receiving a Ping respond with an error message, or ignore it due to security concerns? No recommendation made.
B.2.49   9 MessageOrder Module
Specification Value
Is message ordering (within a Conversation) required? [If so, a once-and-only-once Reliable Messaging scheme must also be selected.] In this version of the specification, Message Ordering SHALL NOT be used.
B.2.50   10 Multi-Hop Module
Specification Value
Are any store-and-forward intermediary MSH nodes present in the message path? If an Intermediary MSH is present (e.g. to act as firewall bridge), it SHALL be fully transparent to the message Endpoints except for the addition of an Intermediate Identification property.
B.2.51   10.1 Multi-hop Reliable Messaging
Specification Value
What are the values of Retry and RetryInterval between intermediate MSH nodes? Not applicable.
B.2.52   10.1.1 AckRequested Sample
Specification Value
Must each intermediary request acknowledgment from the next MSH? Not applicable.
Must each intermediary return an Intermediate Acknowledgment Message synchronously? Not applicable.
B.2.53   10.1.3 Multi-hop Acknowledgments
Specification Value
If both intermediary (multi-hop) and endpoint acknowledgments are requested of the To Party, must they both be sent in the same message? Not applicable.
B.2.54   Appendix B.1 Communication Protocol Bindings
Specification Value
Is HTTP a required or allowed transfer protocol? (See section B.2 for specifics of this protocol.) No recommendation made.
Is HTTPS a required or allowed transfer protocol? (See section B.2 for specifics of this protocol.) No recommendation made.
Is (E)SMTP a required or allowed transfer protocol? (See section B.3 for specifics of this protocol.) No recommendation made.
Are any transfer protocols other than HTTP and SMTP allowed or required? If so, describe the protocol binding to be used. No recommendation made.
B.2.55   B2 Content Transfer Encoding
Specification Value
Is a (non-identity) content-transfer-encoding required for any of the MIME multipart entities? Content-transfer-encoding is NOT required for any MIME parts.
If other than "ebXML" what must the SOAPAction HTTP header field contain? The SOAPAction header SHALL be “ebXML”.
What additional MIME-like headers must be included among the HTTP headers? Additional MIME-like headers SHOULD NOT be included.
B.2.56   B.2.3 HTTP Response Codes
Specification Value
What client behaviors should result when 3xx, 4xx or 5xx HTTP error codes are received? MSH SHALL follow SOAP 1.1 processing rules for HTTP 5xx error codes. HTTP 3xx and 4xx SHALL be treated as errors.
B.2.57   B.2.6 Access Control
Specification Value
Which HTTP access control mechanism(s) are required or allowed? [Basic, Digest, or client certificate (the latter only if transport-layer security is used), for example. Refer to item 4.1.4.8 in Security section. Appears as AccessAuthentication elements in CPA.] No recommendation made.
B.2.58   B.2.7 Confidentiality and Transport Protocol Level Security
Specification Value
Is HTTP transport-layer encryption required?What protocol version(s)? [SSLv3, TLSv1, for example. Refer to item 4.1.4.6 in Security section.] No recommendation made.
What encryption algorithm(s) and minimum key lengths are required? No recommendation made.
What Certificate Authorities are acceptable for server certificate authentication? No recommendation made.
Are direct-trust (self-signed) server certificates allowed? No recommendation made.
Is client-side certificate-based authentication allowed or required? No recommendation made.
What client Certificate Authorities are acceptable? No recommendation made.
What certificate verification policies and procedures must be followed? No recommendation made.
B.2.59   B.3 Minimum Level of Supported Protocols
Specification Value
What is needed in addition to the ebMS minimum requirements for SMTP? No recommendation made.
B.2.60   B.3.2 Sending ebXML Messages over SMTP
Specification Value
Is any specific content-transfer-encoding required, for MIME body parts that must conform to a 7-bit data path? [Base64 or quoted-printable, for example.] No recommendation made.
If other than "ebXML" what must the SOAPAction SMTP header field contain? Not applicable.
What additional MIME headers must be included among the SMTP headers? Not applicable.
B.2.61   B.3.4 Access Control
Specification Value
What SMTP access control mechanisms are required? [Refer to item 4.1.4.8 in Security section.] Not applicable.
B.2.62   B.3.5 Confidentiality and Transport Protocol Level Security
Specification Value
Is transport-layer security required for SMTP, and what are the specifics of its use? [Refer to item 4.1.4.6 in Security section.] No recommendation made.
B.2.63   B.4 Communication Errors during Reliable Messaging
Specification Value
What communication protocol-level error recovery is required, before deferring to Reliable Messaging recovery? [For example, how many retries should occur in the case of failures in DNS, TCP connection, server errors, timeouts; and at what interval?] No recommendation made.
appnC:  New HL7 Specific Uniform Resource Names

The structure of a Uniform Resource Identifier (URI) or Uniform Resource Name (URN) is (RFC 2392):

scheme : pattern string

The scheme is a tag, which may or may not be registered, for which there is a described architecture for the pattern string. The pattern string implements or uses the scheme specific architecture to convey the scheme specific information.

C.1   HL7II URN

A new unregistered scheme is proposed to address the situation where an HL7 Instance Identifier, comprised of a root and optional extension, needs to be referenced as a single identifier.

Scheme: hl7ii this scheme name is suggested as it extends the hl7 conventional use with the "ii" specific use identifier.

Pattern String: root[:extension] this pattern allows for ready parsing of the id root and extension of the referred id

example: reference="urn:hl7ii:2.1.16.3.9.12345.2.39.3:ABC123" would refer to the Instance Identifier root="2.1.16.3.9.12345.2.39.3" extension="ABC123"

Return to top of page