When implementing healthcare solutions, one comes across various products, standards, and frameworks and often wonders what is the role of each in a Patient’s journey;
Below I try to compare and highlight the difference between a product for building apps (Medplum) and a standard for storing clinical meaning (openEHR).
The Core Distinction
- Medplum is a Headless EHR Platform. It provides a backend (Database + API) based on FHIR standards. Developers use it to build apps quickly (UI, auth, workflows) using modern code (React/TypeScript).
- openEHR is a Data Standard & Architecture. It is a way of defining clinical data models (archetypes) so they are semantically strict and vendor-neutral. You buy/build a “Clinical Data Repository” (CDR) to implement it.
Role in a Patient Journey
| Journey Stage | Medplum’s Role (The “App” Engine) | openEHR’s Role (The “Clinical” Memory) |
| 1. Onboarding & Intake | Digital Front Door: Powers the patient portal, registration forms, and scheduling UI. It handles the transaction of signing up and booking. | Data Definition: Defines exactly what “Tobacco Use” or “Allergy” means structurally so the data captured is clinically valid forever. |
| 2. Active Care & Treatment | Workflow Orchestration: Manages tasks (e.g., “Nurse to administer meds”). It routes messages between care teams and triggers notifications via API. | Complex Modelling: Stores the granular details of a complex assessment (e.g., a specific oncology protocol) that doesn’t fit neatly into a standard generic field. |
| 3. Interoperability | The Connector: Because it is FHIR-native, it easily syncs data with Apple Health, other hospital EHRs (Epic/Cerner), and billing systems. | The Translator: Ensures that when data is shared, the clinical meaning is preserved (Semantic Interoperability), even if the receiving system is different. |
| 4. Long-Term History | Access Layer: Provides the API for a patient to view their history on a mobile app 5 years later. | Longitudinal Record: Ensures the data created 5 years ago is still readable and valid today, even if the software app (Medplum/frontend) has changed version or vendor. |
Limitations
Medplum
- Storage vs. Exchange: Medplum uses FHIR for storage. FHIR was designed for messaging (exchange), not necessarily for complex database architecture. This can lead to data nesting issues or “data bloat” when trying to store highly complex clinical histories.
- Clinical Granularity: If you need to record a rare clinical observation that doesn’t have a standard FHIR “Resource,” you must build custom “Extensions,” which can be technically cumbersome to maintain.
openEHR
- No “App” Included: It is just the backend/data layer. It offers no UI, no patient portal, and no auth widgets out of the box. You have to build the entire frontend yourself (or buy a separate tool).
- High Learning Curve: The modelling language (Archetypes/Templates) is academic and difficult. Finding developers who understand openEHR is significantly harder than finding React/FHIR developers (who flock to Medplum).
So, what to use when?
Use Medplum if you are a startup or digital health company needing to launch a patient-facing app quickly with modern developer tools.
Use openEHR (often alongside a tool like Medplum) if you are building a long-term regional health record or a system where complex clinical data integrity over decades is more important than speed to market.
If you are building Healthcare solutions and need AI integration, such as Clinical Decision Support Systems, to empower the care takers (Doctors), please feel free to reach out to me;