Why openEHR?
In this lesson we’ll take a look at the problem with the traditional approaches of software development in the healthcare domain and why some of the most popular and widely adopted technologies don’t work in healthcare.
Monolithic Systems
Monolithic EHR systems [Read: Epic, Cerner] bundle every function into one tightly coupled application. While this integrated approach once made implementation simpler, it now poses significant challenges. Because all components are interdependent, scaling one area such as laboratory requests requires scaling the entire system. This leads to inefficient resource utilization and higher costs, especially in large hospitals where workloads can fluctuate dramatically.
Another major limitation lies in the proprietary nature of most monolithic EHRs. Data is stored in closed, vendor-specific formats that make it difficult to share or analyze beyond the confines of the system. Hospitals often find themselves locked into a single vendor’s roadmap, upgrade cycle, and pricing structure. Attempting to switch vendors can lead to risky data migration projects, often deterring organizations from pursuing more innovative or cost-effective solutions.
Interoperability is another area where monolithic systems fall short. They were not designed for the API-driven world. Integrations that should be straightforward become expensive, custom-built projects requiring significant technical expertise. Moreover, because these systems were built around generic workflows, hospitals are forced to adapt their clinical processes to fit rigid software structures. Customization is rarely feasible, so clinicians end up working around the system rather than with it, reducing efficiency.
As healthcare evolves, monolithic systems are increasingly out of sync with the broader ecosystem. The industry is moving rapidly toward open, standards-based models such as FHIR, openEHR, OMOP, and national health information exchanges that enable data portability and long-term interoperability.
Multiple Applications Sharing a Database
In a shared database architecture all apps depend on the same schema. A simple change such as renaming a column or altering a table structure can break another app unexpectedly. This tight coupling between services creates fragility, making it difficult for teams to evolve their applications independently.
The database itself becomes a single point of contention. When multiple applications query the same database simultaneously, performance often degrades across the board. What starts as a shared resource for convenience quickly turns into a choke point.
This architecture also slows down innovation. If App A’s team wants to evolve faster, they’re limited by App B and C’s reliance on the same schema. Coordination overhead increases because every change “requires a meeting”.
Microservices
Microservices in healthcare promise agility, modularity, and resilience, this works upto a point because the apps talk to each other through REST interface or their own bespoke API, but:
- Interaction via bespoke APIs: If you had n systems, you needed n × (n – 1) connections to make them all talk.
- They fragment patient data (longitudinal health record vs data silos).
- Lifespan of the application itself is much shorter (gets outdated every 10 years) than the lifespan of a patient. Which in turn increases operational and compliance costs.
Unified Data Platform
A unified data platform acts as a single source of truth in healthcare, bringing together information from EHRs, labs, imaging, pharmacy, and even wearables. Instead of clinicians jumping between systems, all data is consolidated into one longitudinal patient record.
Better clinical outcomes depend on complete and consistent data. Without unification, decision support tools or AI models risk missing context, like a critical allergy stored in another system. By harmonizing data, a unified platform ensures clinicians make evidence-based decisions with the full patient story in view.
We’re seeing the rise of FHIRnative databases or graph databases, but doing this is actually hard. We want the same information represented in the same way while allowing the applications to evolve and have their own set of requirements.
This is where openEHR shines.
openEHR as a Solution
As discussed previously, healthcare today suffers from fragmented, siloed systems that make it difficult to share and reuse clinical data. This has created a barrier for clinicians, patients, and innovators who need long-term access to data.
openEHR offers a solution by separating the clinical content from the technical implementation. It defines an open, vendor-neutral way of structuring health information using archetypes and templates. This ensures data remains consistent, reusable, and independent of any single application or vendor.
The strength of openEHR lies in its “semantic persistence” data stored once can be interpreted and reused decades later. Because the clinical models are built and governed by a global community, they evolve with medical knowledge while keeping past records valid. This makes openEHR ideal for long-term patient care.
In the next module we’ll take a look at how openEHR solves the “hard” problem of building a unified data platform.
