IHE Concrete Implementation Case 4
Provider to Provider
This case represents the communications between two providers with minimal IT capabilities
The roles will be played by IBM (Source), GE and Vangent (Source HISP), Medallies (Destination HISP) and an e-mail client as the Destination.
IBM provides a Web app to create XDM package; GE provides a RESTful service to receive an XDM .zip archive, and provide the Source HISP with an XDM to XDR conversion capability. Vangent will take the XDR package and send it to MedAllies, who will convert XDR to XDM.
The Source HISP uses a REST endpoint designed to convert an XDM payload to one or more IHE Provide and Register transactions to the Destination HISP playign the role of an IHE Document Recipient.
REST XDM Adapter
REST XDM Demonstration Endpoint
Note: This endpoint will be live for a limited time during the NHIN Connect evaluation period.
Content-Type: Accepts either application/octet-stream or application/zip
HTTP Status = 200 means Source HISP has accepted the NHIN Direct message.
The log for REST/XDM to XDR Converter piece of Source HISP are at 
REST XDM Adapter Implementation Notes
While most of the pieces of the Provider to Provider demo scenario are based on IHE capabilities of existing commerical products, the REST XDM capability of the Source HISP is something new the team had to create for demonstrating how a vanilla IHE XDR HISP could easily support other modes of submission. This demo implementation is written in Java and uses the open source OpenHealthTools (OHT) IHE Profiles 1.1.0 and Reslet Framework 1.1 frameworks.
- Upon a RESTful POST of a ZIP archive, the XDM REST server verifies that the archive contains an IHE XDM conformant set of files
- For each XDM SubmissionSet inside the archive, the METADATA.XML file is read and transformed using OHT toolkit to an XDR Provider And Register Document Set transaction (same as XDS). This is trivial as the metadata for XDM, XDR and XDS all share the same structure.
- A separate Provide And Register Document Set transaction is conducted internally to the Source HISP's XDR endpoint. Note that this 'internal hop' is communication between the REST XDM Adapter and the rest of the Source HISP demo implementation and could be implemented in non-standard ways. But one of the goals of this demonstration was to show how easy it is to add an XDM via REST capability to an existing IHE XDR Document Recipient implementation so this implementation is merely illustrative, not prescriptive of how production IHE Source HISP implementations should be created.
- Finally the REST XDM Adapter responds with an HTTP Success 200 status code if the internal XDR endpoint returns an ebXML Success status, otherwise a 500 status code is returned indicating that the Source HISP did not accept the submission via REST.
Test DataIn order to test this implementation, we will use the following data
|Source (aka authorPerson)
||NHIN D Address
||NHIN-Direct health address&188.8.131.52.4.1.21367.3100.1&ISO
|Destination (aka Intended Recipient)
||NHIN D Address
|NHIN-Direct health address&184.108.40.206.4.1.21367.3100.1&ISO
This page is part of the IHE Implementation Development Team work