In this complex and difficult digital health and care domain one thing that I keep seeing surfaced occurs when people first come across openEHR
“What,” they ask, “is openEHR?” and, “Where can I download it?”
Well, unfortunately, it is not quite that simple.
Elevator pitches
I have had this conversation a few times with colleagues:
“How do we explain openEHR (“openAir”) to technically naïve people such that in the 2 minutes in the lift they leave with enough understanding to influence their thinking in the future?”
This is my attempt to do this, although at around a thousand words we will have to accept the lift is in a very tall building and quite slow moving!
So, what is it?
“openEHR is a set of technologies that provides the electronic health record component on a digital health and care platform architecture.”
Phew.
We are already in the weeds. Maybe we need to break it down a bit more.
Digital health and care platform architecture
A ‘platform architecture’ is a bit like a shelf. A shelf is a kind of platform, right? You can put things on the shelf, they get supported and kept in place by it. You can put things underneath your shelf, then you know where to find them. The shelf itself needs to have the right shape, be made of the right stuff, size and fixings for the things on it and below it.
It’s a block diagram of a platform architecture for health and care systems, with new apps on top being delivered via a platform service function, platform based components and interop with existing apps below.
In our ‘digital health and care’ world the ‘shelf’ is made of software components. On the shelf are the applications that use these service components for new software, and underneath it are the existing health & care applications (and their data) that we need to talk to. The components would include useful re-usable things like how to find a patient, how to authorise users, how to run applications safely and how to store records. That record storage component is where openEHR sits.
Electronic health record
An ‘electronic health record’ is more than just a form on a screen or a database. EHRs should meet designs that reflect the clinical and care processes, where we assess a patient, examine and do tests, make a plan, enact the plan and then re-assess the patient. The cycle of care. EHRs need to support clinical audit trials, being able to show the changes in the record over time, both for medico-legal purposes and for understanding and learning about the care process. They need to allow users to store specific types of data, like numbers and text, ratios and clinical codes, and these need to be put together in ways that reflect the clinical and care data used in everyday practice. Every record has to be about a patient, and by a clinician who makes the record. The records are sensitive and must be kept securely.
openEHR provides for all of that.
Set of technologies
The ‘set of technologies’ includes a bunch of blueprints for putting together an openEHR service for your platform — the specifications. This ‘service’ is sometimes referred to as a Clinical or Care Data Repository (CDR).
It includes a set of definitions or ‘models’ that can be used in the EHR to record clinical and care concepts like height, temperature and care plans. These can be brought together in different ways to meet the multitude of different use cases in health and care but, crucially, without changing the meaning or definition every time. Once it is a systolic blood pressure, it is always a systolic blood pressure, no matter where it is measured, stored or used.
Lastly it includes an online community, a type of commons, where the specifications, the models and the use of these technologies is debated, discovered and agreed.
So, er, that is what it is. Not quite 2 minutes, and maybe not entirely for the technically naïve. Maybe the pitch is in a space elevator! If you want to hang on and go back to Earth, there is some more to say.
What is it not?
It is not an application. I am afraid you cannot, then, download ‘openEHR.exe’ and install it on your laptop. (Expecting someone will tell me I am wrong about this!)
It is not (always) free. Although the specifications, the models and the community operate under open source vibes, actually building software that can be deployed on your platform as the EHR service is what engineers like to call ‘non-trivial’. This is simply a euphemism for ‘very difficult’. Consequently various software companies have built implementations of openEHR for you, some of which are proprietary and some open source. In particular EHRbase from Vitagroup is becoming the reference open source implementation, but the ‘open’ in openEHR does not always mean free “as in beer”.
It is not a database. In fact it is pretty neutral to the underlying database used (as it does need a database!), although implementations may be designed to operate on top of some particular relational database system, like PostgreSQL or MongoDB for example. (Although HM on X/Twitter clarifies “MongoDB is not a relational database system. It is a NoSQL, document-oriented database” — thanks!)
It is not an interoperability technology, as such. That means it is not primarily a way of moving data about between disparate systems. It can be used for this, but other technologies like FHIR are probably better choices. On the other hand, if you store your data in an openEHR CDR you can run lots of applications using it, thus reducing or even eliminating the need to move stuff about in the first place, and it is fairly easy to share that data to other openEHR CDRs.
It is not a ‘clinical terminology’ like, say, SNOMED CT. You can and should use terminologies in the models, but these are generally things outside of openEHR.
It does not provide a user interface or forms definition. The openEHR data definitions for use cases, which are called ‘templates’, can look like forms for this purpose, but they are not. That said, developers can make use of the code that underlies the templates to build applications, and forms, more efficiently.
Lastly, and this may be evolving into a bit of a theme for this blog, it is not particularly simple. It is actually difficult to simplify what is a complex domain, the domain of health and care, and express it in another complex domain, that of software engineering. That does take a bit of effort.
That can make it challenging to learn and understand how it works, but I hope that as the concepts and approach settle into your head you may be surprised at how elegant and logical the approach is and why, right now, openEHR is the best choice for the EHR component on your Health and Care Digital Platform.
Ground floor
Thanks for the chat and depending on how it has gone you may or may not want to share a lift with me again!
Did that pitch help? I expect that, like so many things, it will need some ongoing refinement. Maybe we could use the commons for that too.
Leave a Reply