XDR-SMD+haromonisation

   Andrew Berry Draft for consultation 25 November 2010 Table of contents Aligning IHE and SMD Messaging i Technical Specification i Preface v Document purpose........ v Intended audience........ v Definitions, acronyms and abbreviations........ v References and related documents........ v Conformance........ v 1 Overview 6 1.1 ................. Relevant Specifications........ 6 1.1.1 ............. Secure Message Delivery...... 6  1.1.2 ............. IHE XDS.b...... 6  1.1.3 ............. IHE XDR...... 6  1.1.4 ............. IHE XDM...... 7  1.1.5 ............. NHINDirect Direct Messaging Specification...... 7 1.2 ................. Proposed Approach and Use Cases........ 7 1.2.1 ............. Comparison of SMD and IHE XDR...... 7  1.2.2 ............. SMD Tunnel between Affinity Domains...... 8  1.2.3 ............. XDR Sender to XDM Receiver via SMD...... 8  1.2.4 ............. XDM Sender to XDS.b Repository via SMD...... 9  1.2.5 ............. SMD Sender to XDR Receiver...... 9  1.2.6 ............. Discussion...... 10  2 Specification 11 2.1 ................. Conformance........ 11 2.2 ................. Roles........ 11 2.3 ................. Identity Mapping........ 12 2.3.1 ............. Organisational Identifiers...... 12  2.3.2 ............. Individual Identifiers...... 12 2.4 ................. Payload Creation........ 13 2.5 ................. XDR Outbound Agent........ 13 2.5.1 ............. Implementation...... 13  2.5.2 ............. Addressing and Service Categories...... 13  2.5.3 ............. Invocation Behaviour...... 14 2.6 ................. XDS.b Outbound Agent........ 14 2.7 ................. XDR Inbound Agent........ 15 2.7.1 ............. Implementation...... 15  2.7.2 ............. Addressing and Service Categories...... 15  2.7.3 ............. Invocation Behaviour...... 15 2.8 ................. XDS.b Inbound Agent........ 16 2.9 ................. XDR Inbound Gateway........ 16 2.9.1 ............. Implementation...... 16  2.9.2 ............. Addressing and Service Categories...... 16  2.9.3 ............. Invocation Behaviour...... 17  2.10 XDS.b Inbound Gateway 17 Definitions 18 Shortened terms........ 18 References 19 Normative References........ 19 Related reading........ 19

This page is intentionally left blank.   This document is intended to describe a method for alignment of the Australia Technical Specification for Secure Message Delivery (ATS 5822—2010) and the key messaging standards associated with the IHE platform, specifically XDR and XDM. Further, the document defines a set of conformance points for software implementations that implement the alignment described, to provide assurance that conformant implementations will interoperate. This document is provided for consideration by Standards Australia and the IHE Technical Committee to assist in ensuring that their respective specifications are complementary.  This is a technical document. The reader is expected to have a high-level understanding of: · The IHE technical framework; · The IHE XDR and XDM specifications; · The Australian Technical Specification for Secure Message Delivery; and · SOAP web services; Explicit reference is made to relevant documentation, allowing readers to gather the necessary information required to read this document as required.  For lists of definitions, acronyms and abbreviations, see the Definitions section on page 18.  For a list of all referenced documents, see the References section on page 19.  The keywords MUST, MUST NOT , SHOULD , SHOULD NOT , and MAY in this document are to be interpreted as described in the Internet Engineering Task Force’s (IETF) Request for Comments (RFC) 2119 [RFC2119].

= =

The following subsections briefly describe the relevant specifications from Standards Australian and IHE, highlighting the key characteristics relevant for alignment.

Standards Australia has published an Australian Technical Specification for Secure Message Delivery (ATS 5822—2010) also known as "SMD". This specification defines a content-agnostic mechanism for the secure transmission of messages between software systems. Key requirements include: · Exchange of any message, including documents; · End-to-end encryption, with no visible patient or clinical data; · Support for messaging intermediaries; · Delivery confirmation; · Accommodation of common messaging business models; · Senders and receivers do not need to host web services, and need not be permanently or reliably connected. The resulting specification is very similar to the Internet email protocols SMTP and POP, but using SOAP web services and consistent payload encryption. The specification ensures that all conforming implementations can exchange messages, that is, the lowest level of conformance is sufficient to communicate with any other conforming implementation. While the specification is designed to support health care messaging, it is not restricted to health care applications. The data required for messaging is limited to routing, encryption and identification data.

