IHE Implementation

IHE Implementation

Overview

This is the specification description for the second variation of the IHE based implementations under discussion by the IHE Implementation Development Team. This document suggests a mapping of the current IHE XDS, XDR and XCA transactions as expressed in the NwHIN Specifications onto the associated Direct Project Abstract Model. The overarching theme of this mapping is the use of currently existing and widely understood Internet technologies/services/standards.

Direct Project Message

• XDSSumbmissionSet defined by XDSDocumentEntry entries, packaged with MTOM encoding.

Direct Project Source Edge Protocol

• SOAP over TLS (HTTPS).

Direct Project Destination Edge Protocol

• SOAP over TLS (HTTPS)

Direct Project Provider Address

• A mapping from a provider address URN to a SOAP endpoint

Direct Project Certificate Directory

• NwHIN UDDI or DNS CERT RR

Direct Project HISP Address Directory

• NwHIN UDDI query by intendedRecipient's Health Domain Name or mapping from URN to URI providing a WSDL through lookup from intendedRecipient's Health Domain Name

Direct Project Backbone Protocol

• HTTP over TLS with a SOAP API.

Synopsis

Area	Transaction	Payload	Notes
Source to HISP	Provide and Register Document Set (XDR) + Update Document Set to change status metadata	XDS metadata + MTOM
HISP to HISP	Provide and Register Document Set (XDR)	XDS metadata + MTOM
Destination to HISP	Registry Stored Query + Retrieve Document + Update Document Set	XDS metadata + MTOM	Requires modification to XDS metadata to support

Source to HISP

Transaction 1.1: Source authenticates to HISP

• Source and HISP must support, at a minimum, WS-Security with basic password combined with TLS and mutual authentication.

Transaction 1.2: Source sends Direct Project Message to HISP

• Source creates XDS metadata (XDSSubmissionSet and XDSDocumentEntry entries for each associated document) and MTOM-encodes each message component. The XDSSubmissionSet intendedRecipient metadata holds the To address.
• Source packages XDS metadata and message components in a Provide and Register Document Set SOAP transaction with WS-Security headers as documented above

Transaction 1.3: Source receives message status information

• Registry Stored Query to query document metadata.
• NOTE: This implies a modification of Registry Stored Query to support mailboxing by intendedRecipient and status metadata supporting NEW/ACK/NACK semantics

HISP to HISP

Transaction 2.1: Source HISP authenticates to destination HISP

• WS-Security with SAML tokens combined with TLS and mutual authentication.

Transaction 2.2: Source HISP sends Direct Project Message to destination HISP

• The sending HISP reads the associated provider Health Domain Name from the XDSSubmissionSet metadata and looks up the destination HISP SOAP endpoints via UDDI or via mapping from URN to URL providing a WSDL. The sending HISP then composes the Provide and Register Document Set transaction with the same metadata and data as the originating transaction.

Transaction 2.3: Source HISP receives message status from destination HISP

• Update Document Set transaction to alter status metadata

HISP to Destination

Transaction 3.1: Destination authenticates to HISP

• Source and HISP must support, at a minimum, WS-Security with basic password combined with TLS and mutual authentication.

Transaction 3.2: Destination lists available Direct Project Messages from HISP

• Registry Stored Query to query metadata corresponding to the indendedRecipient's inbox.
• NOTE: this orchestration implies some significant changes to XDS/XDR to support these use cases. As it stands, Registry Stored Query is not an appropriate transaction to search for new messages sent to the provider, XDS Metadata does not suppor this use case, and XDR typically would not create document metadata in any case. NAV is an option but NAV only sends an email pointer to the document, which must be downloaded separately (via Retrieve Document Set).
• Alternative would be to send the XDR content (metadata and documents) using XDM over email. This would have all the power of SMTP (acknowledgements etc.) but use the same metadata coding as XDR so could be converted very easily. All the above concerns raised when considering query/retrieve as a mechanism for this transaction go away. This part of the transaction becomes the same as SMTP list, and Transaction 3.3 is a read of SMTP messages with zip attachment.

Transaction 3.3: Destination downloads Direct Project Message from HISP

• Retrieve Document Set

Transaction 3.4: Destination updates message status with the HISP

• Update Document Set transaction to alter status metadata.
• NOTE: this orchestration implies some significant changes to XDS/XDR to support these use cases. As it stands, Registry Stored Query is not an appropriate transaction to search for new messages sent to the provider, and XDR typically would not create document metadata in any case. NAV is an option but NAV only sends an email pointer to the document, which must be downloaded separately (via Retrieve Document Set). Use of NAV would imply using the SMTP Implementation semantics for message status.