IHE, FHIR or openEHR?
all depends on where you are going
Introduction
The choices of which interoperability technologies to use are driven be very human motivations. None of these technologies are easy and it takes time and effort to get to grips with them. Investment of such resources often gives rise to preferences: you like to use what you know. The truth of the matter is, each of the three main interoperability approaches all have their strengths and weaknesses.
At some point I would like to do an in depth analysis of the mathematical appropriateness of each of the three standards - but this is a long piece of work, and remains in my wish list in my Blue Sky Thinking.
The links below will take you to a more in-depth look at the pros and cons of FHIR, IHE amd openEHR. The following sections give an outline of the relative merits of the three main healthcare interoperability standards.
Of course, all three of these standards are still evolving. IHE and FHIR have explicit agreements to work together. The whole principle of the IHE is to re-use existing standards wherever possible (IHE incorporates us of HL7 and the DICOM imaging standard). For sure the next few years will see a convergence of these technologies: the "interoperability of interoperability".
IHE - The Network Approach
If you want to build a network and have a Vendor Neutral approach to who can join the network, then IHE is for you. It brings the advantages that it deals with structured blobs (like CDAs or FHIR payloads of data and unstructured (like pdfs). It is a 'publish subscribe' model that also has a structured way to build vendor neutral workflows (if the vendors will play ball). And it brings an explicit privacy and consent model, that enables the network rather than the applications to take control of data flows. But XDS is clumsy when it comes to detailed use of data elements, and uses an older Web Based API technology called SOAP (SOAP has an extra message that needs to be implemented to make it work - but then this is part of the publish subscribe approach. Importantly, IHE now uses FHIR messaging n parts of the standard - and IHE and HL7org have signed a collaborative agreement to work on convergence and mutual use of the two standards over the coming years.
Large EPR companies can be resistant to the Vendor Neutral Network approach, and instead prefer a systems integration approach. This means the systems themselves control the granular data elements and who can access them (and share only what is necessary to share). Concepts such as a network wide Audit, or a network wide Privacy/Consent model, embodied in the IHE approach, do not figure highly in the systems approach.
FHIR - The Systems Approach
If you have a Systems approach to building interoperability then you will lean towards FHIR. FHIR is specifically designed for fast and easy systems integration. If uses the more modern RESTful web API interface and is well aligned with the systems integration experience in large companies and NHS-Digital. It also keeps Privacy/Consent and Workflow inside the systems/applications - meaning these applications can carry more value as they manage this tricky area.
The real technical advantage of FHIR is that you can easily access structured data and share structured data. But this requires agreement between the vendors of the systems. This agreement can be hard to achieve. However, as a stratategy, NHS Digital and NHS England are busy defining the UK / NHS specific flavour of FHIR for everyone to work with and enforcing these UK standards. Healthcare systems suppliers cannot sell in the UK unless they sign up to deliver the NHS CareConnect Interfaces. The development of the CareConnect interfaces is handled by INTERopen.
The disadvantages of FHIR are in "herding the suppliers together" to play ball (and follow the CareConnect APIs). And, technically, no central index, no workflow tools. These, together with privacy/consent, have to be managed by the systems/applications.
openEHR - The Data Approach
If you have a data driven approach, and you have the appetite to develop and manage your own systems, there is a ground up healthcare data management paradigm called openEHR. It is very much seen as an outlier in the UK because it requires strong ownership from the implementing organisations. Not many UK Healthcare Providers have the capacity to build the required strong technical team. It is implemented in Slovenia, Moscow and rumor has it that Brazil will now start to use this technology nationally. In the UK, the 100,000 genome project uses this as an information data source for healthcare information to support the 100,000 genome project in at least 2 locations. Every data element (and groupings of data elements, and groupings of groupings ..) is defined and added to the growing international templates. A hierarchical structure is produced, and APIs can give access to any data element or group. It is the 'holy grail' of interoperability, BUT the hardest to make the suppliers play ball. Every healthcare systems provider has considerable IP locked up in the way they manage data. Also, there is no central index, and no privacy and consent model built in. Also there is no workflow part to this standard (though work on this is starting).
IHE XDS XCA
Taking a federated approach to link structured and unstructured healthcare information. This international standard is for those wanting to implement a vendor neutral network.
FHIR
Easy to implement for engineers, fast development linking systems can be acheived - it is also strongly favoured by the NHS.
openEHR
Clinical data modelling: information strcutured for interoperability for building systems from the ground up.