I’ve written before about openEHR and how I think its time has come. I been talking to lots of people about openEHR and it’s clear it takes a while to really understand its power – It took me 15 years. In this blog I try and summarise what I think makes it different and special. If you are new to openEHR I suggest you read this first and then go to my previous blog and openEHR.org for more detail.
OpenEHR is not a piece of software it’s an open specification from which software can be built. It has it roots as a way of creating electronic health records, but can be used to build records across the whole of the health and social care domain.
Its key benefits are:
- It enables those designing systems to work at the information level rather than at the level of a particular technology separating
- “content” – the domain of the clinician or social care professional
- from “technical infrastructure” – the domain of the software engineer
- enabling both to concentrate on their own domain without needing to worry about the complexity of the other.
- It’s independent of any particular vendor or technology – There are multiple implementations from a number of vendors, built on various technologies, including open source options.
- There is a vibrant global openEHR clinical community creating archetypes (the building blocks of openEHR), which are generally “open source” and can thus be freely shared, used and adapted. See Wooland’s Cat for more on this
- There is an active vendor community which supports the clinical content development and a number of examples of implementation at scale, mainly outside the UK where it was invented!
- The specifications are amazingly rich. There is very little than its creators have not covered including:
- Interoperability, openEHR makes it easier to achieve interoperability than not.
- Multilingual support and language independence
- Federated multi-vendor implementations, with cross vendor querying
- Complex access control capabilities
- Intermittently connected devices
- Versioning and backward comparability
- Privacy protection and consent management
- Terminology bindings
However, the most remarkable and powerful feature of openEHR is its ability to support new requirements with minimal changes to systems. To support a new requirement it is simply necessary to create new archetypes. These will be immediately deployable, storable and queryable; will not require any database schema changes, won’t affect parts of the system not connected with the new requirement and won’t break anything – This means that new requirements can often be deployed in hours rather than months. Let me explain further:
New requirements generally mean new information has to be collected and stored. Anybody, who has worked at the database level will know how problematic this can be. You have to modify the database schema, modify existing tables, maybe create new ones and then migrate data from the old schema to the new. In a database of any complexity it’s easy to break things and can require the rework of lots of software unconnected with the new requirement. While modern databases have tools that can help developers avoid schema changes like the plague and when they do consider them, the rework and testing required means that changes will be expensive and slow if they happen at all often leaving people with no recourse than another Feral System
Supporting new models of care means being able to meet new requirements 10 – 100 faster, by utilising openEHR’s ability to incorporate changes simply by creating new archetypes, the large preexisting set of open source archetypes, its openAPIs we can now achieve this.
If you not looked an openEHR already then I suggest you do and if you loked at it a while ago I suggest you look again.
This video produced by Dr Wai Keong Wong (@ )provides a useful introduction to openEHR