The IHE XDS.b profile or Cross-enterprise Document Sharing specifies the protocol, schemas and necessary meta-data for the population and use of a clinical document repository and an associated registry. The specification defines (amongst other things) SOAP interfaces and associated schemas for various actions against a document repository and registry. Documents submitted to the repository require metadata sufficient to index the content in the registry, including identification of the patient. Since communications are point-to-point, this information can be adequately secured using SOAP encryption mechanisms or TLS. Separate content encryption is not required or specified. In order to enable the carriage of large documents, XDS.b makes use of MTOM/XOP with SOAP web services.

IHE have published a direct messaging profile known as XDR or Cross-enterprise Reliable Document Interchange. This specification re-uses the SOAP interfaces of the XDS.b profile for point-to-point messaging. As with XDS.b: · Documents are accompanied by metadata that includes identification of the patient. · Document transmission is secured by SOAP encryption mechanisms. · Interactions are document-centric. While non-document messages can be carried, the required metadata must be synthesized for messages that are not explicitly related to a patient.

IHE have also published a profile for the exchange of documents using physical and other media. This is known as XDM or Cross-enterprise Document Media Interchange. Identified media includes CD-ROM, USB flash drives and email. XDM is designed to allow for the possibility that the recipient of a document set is a human, organising the document set into folders containing documents and metadata. An XDS.b or XDR document set can be deterministically transformed into an XDM folder structure and vice-versa. Email transfer of an XDM folder structure is achieved by attaching a ZIP archive of the folder structure to an email using MIME standards. The content can be signed and encrypted using S/MIME. A system to create XDM document sets is known as a "portable media creator". A system to consume XDM document sets is known as a "portable media importer". Note that both tasks can conceivably be performed manually by a human user.

The Nationwide Health Information Network (NHIN, USA) has been established to support the nationwide exchange of health information using recognised standards. NHIN have produced a specification for direct messaging that interworks with XDR and XDS.b. The basis of their approach is the transformation of XDS.b document sets into XDM form and vice versa, with transmission of a zipped XDM archive via email being a key platform, although other messaging mechanisms are also identified. Specific transformation steps are defined and a stripped-down set of XDS.b metadata is permitted for transmission of documents from non-XDS sources.

This document proposes an approach to alignment based on the co-existence of SMD with the IHE XDR, XDS.b and XDM specifications. In this context, SMD is positioned as an additional transport mechanism for document sets formatted as XDM ZIP archives. This approach recognises the differences in requirements and also embraces the broader scope of SMD as a messaging mechanism. The following subsections illustrate the proposed approach through a series of use cases. A comparison of SMD with XDR is first presented to highlight the fundamental differences between these two apparently similar specifications.

From the descriptions in the preceding sections, it should be clear that SMD and XDR address different requirements. The following differences are particularly relevant: · SMD is fundamentally a message transport protocol, whereas XDR is a clinical document interchange protocol. As such, they exist at different levels in a protocol stack. · SMD is intended to support reliable messaging between occasionally connected participants with no server hosting capabilities, whereas XDR requires both parties to be online and the receiving party operating a web server. In SMD, messaging intermediaries are required to allow for occasionally connected participants with no web server. · SMD uses payload signing and encryption to realise end-to-end privacy and integrity, whereas XDR uses SOAP encryption mechanisms. The SOAP mechanisms cannot provide end-to-end privacy and integrity when messaging intermediaries are used. · XDR uses MTOM/XOP for efficient transmission of documents. The use of this mechanism is incompatible with the W3C standard XML encryption and signing used for SMD payloads. Convergence of these protocols cannot be achieved without compromising their respective purposes and requirements. Thus this alignment specification focuses on their co-existence and interworking.

In this case, SMD provides a secured, asynchronous messaging "tunnel" between two distinct IHE affinity domains. For example, Princess Alexandria Hospital operates an XDR conformant discharge summary application and wishes to send a discharge summary to Milton Medical Centre for their mutual patient John Jones. Milton Medical Centre also operates XDR conformant applications, but the organisations operate within distinct affinity domains and Milton Medical Centre uses a messaging intermediary because of security concerns associated with operating public-facing servers. This case is illustrated in Figure 1: 1: SMD Tunnel between Affinity Domains

In this case, an XDM portable media importer receives XDM ZIP archives from an XDR sender via SMD. For example, Princess Alexandria Hospital wishes to send a copy of the John Jones discharge summary to Dr Jack Jericho, a local orthopaedic surgeon. Dr Jericho is capable of receiving SMD messages through his messaging intermediary and importing XDM ZIP archives in his clinical desktop application, but does not operate any XDR compliant applications. This case is illustrated in Figure 2: 2: XDR Sender to XDM Receiver via SMD

