FHIR vs OpenEHR
Today I attended an event on the NHS and openEHR, hosted by Salford Royal NHS Foundation Trust. It was a great event with lots of interesting and inspiring stories about how people are combining innovation and open standards to help enable the delivery of better care to patients. As someone who has been working with FHIR for a number years to help solve similar problems I was interested to learn more about openEHR, how people are using it and also how it aligns with FHIR.
Clearly one day at an event does not make me an openEHR expert and this piece is by no means exhaustive, but there were a couple of observations I felt are worth sharing.
Firstly, both FHIR and openEHR are open standards maintained by HL7 and the openEHR foundation respectively. Both have open standards, data and interoperability at heart and while there are large areas of overlap both seem to be designed to solve slightly different problems. FHIR is optimised for the exchange of data through the provision of simple and easy to use REST API’s. The basic building block of FHIR is a resource. There are around 100 resources and they while they can be used for a variety of purposes they are typically used to exchange clinical content such as encounters, care plans and diagnostic orders etc. People implementing a FHIR based solution can choose to implement data persistence centred around these resources using a database of their choice but it is not a core principle behind the standard .
On the other hand openEHR is optimised to provide a data platform with a stronger focus on the persistence of data, with APIs and data exchange a secondary focus. In contrast to FHIR resources, openEHR uses over 300 more complex Archetypes which are designed to provide a maximal set of data elements. This breadth and depth inevitably brings a level of complexity, especially when compared to FHIR which is optimised for the simpler “80/20” rule, with the option to extend where required. There are clearly pros and cons to both approaches and the best approach will depend on the problem you are trying to solve.
A number of stories during the Salford event focused on people building systems of record from scratch using openEHR as the core data platform. For this problem, I think this is a sensible approach, but in a bi-modal world where all the innovation is happening in the system of engagement, adopting FHIR as a standard is the better choice. The simplicity of the API’s and the provision of a simpler data model provides a better foundation to quickly build patient centred applications that support the easy exchange of data.
There has been some discussion about how to combine both FHIR and openEHR in a bid to maximise the best of both worlds. My guess is this will not happen and what we will see is both standards maturing independently with openEHR extending beyond a data platform to being more API focused and likewise FHIR continuing to mature its resource model through ongoing implementer and clinical feedback.
Regardless of whether the future is FHIR or openEHR, or a combination of both(likely), the great thing is that the future is open standards and open data (appropriately secured and governed by appropriate patient consent). The absence of this is the single biggest problem the NHS has today when it comes to interoperability. The tide is turning but there are still too many “closed” suppliers that are making interoperability too hard and whether they like it or not they are stifling the ability of the innovator to provide solutions that can transform how care is delivered. Lets crusade towards changing this first. I’m happy to argue over the standard second.
