It is just over ten years since Marc Andreesen wrote his famous piece, Why Software is Eating the World? He reflected on how more and more businesses and industries were being run on software and delivered online. He predicted that new software companies would disrupt more industries through innovative new software over the next ten years. Ten years later, it is fair to say he was right — with perhaps more disruption (and more challenges) than he predicted.
However, within healthcare, it has been a case of “Gradually, then Suddenly” — with little innovation or disruption for years, until COVID-19 came along and necessity became the mother of invention. Over the past 18 months, I have been directly involved in supporting a small part of the NHS’s response to COVID-19 through Kainos’ work on remote consultations and the services they delivered for COVID-19 Testing, Contact Tracing and Vaccinations. I have seen first-hand how innovation has been ignited, processes have been optimised, and hurdles have been safely removed. Things that used to take months were completed in weeks, sometimes days. There will be many elements to maintaining this innovative approach and there is one foundational piece that I believe will play a crucial role.
openEHR and healthcare (Pronounced “open-air”)
More healthcare systems are turning to openEHR — from individual hospitals to regions to entire countries. I believe we are at a similar junction now with healthcare and openEHR as we were with software in 2011. But, just as with software then, we can see that the tide is turning, momentum is growing, and disruption is coming. Over the next ten years, I expect many more healthcare systems to separate their applications from their data, putting openEHR at the centre of their architecture. Doing so will allow them to establish entire ecosystems of disruptive and innovative services centred around the patient.
Why is this happening?
Because openEHR will make healthcare integration obsolete, accelerating digital transformation.
Most software applications, including those in healthcare, have app-centric architectures, where the data for the app is stored as an integrated part of the application, each responsible for storing, protecting, auditing and sharing the data for their app. However, within any healthcare system there is never just one application. This means we typically end up with lots of data — often duplicated — stored across many applications, oftentimes in a closed, proprietary format.
The traditional approach to making all these applications speak to one another lies in what I believe is an overused buzzword.
Interoperability
Typically, people associate this term with API’s or ETL’s that move data between systems to support the needs of one or more applications. Healthcare organisations have been wrestling with this idea of interoperability for years, which is understandable — stitching together an entire healthcare system in this way with hundreds of applications is highly complex and challenging.
Why is openEHR different?
openEHR still enables a system to be “interoperable”, federated, and use standards-based API’s to interact with data, but it moves the entire landscape from an app-centric architecture to a data-centric one. In making this shift, it eliminates data silos, removes point-to-point integrations between applications and provides a composable architecture that accelerates development.
Healthcare organisations considering this shift will need to carefully evaluate how they will manage their data, especially if it will be at the centre of their architecture. First, they will be making a strategic, long-term decision, so they will not want to be tied to one vendor. Second, they will be working with complex healthcare data, so they will want something that embraces this complexity and allows information to be precisely defined. Finally, they will be establishing an ecosystem of applications around the data, so they will need a robust modelling framework that encourages agility and re-use.
openEHR addresses each of these considerations as a core part of its design. It has an open architecture, allowing patient-centric information to be stored in a vendor-neutral format that is long-lived, versioned, and easily computable. Second, it has a semantic architecture, allowing the meaning of health and care information to be precisely defined. Finally, it has a robust modelling framework, where domain models are created by domain experts (such as clinicians) and are separated from technical layers, leading to greater agility and re-use.
I believe this data-centric approach — implemented using openEHR — will allow an eco-system of intuitive, user-centred applications to emerge. It will also enable innovation in clinical research, digital therapeutics, disease prevention and population health management — leveraging complementary standards such as FHIR, OMOP CDM and patterns such as Data Mesh. I am not alone in believing openEHR will make a difference. There are many examples across the world of where it is being adopted.
Adoption of openEHR in healthcare
Perhaps the most recent and high-profile example of this is the Catalonia Health Service. They plan on using openEHR for its new platform for health records across the entire region of Catalonia. The announcement highlights that its current system for sharing information is a “barrier to the systematic use of health data”, with “semantic interoperability being probably the biggest problem”.
In London, a £3.1m contract was recently announced to provide a shared care planning solution for London. This solution will “Establish… a platform of persistent data with openEHR coupled with a low code environment for health and care professionals to dynamically evolve digital care planning services”.
In Wales, Digital Health and Care Wales (DHCW) has announced a contract to implement a clinical data repository that will form a “constituent part” of their national architecture and will “help to transform care and treatment for patients”.
Still, we face some challenges
First of all, there is a view from many CIO’s and healthcare leaders that there are no applications that run on top of openEHR. This is not true. There is an ever-growing ecosystem of applications, which I expect will accelerate over the next ten years.
I also believe we are entering the next generation of software development, where no-code/low-code applications will allow citizen developers to quickly build applications safely, using platforms developed and managed by programmers and platform engineers.
Secondly, there is rarely a “greenfield” opportunity where CIOs only need to think about their target state architecture without considering what they have now. The key message here is to re-use existing assets, not be limited by them. Where new applications are introduced, adopt a data-centric approach from the start. Where existing applications are in place, incrementally move towards a data-centric architecture leveraging tools such as API management to support an intermediate state of co-existence between your current state and target state architectures.
Finally, over the last number of years, there have been many headlines and much attention surrounding FHIR. Much of this has been well deserved, and I’m an advocate for FHIR, where it is used in the right way. However, the challenge emerges when people believe FHIR and openEHR are competitive standards that do the same thing. At best, this leads to confusion; at worst, it leads to bad design decisions impacting implementations. Nevertheless, I believe there is a place for both standards to be used in a complementary way.
The alternative option of standing still is — I believe — not an option. Instead of being held back by the scars of the past or perceived challenges of the future, let’s seek to understand the benefits of a new data-centric architecture. To quote Marc Andreesen, “That’s the big opportunity. I know where I’m putting my money”.
About the author
Alastair Allen, Chief Technology Officer at Better, is an experienced technology leader with a proven track record of leading the strategy, design and development of large transformational digital services and products.