In this case, an XDM portable media creator sends an XDM ZIP archive to an XDS.b repository via SMD. For example, Dr Jericho has prepared a report on John Jones for Milton Medical Centre, who operates an IHE compliant repository of clinical records for their patients. John Jones has requested that Dr Jericho send a copy of his report to the repository. Dr Jericho is able to construct an XDM ZIP archive using his desktop software and submit it for delivery to Milton Medical Centre via SMD. This case is illustrated in Figure 3: 3: XDM Sender to XDS.b Receiver via SMD

In this case, a non-IHE application sends a clinical document to an XDS.b Receiver via SMD. For example, LINQ Pathology sends a pathology result report for John Jones to Dr April Appleby at Milton Medical Centre, who requested the test. LINQ are compliant with the Standards Australia profile for HL7v2 pathology messaging but do not have any IHE capabilities. The Milton Medical Centre SMD agent, upon receipt of an SMD message containing this well-defined HL7v2 profile, generates suitable IHE metadata for the message and delivers it to the XDR-compliant clinical desktop application used by Dr Appleby. The SMD agent also generates the necessary HL7v2 application acknowledgement and sends it back to the pathology laboratory as an SMD message. This case is illustrated in Figure 4: 4: SMD Sender to XDR Receiver

The use cases above illustrate the proposed approach to alignment of IHE and SMD. It is worthwhile to highlight the features of this approach: · SMD and IHE are quite complementary: IHE addresses issues of content and interaction protocols for e-health scenarios within a trusted network (affinity domain). SMD provides a secure, reliable transport mechanism for use of IHE content and protocols through an untrusted and unreliable network. · The SMD transport mechanism addresses current IHE issues related to occasionally connected organisations, or those lacking the skill or desire to operate a web server. While a number of the use cases presented could be addressed on a small scale using email as transport, SMD has been developed specifically to address the known shortcomings of email for large scale secured communication between applications. · SMD also provides a suitable mechanism for securely transporting non-document messages between organisations, for example, HL7v2 acknowledgements. = = The following subsections specify the roles and behaviours of the key entities required to support the use cases identified in section 1. This specification is intended to capture sufficient detail to provide assurance that conformant implementations can interwork. This specification makes considerable use of other specifications to define behaviour. These are point-in-time references, so any subsequent revision of those other specifications might not be compatible with this specification. As much as possible, the current versions of those specifications are explicitly identified.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

The following roles are defined in this specificiation: · An ** XDR Outbound Agent **: this role implements the ability to send an XDR document set via the SMD transport mechanism. The recipient might be either an XDR compliant application or an XDM portable media importer. Such an implementation would fulfill the requirements of the sending SMD Agent in the use cases described in sections 1.2.2 and 1.2.3. · An ** XDS.b Outbound Agent **: this role implements the ability to send an XDS.b document set to a XDS.b repository via the SMD transport mechanism. While this capability is not required by any documented use cases, it is included for completeness. · An ** XDR Inbound Agent **: this role implements the ability to receive XDR document sets via SMD and deliver them to a local XDR application. Such an implementation would fulfill the requirements of the receiving SMD Agent in the use case described in section 1.2.2. · An ** XDS.b Inbound Agent **: this role implements the ability to receive XDS.b document sets via SMD and deliver them to a local XDM application. Such an implementation would fulfill the requirements of the receiving SMD Agent in the use case described in section 1.2.4. · An ** XDR Inbound Gateway **: this role implements the ability to receive non-IHE clinical messages via SMD, synthesize XDR metadata and deliver the resulting document set to a local XDR application. Such an implementation would fulfill the requirements of the receiving SMD Agent in the use case described in section 1.2.5. · An ** XDS.b Inbound Gateway **: this role implements the ability to receive non-IHE clinical messages via SMD, synthesize XDS.b metadata and deliver the resulting document set to a local XDS.b repository. While this capability is not required by any documented use cases, it is included for completeness. Since the capabilities of the XDR and XDS.b agents/gateways are very similar for a given direction (inbound or outbound), it is anticipated that most implementations will implement both capabilities in a single agent/gateway. Note that the capabilities required for Dr Jericho in the use cases described in sections 1.2.3 and 1.2.4 are covered by existing specifications. For the use case in section 1.2.3, Dr Jericho requires an SMD Receiver implementation as defined in [ATS 5822—2010] and a Portable Media Importer implementation, as defined in [IHE XDM]. For the use case in section 1.2.4, Dr Jericho requires an SMD Sender implementation as defined in [ATS 5822—2010] and a Portable Media Exporter implementation, as defined in [IHE XDM].

