IHE Concrete Implementation Case 4

Concrete Implementation Workgroup > IHE Implementation Development Team > 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.
 

Source HISP

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.
Address: [1]
Method: POST
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 [2]

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.
 

1. Upon a RESTful POST of a ZIP archive, the XDM REST server verifies that the archive contains an IHE XDM conformant set of files
2. 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.
3. 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.
4. 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)
Name	NHIN D Address	OID
	[[3]]	NHIN-Direct health address&1.3.6.1.4.1.21367.3100.1&ISO
Destination (aka Intended Recipient)
Name	NHIN D Address	OID
	[[4]]	NHIN-Direct health address&1.3.6.1.4.1.21367.3100.1&ISO
Patient Information
Name	ID	Address	DOB
	DEM0260200^^^&1.2.840.114350.1.13.1.1.7.3.688884.100&ISO
Destination email
	[[5]]

---

This page is part of the IHE Implementation Development Team work