IHE based implementations
IHE-based Implementation of NHIN Direct Transactions
The purpose of this implementation specification is to demonstrate the re-use of the IHE profiles and transactions for NHIN Direct. There are three variations of the high-level specification, reflecting different capabilities of the source and destination.
XDR End-to-End Transactions
The simplest mapping of IHE transactions (conceptually, not necessarily the simplest to implement) is using the XDR transaction with deferred response (originally posted here):
|
|
| XDR end-to-end transactions |
The solid arrows represent the initiating message, the dotted arrows represent the response ACK message. The transactions from the abstract model are shown as "belonging" to a specific message, while the letters show the sequence of messages. A, B, and C represent the XDR Provide and Register Document Set request message (PnR), while D, E, and F are the deferred Provide and Register Document Set Response message (don't let the name of the messages fool you, there is no registry involved).
Benefits
- Comprehensive HIE Interoperability via NHIN Exchange is reduced to achieving compatibility between the trust models of NHIN Direct and NHIN Exchange. The metadata and protocol stack for NHIN Direct can be likely defined as a proper subset of the metadata and protocol stack of NHIN Exchange.
- This satisfies the requirement of an acknowledgment message to go from the Destination to the Source.
- Uniform technology base - SOAP-based web services for all transactions.
Note: The "chaining" of XDR messages allows for any number of intermediaries to be involved, which is important when considering the cases for Comprehensive HIE interoperability.
Drawbacks
- The Destination and the Source are required to be able to properly maintain incoming connections from the Internet.
- Without further requirements on the HISPs, this implies an "always on" model for the Source/Destination. If additional reliability requirements are imposed on the HISPs, e.g queuing and resending, this allows for intermittent connectivity.
Implementation Notes
The routing requirement based on the Intended Recipient in the XDS Metadata is not explicitly stated in the current IHE specification, but it is not prohibited in any way. Existing implementations of XDR will have to provide the deferred response capability, which is accepted for adoption by IHE and NHIN (as an option), and it should become part of existing XDR implementations very soon (next IHE Connectathon testing starts in October, and NHIN CONNECT is on a similar, if not more accelerated, time frame).
XDR/XDS/MPQ transactions
This was the original IHE Implementation Specification proposed early on (as found here). In order to allow for the Source and Destination to avoid opening server ports to the Internet, the edge transactions can be modified as follows:
|
|
| XDR/XDS/MPQ transactions |
In this case A and B are the same PnR messages as in the previous case. For A, there is a need to use a custom status for the submission (e.g. Initiated). The Destination HISP is expected to provide rudimentary XDS Registry/Repository capabilities in order to allow the Destination to issue a Multi-patient Query (MPQ) against the intended recipient information in the metadata (step C in the diagram), and then to retrieve the documents using the XDS Retrieve Document Set transaction (step D in the diagram). The completion of step D triggers step E, which is a deferred PnR response, as in the previous case. The Source HISP is expected to provide a queuing and a correlation mechanism between the PnR messages and the PnR Response messages, and upon receiving a PnR Response to change the status of the original PnR metadata from e.g. Intitated to e.g. Delivered. The Source, can poll for submission sets with a status of e.g. Delivered using MPQ queries.
Benefits
- Using XDR between the the Source HISP and the Destination HISP enables Comprehensive HIE interoperability at the HISP/NHIN node level.
- This satisfies the requirement for only outgoing transactions from the Source and Destination.
- This satisfies the requirement of an acknowledgment message to go from the Destination to the Source.
- Uniform technology base - SOAP-based web services for all transactions.
Drawbacks
- Adds infrastructure requirement to the HISPs to provide rudimentary XDS Registry (Source HISP) and XDS Repository/Registry (Destination HISP) capabilities.
- Adds extensions to XDS metadata, and XDS Stored Query/MPQ transactions:
- new metadata statuses in order to support polling for the delivery receipt
- Ability to query intended recipient
Implementation Notes
The routing requirement based on the Intended Recipient in the XDS Metadata is not explicitly stated in the current IHE specification, but it is not prohibited in any way. Existing implementations of XDR will have to provide the deferred response capability, which is accepted for adoption by IHE and NHIN (as an option), and it should become part of existing XDR implementations very soon (next IHE Connectathon testing starts in October, and NHIN CONNECT is on a similar, if not more accelerated, time frame). HISPs need to provide minimal XDS registry/repository capabilities with the enhancements described above.
XDR/XDM transactions
In order to lower the technological requirements for the Source and Destination, the edge transactions can be modified as follows:
|
|
| XDR/XDM transactions |
In this case step A is an SMTP transaction, which sends an XDM .zip archive as a single attachment. The Source HISP unpacks the .zip file and reconstitutes the XDS metadata for the XDR Provide and Register Document Set Request transaction (Step B). The destination HISP rebuilds an XDM .zip archive and stores an email message in the mailbox for the intended recipient. Since POP and IMAP work slightly differently, all the abstract model transactions are grouped in a single step, C, for this mapping - there may be a separate message to get the list of messages, and then retrieve the actual messages, but there is no requirement on how to do it. Once the XDM package is retrieved by the Destination, the Destination HISP initiates the deferred XDR Provide and Register Document Set Response message (step D). The source HISP transforms the PnR Response into an e-mail "read receipt", and makes it available via POP/IMAP for the Source to retrieve. At their leisure, the Source uses POP or IMAP to retrieve the "read receipt" (step E).
Benefits
- Using XDR between the the Source HISP and the Destination HISP enables Comprehensive HIE interoperability at the HISP/NHIN node level.
- This satisfies the requirement for only outgoing transactions from the Source and Destination.
- This satisfies the requirement of an acknowledgment message to go from the Destination to the Source - does not rely on SMTP/POP/IMAP to produce the "read receipt", which is not reliable as it requires user action at the Destination.
- Allows the use of e-mail clients at the Source and Destination
Drawbacks
- Adds infrastructure requirement to the HISPs to provide step-up and step-down transformations from XDM to XDR and vice versa.
- Non-uniform technological base: SMTP, ZIP archives, SOAP-based web services.
Implementation Notes
The routing requirement based on the Intended Recipient in the XDS Metadata is not explicitly stated in the current IHE specification, but it is not prohibited in any way. Existing implementations of XDR will have to provide the deferred response capability, which is accepted for adoption by IHE and NHIN (as an option), and it should become part of existing XDR implementations very soon (next IHE Connectathon testing starts in October, and NHIN CONNECT is on a similar, if not more accelerated, time frame). HISPs need to provide a step-up/step down capability from e-mail to SOAP-based web services and vice-versa.Note: a possible variation of this is to relax the requirement for XDM (and the associated XDS metadata) at the Source, and allow simple e-mail with attachment. Such a simplification requires out of band configuration at the Source HISP to enable the step-up to XDR with the necessary metadata.