SMD messages are between organisations. As such, the identity of the organisations sending and receiving the message are mandatory. The following conformance points define the mapping of XDR identity information to SMD organisation identifiers. These conformance points apply to any role that creates an SMD message from an incoming XDR or XDS.b document set, referred to as the Outbound Agent in these conformance points. a) The Outbound Agent shall extract identifying information for the sending and receiving organisations from the metadata of each document set. [AB1]    b) If an identification authority for health care organisations exists, then: i. The Outbound Agent should use an identifier supplied by that authority to identify the sending and receiving organisations in the SMD MessageMetadata. ii. If the identifying information for the sending and receiving organisations does not include an identifier supplied by the authority, then the Outbound Agent should perform a directory lookup to obtain the identifiers for the sending and receiving organisations. c) If no identification authority for health care organisations exists, or no match for the sending and receiving organisations can be found in a relevant directory, the Outbound Agent shall use an internet domain name to identify the sending and receiving organisations. d) The Outbound Agent shall encode identifiers for organisations as qualified identifiers according to clause 2.6.2 of [ATS 5822—2010] before inclusion in the SMD MessageMetadata.

SMD messages optionally include an identifier for the sending and receiving individuals in the message metadata. This is intended for local routing within the Sender and Receiver organisations. The following conformance points define the mapping of XDR individual identity information to SMD individual identifiers. These conformance points apply to any role that creates an SMD message from an incoming XDR or XDS.b document set, referred to as the Outbound Agent in these conformance points. a) The Outbound Agent shall extract identifying information for the sending and receiving individuals from the metadata of each document set. [AB2]    b) If an identification authority for individual health care providers exists, then: i. The Outbound Agent should use an identifier supplied by that naming authority to identify the sending and receiving individuals in the SMD MessageMetadata. ii. If the identifying information for the sending and receiving individuals does not include an identifier supplied by the authority, then the Outbound Agent should perform a directory lookup to obtain the identifiers for the sending and receiving individuals. c) If no identification authority for individual health care providers exists, or no match for the sending and receiving individuals can be found in a relevant directory, the Outbound Agent shall use an email address to identify the sending and receiving organisations. d) Identifiers for individuals shall be encoded as qualified identifiers as described in clause 2.6.1 of [ATS 5822—2010] before inclusion in the SMD MessageMetadata. If email addresses are used to identify individuals, then the qualified identifier shall be a mailto:  URL.

The following payload creation conformance points apply to any role that creates an SMD message from an incoming XDR or XDS.b document set, referred to as the Outbound Agent in these conformance points.: a) The Outbound Agent shall convert the incoming document set to an XDM archive as defined in [NHINDIRECT]. b) The Outbound Agent shall include the XDM archive in the element of an SMD Message schema as defined in clause 7.3.1 of [ATS 5822—2010]. Note the implication that the XDM archive is Base-64 encoded for transmission within a SOAP body. c) The Outbound Agent shall set the sending and receiving organisation identifiers of the SMD MessageMetadata using the mappings defined in section 2.3.1. d) The Outbound Agent shall set the sending and receiving individual identifiers of the MessageMetadata using the mapping defined in section 2.3.2. e) The Outbound Agent shall set the creationTime element of the MessageMetadata by copying the ?? [AB3]  field of the XDR message.  f) The Outbound Agent shall create a SealedMessage according to [ATS 5822—2010] using the Message and SealedMessageMetadata created as described in the preceding conformance points.

The following capabilities must be implemented by an XDR Outbound Agent:  b) An XDR Outbound Agent shall implement an SMD Sender endpoint as defined in [ATS 5822—2010] for the transmission of messages containing an XDM payload.

SMD Receiver endpoints identify the types of interactions that they support through “service categories” [ELS 2010]. The intent is that service providers publish the service categories that they support in a service directory. The following conformance points relate to the use of service categories for an XDR Outbound Agent:  [] a)  above.      Note that an SMD Receiver Intermediary can publish entries in a service directory on behalf of an SMD Receiver. In this case, the interface address will identify a service offered by the SMD Receiver Intermediary, and the SMD Receiver will “pull” messages down from that intermediary rather than offering a service directly.

