FHIR vs OpenEHR — Part 2
About a year ago I wrote a post on FHIR vs Open EHR. Looking back one year later I think most of what I said still stands up but there a few things I have observed having spent a bit more time working with FHIR and looking further into OpenEHR.
In terms of the design philosophy it is important to note they are fundamentally different. OpenEHR has been designed to model clinical information, while FHIR has been designed to exchange information. This is not to say you can’t use either standard to implement both patterns and I have seen several use cases where FHIR has been used very successfully for both, but like all things your case will shape what the correct decision is.
CareConnect
What is more clear however is that the NHS have selected FHIR as the standard they want to adopt for exchanging information and they have worked closely with InterOpen in developing the CareConnect APIs to support this approach.
For anyone not familiar with CareConnect it has been specifically designed to open up information and data held across different clinical care settings. The CareConnect open APIs will use nationally defined FHIR resources and are a method of transferring records from a source to a recipient.
A CareConnect record will contain metadata (e.g patient, location), written statements about the care provided (e.g diagnosis, medications, procedures, allergies) and coded entries (e.g medication, diagnosis, procedure). When combined with other capabilities CareConnect Open APIs will enable clinicians in one care setting to view records from across other care settings (e.g. a clinician in A&E accessing a patient’s medical record from an out of area service).
The NHS is now starting to mandate the adoption of CareConnect so this is happening now and it is very much real. By 31st December 2018, all organisations will be required to have implemented the text and CareConnect profiles specified by CareConnect at a minimum. Where care setting specific specifications exist then organisations will be expected to have implemented these specifications by the relevant date. An example of this is Transfer of Care (used for sending clinic letters and discharge summaries to GPs). CDA has now been deprecated for Transfer of Care and from October 2018 organisations need to have in place a plan to adopt the nationally published FHIR profiles, which are based on the CareConnect APIs.
So, its quite simple. If you want to exchange information within the NHS you need to be using FHIR, and specifically CareConnect Profiles. If you are not using FHIR you wont be exchanging information for very long, regardless of how or where the data is actually stored.
CareConnect and OpenEHR
This then has a very direct impact on OpenEHR within the NHS. Simply put, if you are using OpenEHR in the NHS you need to ensure your Open EHR Archetypes are tightly integrated with the CareConnect FHIR APIs or your system will not be compliant (unless of course your system doesn’t need to interoperate, which of course is not the future). This is an area that needs further development especially by the OpenEHR community within the NHS. Given OpenEHR is a standard that represents the maximum dataset and FHIR is a standard that represents the 80/20 rule care must be taken to avoid the problems associated with leaky abstraction. Perhaps only a subset of the OpenEHR data needs to be exchanged and FHIR will be an efficient way to do so, but what if your use case is more complex and you end up with a complex set of extended FHIR resources mapped to an even bigger set of OpenEHR Archetypes and Templates?
CareConnect and FHIR
On the other side of the fence CareConnect will have its own FHIR based challenges going forward as well. Currently it is based on the STU3 version of FHIR. At the time of writing this may be the most up to date version of FHIR, but work is already underway for FHIR version 4 and beyond. Having worked with FHIR for a number of years now I have seen first hand the challenges of upgrading between FHIR versions. Going forward NHS Digital and InterOpen will have to carefully consider when and how they upgrade. HL7 also have a significant role to play here as well. Finding a way to make it easier to migrate between FHIR versions will be important, but also pushing more key resources to Normative more quickly and reducing the number of breaking changes for the remainder, especially those used by CareConnect, will help to minimise the impact for many.
In summary, we have two great standards, both unique and different in certain ways. However, I think much work is still needed to get further clarity on how they will both work together. In the NHS I could see a future of FHIR without OpenEHR, but I cannot see a future of OpenEHR without FHIR.
