What is openEHR?
openEHR stands for Open Electronic Health Records.
It was started in 1988 with the Good European Health Record (GEHR) project by Dr. Alain Maskens and Dr. Sam Heard, and they were later joined by Thomas Beale who acted as a technical architect.
Around 1995 this evolved into an official CEN standard – a European body for the standardization of goods, processes and services – and namely the TC/251 standard for Medical Informatics.
MEDrecord have been actively participating in the openEHR community since 2005. Since then, we’ve developed 3 complete openEHR based platforms and as a result we think we can call ourselves experts in this domain.
What the openEHR standard does is it describes the information model being used.
This model is based on “semantic interoperability principles.” So it focusses on the information around the patient in all facets (in other words it is a “holistic model”).
By doing this, users are able to actually get an entire picture of the patient and not just short separate and distributed parameters/messages.
In openEHR every piece of information starts with an archetype.
These archetypes can be developed using an archetype editor and a lot of shared archetypes can be found in the CKM (Clinical Knowledge manager).
So what you have are archetypes for blood pressure, weight, height etc.
They are small pieces of information. And if you need them together in for instance a BMI measurement (for this calculation you’ll need height, weight and age) openEHR requires you create a Template and that template can be managed in a template editor…
The downside
All in all, it’s a very well thought of system.
The only challenges we experienced with the system was in the area of performance. As you can image, it wasn’t optimal.
Due to the highly complex and hierarchical structure; performance always suffered. Of course, we’re still only talking about milliseconds here, it was still a fast system, but we just thought it could be better.
Improving performance was also what drove us to develop three different systems to work with openEHR. The first took us about three years to develop, the second a year, and the third one we were able to build in about eight months.
But even after three iterations, we were still not satisfied with performance and couldn’t find an alternative openEHR based platform that performed to our expectations.
What about HL7 FHIR?
FHIR pronounced “fire”, stands for Fast Healthcare Interoperability Resources.
It is a message standard for sending and retrieving clinical data and in principle it does the opposite of openEHR. The standard focuses only on (short) messages and not on an information model per se.
Let’s also explain quickly what HL7 has to do with FHIR.
The HL7 foundation holds a bunch of standards, all communication standards. It started with UN/EDIFACT fax messages (an international standard for the electronic interchange of data developed for the UN) that eventually evolved to HL7 v2.
Later this led to HL7 v3 being created and it in essence represented the v2 model in XML (This doesn’t really tell the whole story but that would take an entirely different article.)
All of these standards suffered from the Microsoft syndrome as they had to take all legacy systems into account and that was not an easy job to do (let’s say virtually impossible.)
By the end of 2010 the first platforms and websites with API’s started to show up and if I remember correctly form our talk this is exactly what Ewout Kramer took as a starting point for FHIR.
From that initial starting point the idea really (and I mean really..) got traction. All over the world the FHIR idea rapidly gained popularity. So much so in fact that it became the de facto standard.
In FHIR you have to model your data inside so called “Profiles”. Open source versions of these profiles are shared inside Simplifier and you are completely free to use them.
There’s also an open source version FHIR based backends like HAPI and for instance FhirBase. Let’s also not forget that there are also Google FHIR and even Microsoft FHIR versions – each which their own pros and cons.
How do we use FHIR together with openEHR?
Our key advantage is that we use the openEHR approach in our FHIR based backend, and on top of that we have developed easily accessible API’s with an open architecture that allows developers to more or less “hide” all this complexity.
We provide a head start for any developer wanting to make use of these systems, and this is actually well appreciated. We even provide a GUI framework that is ready to use on web (Angular) and for mobile (ReactNative).
Our MEDrecord platform is certified and checked yearly for the FHIR standard (together with ISO27001 and NEN7510) and we built it to further remove complexity and allow for the rapid development of great ideas to filter through.
How is FHIR used in healthcare?
Since FHIR became the de facto international standard, more and more governments are “forcing” software providers to open up their systems by also using the same FHIR standard.
For instance in the Netherlands this is done by Nictiz, in the UK by the NHS. Both have great examples. There are of course countless other examples that different countries are implementing as well.
Why use FHIR?
And that number of environments continues to grow.
Lets hope large industry EHR software manufacturers like Cerner and Epic will follow soon by opening up as well.
This is more a political and financial discussion than a technical one since all of them do have FHIR connectors already – The question is how much are you willing to pay for using them.
The downside
The only sad story (at least for us) is that here in the Netherlands they have opted to put ZIB (Care Building Blocks) on top of the FHIR Profiles.
By doing this we are still compliant with FHIR Profiles. However, we have to use them with additional extensions that external systems don’t have.
We are therefore not able to communicate to everything outside The Netherlands without first having to write mappers which means basically having had to start over (almost.)
If each user/country uses FHIR, or any standard, but modifies it in a similar way it kind of kills the purpose behind having an international data exchange standard in the first place.
How do Dutch Personal Health Environments use FHIR?
In The Netherlands we have chosen FHIR as the main standard in healthcare and we have a law that states that medical information belongs to the patient.
This is why so many PHE’s (Personal health Environments) have emerged. These PHE’s need to be approved by MedMij which is the authority in PHEs. At this moment there are about 36 of them.
With our MEDrecord platform we are the underlying architecture for a number of Dutch PHEs, and we offer MedSafe is as our own proprietary environment. Our goal is to enable more innovators and organizations to build tools that leverage Personal Health Data so they can empower both patients and healthcare providers in new and innovative ways.
Please check here how we are able to help startups with their own PHEs or any other healthcare innovation.