For each Provide and Register Document Set transaction received on its interface, the XDR Outbound Agent shall:  b) Attempt to send an SMD SealedMessage created as defined in 2.4 to an SMD Receiver endpoint identified as described in 2.3.1 and addressed as described in 2.5.2. The XDR Outbound Agent may use either a SealedMessageDelivery or a SealedImmediateMessageDelivery interface for this transmission, depending on the capabilities and preferences of the identified SMD Receiver. c) If successful in creating the SMD SealedMessage and invoking an appropriate SealedMessageDelivery interface, return a successful response to the invoker. d) If not successful in creating and sending the SMD SealedMessage, return a fault [AB4]  to the invoker. e) If an Error Transport Response to the SMD SealedMessage is subsequently received, escalate the issue to a responsible person and provide a link to the storage location of the associated document set. In addition: f) If a Successful Transport Response to an SMD SealedMessage is received, the XDR Outbound Agent may remove the associated document set from the stable storage used at a) above. g) The XDR Outbound Agent shall return a fault for any invocations of the Retrieve Document Set operation defined in its interface WSDL.

An XDS.b Outbound Agent is subject to the same conformance points as an XDR Outbound Agent except for 2.5.1a), 2.5.2a) and 2.5.2b) which are replaced with, respectively: a) An XDR Outbound Agent shall implement an IHE Document Repository interface for receipt of XDS.b document sets created as defined in [IHE XDS]. 2.3.1, and the following service category identifier: [] c) The XDS.b Outbound Agent shall set the serviceCategory field of an outbound SMD message to the service category identifier defined in  b)   above. Note that the XDS.b Outbound Agent does not support the Retrieve Documents Transaction, since this transaction requires a synchronous response containing the retrieval result. While SMD has an immediate mode (synchronous) option, it is not mandatory.

The following capabilities must be implemented by an XDR Inbound Agent: a) An XDR Inbound Agent shall implement an SMD Receiver endpoint as defined in [ATS 5822—2010] for the receipt of messages containing an XDM payload.

SMD Receiver endpoints identify the types of interactions that they support through “service categories” [ELS 2010]. The intent is that service providers publish the service categories that they support in a service directory. The following conformance points relate to the use of service categories for an XDR Inbound Agent: a) The XDR Inbound Agent should publish one or more entries in a service directory identifying an SMD Receiver endpoint for the receipt of IHE document sets, as defined in [ATS 5822—2010]. When publishing an entry identifying an SMD receiver endpoint for the receipt of IHE document sets, an XDR Inbound Agent shall:    []    c) If an identification authority for health care organisations exists, use the identifier allocated by that authority in the published service capability. d) If no identification authority for health care organisations exists, use an internet domain name that is controlled by the XDR Inbound Agent as the organisational identifier in the published service capability.      Note that an SMD Receiver Intermediary can publish entries in a service directory on behalf of an SMD Receiver. In this case, the interface address will identify a service offered by the SMD Receiver Intermediary, and the SMD Receiver will “pull” messages down from that intermediary rather than offering a service directly.

Upon receipt of an SMD Message with the service category identified in 2.7.2b), the XDR Inbound Agent shall: a) Extract the XDM archive from the message. b) Convert the XDM archive to the XML structure required for a Provide and Register Document set invocation as described in [NHINDIRECT]. c) Examine the SMD and document set metadata and identify the local service to which the document set should be delivered. d) If the extraction, conversion and addressing above is unsuccessful, send an SMD Error Transport Response to the SMD Sender with the response code:    [] CannotExtract     e) If the extraction, conversion and addressing is successful, invoke the local service to deliver the document set. f) If the invocation is successful, send an SMD Success Transport Response to the SMD Sender. g) If the invocation is unsuccessful, send an SMD Error Transport Response to the SMD Sender with the response code: [] InvokeError

An XDS.b Inbound Agent is subject to the same conformance points as an XDR Inbound Agent except for 2.7.1b) and 2.7.2b) which are replaced with, respectively: a) An XDR Inbound Agent shall implement a consumer (client) of the IHE Document Repository interface for invoking the Provide and Register Document transaction as defined in [IHE XDS.b]. b) When publishing an entry in a service directory identifying an SMD receiver endpoint for the receipt of IHE document sets, an XDR Inbound Agent shall use the service category: []

The following capabilities must be implemented by an XDR Inbound Agent: a) An XDR Inbound Gateway shall implement an SMD Receiver endpoint as defined in [ATS 5822—2010] for the receipt of messages containing a clinical document payload.   c) An XDR Inbound Gateway should implement an SMD Sender endpoint as defined in [ATS 5822—2010] to send acknowledgements required for incoming messages.

