Introduction

The IHE ( Integrating the Healthcare Enterprise ) grew out of initiatives within the healthcare imaging world in Radiology. Within radiology, a combination of HL7 and the imaging standard DICOM have successfully empowered imaging organisations to work in a vendor neutral environment - interoperably sharing radiology images and reports.

Developments and other integrations led parts of the DICOM and HL7 organisations to develop web services version for the communications protocols, and to define a generic Healthcare Enterprise set of working methods between the various healthcare systems or actors.

It is a well established standard having been around since the late 1990's. Therein lies one of its weaknesses, being based on SOAP interactions rather than RESTful. The main thing to be said about IHE is that it is Document, or blob-of-data, focused and can deal with both structured and unstructured documents/data. It works on a publish/subscribe basis (google-like) and has patient privacy/consent baked in.

The elements of IHE XDS that make it so powerful are the way it deconstructs the world of interoperability into various actors and ascribes roles to those actors and their rules of interaction (called profiles in the IHE world). This deconstruction is very logical, and allows participating systems to work together in a web-services oriented manner. The three key features are

• Working in the context of a normalised patient ID
• A central Index or Registry
• Patient Privacy and Consent management

The advantages of XDS are;

1. The Network approach is a very powerful way to federate data from different sources.
2. The Central Index (the main tool for federating the information) is a central structure in the "publish/subscribe" paradigm.
3. Publishing on a wide or regional basis means you must consider privacy and consent. IHE has tools to implement a regional privacy/consent model.
4. Can deal with structured and unstructured data. This is very practical given the 'forms' and document based nature of many healthcare records today.
5. Because it follows the pub/sub model, it is possible to build workflows on top of this, and IHE include workflow tools.

The weaknesses of IHE XDS stem from the technology and times when it emerged. IHE started before RESTful web services came of age.

The best discussion I have seen on the relative merits or otherwise of SOAP and REST can be found here : I won't discuss it more here, except to say that in a way it's not so relevant to the end result - sharing data securely over the web.

The weaknesses of IHE are;

1. The Document based model can make it hard to access structured data ements within a document (even when they are contained in a CDA or similar). Solutions depend on a common understanding of the interpretation of the document objects. This takes a whole level of coordination over and above the simple messaging connectivity.
2. IHE is based on SOAP rather than REST as a web services technology. It's a little more clunky.
3. The XML.b basis of the standards profiles and messaging can quickly become large and unwieldy.