The following conformance points relate to the publication of entries in a service directory by an XDR Inbound Gateway a) The XDR Inbound Gateway should publish one or more entries in a service directory identifying an SMD Receiver endpoint for the receipt of clinical documents, as defined in [ATS 5822—2010]. When publishing an entry identifying an SMD receiver endpoint for the receipt of clinical documents, an XDR Inbound Gateway shall: b) Publish under one or more service categories that indicate the types of documents that the XDR Inbound Gateway is able to convert to an XDR document set. c) If an identification authority for health care organisations exists, use the identifier allocated by that authority in the published service capability.   d)  If no identification authority for health care organisations exists, use an internet domain name that is controlled by the XDR Inbound Agent as the organisational identifier in the published service capability. Note that an SMD Receiver Intermediary can publish entries in a service directory on behalf of an SMD Receiver. In this case, the interface address will identify a service offered by the SMD Receiver Intermediary, and the SMD Receiver will “pull” messages down from that intermediary rather than offering a service directly.

Upon receipt of an SMD Message, the XDR Inbound Gateway shall: a) Extract the clinical document from the message. b) Extract metadata from the document and synthesize the XML structure required for a Provide and Register Document set invocation as described in [NHINDIRECT]. c) Examine the message metadata and extracted document metadata to identify the local service to which the document set should be delivered. d) If the extraction is unsuccessful, send an SMD Error Transport Response to the SMD Sender with the response code: [] CannotConvert e) If the extraction is successful, invoke the identified local service to deliver the synthesized document set. f) If the invocation is successful, send an SMD Success Transport Response to the SMD Sender. g) If the invocation is unsuccessful, send an SMD Error Transport Response to the SMD Sender with the response code:   [] InvokeError  h) If the clinical document format requires one or more explicit acknowledgements (e.g. HL7v2), the XDR Inbound Gateway should synthesize suitable acknowledgements and send them back to the organisation that sent the document as a distinct SMD message.

An XDS.b Inbound Gateway is subject to the same conformance points as an XDR Inbound Gateway except for 2.9.1b) which is replaced with: a) An XDR Inbound Agent shall implement a consumer (client) of the IHE Document Repository interface for invoking the Provide and Register Document transaction as defined in [IHE XDS.b].

 This section explains the terminology used in this document.  This table lists abbreviations and acronyms in alphabetical order.
 * ** Term ** || ** Description ** ||
 * || IHE Cross-enterprise Reliable Document Interchange ||
 * XDS.b || IHE Cross-enterprise Document Sharing ||
 * XDM || IHE Cross-enterprise Document Media Interchange ||
 * HL7 || Health Level 7 ||
 * RFC || Request for Comments ||
 * SMD || Secure Message Delivery ||
 * XML || Extensible Markup Language ||

   The following referenced documents are indispensable for the application of this document. Only the version cited applies. 1997 || http://ietf.org/rfc/rfc2119.txt || 2010 || [] || 25 Nov 2010 || http://wiki.directproject.org/XDR+and+XDM+for+Direct+Messaging ||  The documents listed below may provide further information about the issues discussed in this document. 2010 || http://www.e-health.standards.org.au/Home/Publications.aspx || 2010 || [] || 2010 || [] ||
 * ** Reference Documents ** ||
 * [REF] || Document Name || Publisher || Link ||
 * [RFC2119] || RFC 2119: Keywords for use in RFCs to Indicate Requirement Levels || IETF
 * [ATS 5822—2010] || Australian Technical Specification - E-Health Secure Message Delivery || Standards Australia
 * [IHE XDR] || || || ||
 * [IHE XDS] || || || ||
 * [IHE XDM] || || ||  [AB5]   ||
 * [NHINDIRECT] || XDR and XDM for Direct Messaging || NHINDirect
 * ** Related Documents ** ||
 * [REF] || Document Name || Publisher || Link ||
 * || Australian Technical Specification - E-Health Web Services Profiles || Standards Australia
 * [ATS 5821—2010] || Australian Technical Specification – E-Health XML Secured Payload Profiles || Standards Australia
 * [TR 5823—2010] || Technical Report - Endpoint Location Service. || Standards Australia

[AB1] Should identify specific fields, if possible. [AB2] Should identify specific fields, if possible. [AB3] To be determined. [AB4] Need to be more specific here [AB5] Would like someone to supply correct references. Particularly for XDR, I have trouble working out which document to reference.