openEHR CDR Vendor Comparison 2026: EHRbase vs Better vs Ocean

If you are evaluating openEHR Clinical Data Repositories in 2026, you face a problem: there is no independent comparison. Vendor websites highlight their own strengths. Community forums have loyal advocates. Conference talks are sponsored. Nobody has laid out the technical facts side by side and said, "Here is what each platform actually does, where it excels, and where it falls short."

This blog is that comparison for three of the most widely deployed options. This blog evaluates three major openEHR CDR platforms — EHRbase, Better Platform, and Ocean Health Systems — across architecture, tooling, deployment scale, FHIR integration, cost structure, and developer experience. No vendor sponsorship. No affiliate relationships. Just engineering analysis based on published documentation, community benchmarks, and publicly available deployment data.

Why This Comparison Matters Now

The openEHR CDR market has matured dramatically. Five years ago, choosing a CDR meant choosing between "the open-source one" and "the commercial one." Today, the landscape includes three distinct approaches with fundamentally different philosophies about how clinical data infrastructure should work. Note: other openEHR CDR implementations exist (including Medblocks, Cabolabs, and others). This comparison focuses on the three platforms with the largest documented production deployments as of early 2026.

The stakes are high. A CDR selection locks your organization into an architecture for 5-10 years. Migration between CDRs — while theoretically possible because of openEHR's data portability — is operationally expensive. Choosing wrong means either over-paying for capabilities you do not need or under-investing in capabilities that will block your roadmap.

The Three Contenders at a Glance

Dimension	EHRbase	Better Platform	Ocean Health Systems
Headquarters	Germany (vitagroup AG)	Slovenia (Better d.o.o.)	Australia
License	Apache 2.0 (open source)	Proprietary	Proprietary (some free tools)
Core Philosophy	Open-source CDR with enterprise layer	Full-stack integrated platform	Clinical governance + CDR
Database	PostgreSQL 16	Not publicly disclosed	Not publicly disclosed
Language	Java (JDK 21)	Not publicly disclosed	Not publicly disclosed
Company Size	300+ (vitagroup overall)	~150 employees	Small, deeply specialized
Largest Deployment	Catalonia (7.5M inhabitants)	OneLondon (10M patients)	Queensland (150M records)
openEHR RM Version	1.1.0	Current spec	Current spec

EHRbase: The Open-Source Foundation

Architecture

EHRbase is the only mature, fully open-source openEHR CDR under a permissive license (Apache 2.0). Built in Java, running on PostgreSQL, it implements the openEHR Reference Model 1.1.0 with ADL 1.4 support. The 2.0 release in April 2024 brought a complete overhaul of the data structure and AQL engine — this was not an incremental update but a ground-up rewrite of the query layer.

The architecture is deliberately minimal: a CDR core, a REST API conforming to the openEHR specification, and an SDK (currently at v2.26.0). Everything else — form building, template design, clinical portals — comes from the ecosystem. This is a conscious design choice: EHRbase can be embedded into any technology stack without dragging along unwanted tooling.

The FHIR Bridge is a separate project that maps FHIR resources to openEHR compositions. It works as a broker between HL7 FHIR clients and the openEHR server, but it is not a native FHIR endpoint — this distinction matters for integration planning.

Strengths

• Full source code access — Audit, modify, and extend the CDR without vendor permission. Critical for organizations with strict sovereignty requirements, custom compliance needs, or security teams that mandate code review of infrastructure dependencies.
• Flexible deployment — Docker, Kubernetes, bare metal, any cloud provider. Lightweight footprint (JRE + PostgreSQL). Fits into existing infrastructure rather than requiring its own stack.
• Strong institutional backing — vitagroup (300+ employees), HiGHmed consortium (German university hospitals), and Hannover Medical School's Peter L. Reichertz Institute provide sustained development investment and academic rigor.
• Enterprise upgrade path — HIP EHRbase adds multi-tenancy API, event triggers, transaction compensation, and message-bus integration. You can start open-source and graduate to enterprise without re-platforming.
• National-scale proven — Deployed in Catalonia (7.5M inhabitants) alongside IBM, RedHat, and Yugabyte. Powers German Hospital Future Act (KHZG) compliance infrastructure across university hospitals.
• AQL engine rebuilt from scratch — Version 2.0 AQL engine includes path-node-skipping optimization, template cache pre-fill, and experimental FOLDER querying. Performance characteristics are well-documented.

Weaknesses

• No built-in tooling — No form builder, no template designer, no clinical portal, no low-code environment. You need to source these separately or build them. This is not a problem for engineering-heavy teams, but it significantly increases initial implementation effort for clinical informatician-led projects.
• FHIR support is indirect — The FHIR Bridge requires maintaining a separate mapping layer. Organizations needing deep FHIR interoperability should budget for this integration effort.
• Requires DevOps maturity — Self-hosting an open-source CDR demands expertise in monitoring, scaling, security patching, and upgrade orchestration. Organizations without strong infrastructure teams will struggle.
• Community is modest — ~107 GitHub stars, 275 forks. The EHRbase Sandbox reached 400+ subscribers within 5 months, indicating growing interest, but the community is still small compared to mainstream open-source database projects.

Best For

Organizations with strong engineering teams that want full control over their clinical data infrastructure. Government projects with data sovereignty requirements. Teams building custom health platforms where the CDR is one component in a larger architecture. Research institutions that need to modify CDR internals for novel use cases.

Better Platform: The Enterprise Full-Stack

Architecture

Better Platform is the most comprehensive commercial openEHR offering. It is not just a CDR — it is an integrated platform that includes the Clinical Data Repository, an Operational Data Repository (ODR), Better Studio (low-code clinical app builder), AQL Builder (with AI-assisted query generation), Better ETL 2.0 (data integration/export), and a Clinical Portal. The architecture is event-driven, powered by Apache Kafka for real-time data streaming.

Better provides both openEHR REST API and native FHIR API from the same platform, making it one of the few implementations that natively speaks both standards without requiring a bridge. The Demographics Server supports HFQL (a query language over FHIR data), adding another integration surface for demographics-heavy workflows.

Strengths

• Comprehensive tooling suite — Better Studio 3.12 claims 90% reduction in clinical application development time. The low-code approach means clinical informaticians — not just software developers — can build data capture forms, clinical workflows, and dashboards. The AQL Builder includes natural language to AQL translation, lowering the barrier to clinical querying.
• Proven at national scale across multiple countries — OneLondon Universal Care Plan serves 10 million patients across 5 Integrated Care Systems, 40+ NHS trusts, and 1,400 GP practices. National EHR systems in Slovenia, Greece, and Malta. 60+ hospitals in Finland. 30+ million patients supported globally across 20+ markets.
• Industry recognition — Named a Leader in the IDC MarketScape: EMEA Healthcare Data Platforms for Providers 2025. NHS Full Rollout Approval for Electronic Prescription Service (EPS). These validations matter for enterprise procurement processes that require analyst backing.
• Native dual-standard support — openEHR and FHIR APIs from the same platform with bidirectional mapping. No bridge to maintain, no mapping layer to manage. Dynamic terminology validation and mapping via FHIR API.
• AI-assisted clinical modeling — Better Studio 3.12 introduced AI capabilities for template design and clinical modeling. The platform is investing in AI-augmented development tools ahead of most competitors.
• Real-time event architecture — Apache Kafka integration enables event-driven workflows: trigger alerts, notifications, and downstream processing when clinical data changes. This is infrastructure that other CDRs require you to build yourself.

Weaknesses

• Vendor lock-in risk beyond the data layer — Despite openEHR's data portability, the platform tooling (Studio, Portal, ETL) is proprietary. Migrating away means replacing your entire development workflow and retraining your clinical informatics team, not just pointing to a new CDR.
• Opaque pricing — No public pricing whatsoever. Enterprise sales model means lengthy procurement cycles, pricing that varies significantly by deal size and region, and difficulty benchmarking cost against alternatives.
• No source code access — If you hit a CDR bug that blocks a go-live, you file a support ticket. Organizations accustomed to open-source velocity — where you can patch and submit a PR — may find this constraining during critical deployment phases.
• Platform coupling — The platform works best when you use all of it. Cherry-picking individual components (just the CDR without Studio, or just the AQL engine) may not be supported or cost-effective. This is a feature for all-in organizations but a constraint for those with existing tooling investments.

Best For

Large health systems and national programs that need a turnkey platform with integrated tooling. Organizations where speed of clinical application development matters more than infrastructure control. Procurement teams that value analyst recognition and established reference sites. Programs with mixed teams of clinical informaticians and developers who need shared tooling.

Ocean Health Systems: The Governance Pioneer

Architecture

Ocean Health Systems occupies a unique position in the openEHR ecosystem: it built the first openEHR CDR (OceanEHR) and maintains the Clinical Knowledge Manager (CKM) — the platform that the entire openEHR community uses worldwide for archetype governance. This is not just a CDR vendor; it is a foundational infrastructure provider for the openEHR ecosystem itself.

Founded around 1998 by Sam Heard, Peter Schloeffel, and David Rowed alongside Thomas Beale's openEHR specification work, Ocean has the deepest heritage in openEHR of any organization. The product suite includes OceanEHR (the CDR), the Clinical Knowledge Manager (CKM, launched May 2008), the Template Designer (free, drag-and-drop), the Archetype Editor (open-source), and Multiprac Surveillance (healthcare-associated infection monitoring aligned with Australia's new Centre for Disease Control, established January 2026).

Strengths

• Deepest openEHR heritage — Built the first CDR. Maintains the CKM. Multiple team members are recognized openEHR Senior Fellows. Sam Heard serves as board Chair. The team has 100+ person-years of collective health informatics experience. No other vendor has this depth of specification-level expertise.
• CKM is the global standard — The Clinical Knowledge Manager is used for archetype governance by national programs in Norway, UK, Germany, Slovenia, Finland, Jamaica, Canada, and Catalonia. If you use openEHR, you almost certainly use CKM. Ocean maintains this as infrastructure for the entire community.
• Largest deployment by record count — Queensland Health: 130+ public hospital sites, 150 million patient records on openEHR. This is one of the single largest openEHR deployments in the world and demonstrates that the architecture handles genuine enterprise scale.
• Free governance tooling — Template Designer and Archetype Editor are provided free of charge and are widely adopted across the community. Even organizations using competing CDRs often use Ocean's governance tools.
• Government and public health expertise — Deep knowledge of public health surveillance, infection control, and national health data infrastructure. Multiprac Surveillance addresses a concrete clinical need (HAI monitoring) rather than being generic platform tooling.
• Specification influence — As a founding contributor to the openEHR specification, Ocean's CDR implementation reflects deep understanding of the standard's design intent, not just its letter. Edge cases and ambiguities are resolved by the people who designed the specification.

Weaknesses

• Limited technical transparency — OceanEHR's internal architecture, database backend, API specifics, and performance characteristics are not publicly documented in detail. This makes independent technical evaluation difficult and creates reliance on the vendor's representations during procurement.
• Aging development tooling — The Template Designer is a Windows-only desktop application. In 2026, when development teams expect web-based, cross-platform tooling, this is a significant friction point. Teams on macOS or Linux must use virtual machines or Wine to access the tool.
• Geographic concentration — Primarily focused on Australia/Oceania with selective international projects (Catalonia CKM deployment, UK connections). Organizations in other regions may face timezone challenges and limited local partner networks.
• FHIR as secondary integration — FHIR support through AU Core and emerging FHIR/OMOP mappings in CKM, but it appears to be a secondary capability rather than a core architectural pillar. Organizations where FHIR interoperability is a primary requirement may find this limiting.
• No public cloud/SaaS offering — Primarily on-premise and managed hosting deployment models. No self-service cloud option is visible, which limits accessibility for smaller organizations or innovation teams that want to experiment quickly.

Best For

Government health programs that need archetype governance infrastructure alongside their CDR. Public health surveillance and infection control use cases. Organizations in Australia/Oceania working with AU health standards. Projects where clinical knowledge management and archetype stewardship are as important as data storage. Organizations that value having the specification authors as their implementation partners.

Head-to-Head: Six Dimensions That Matter

1. AQL Compliance

All three platforms support AQL, but the depth and transparency vary. EHRbase rebuilt its AQL engine from scratch in version 2.0, supports experimental FOLDER querying, and publishes performance tuning documentation. Better adds AI-assisted query building and natural language to AQL translation on top of standard compliance. Ocean supports AQL through OceanEHR but does not publish detailed compliance documentation publicly.

Winner: Tie between EHRbase (most transparent, open-source engine you can inspect) and Better (most user-friendly tooling layered on top of AQL).

2. FHIR Integration

Better offers native dual-API support — openEHR and FHIR from the same platform with bidirectional mapping and no bridge required. EHRbase relies on the separate FHIR Bridge project, which works but requires maintaining an additional component. Ocean treats FHIR as a secondary integration layer, with AU Core support and emerging FHIR mappings in CKM.

Winner: Better, clearly. Native dual-standard support without a bridge is a significant architectural advantage.

3. Tooling Ecosystem

Better's integrated suite (Studio, AQL Builder, ETL, Portal) is unmatched in breadth and depth. Ocean's CKM and Template Designer dominate the governance and clinical knowledge management layer — even competing vendors' customers use Ocean's governance tools. EHRbase intentionally has minimal built-in tooling, relying on the ecosystem.

Winner: Better (application development breadth) or Ocean (governance and archetype management), depending on whether your priority is building clinical apps or managing clinical knowledge.

4. Open-Source Access

EHRbase is fully open under Apache 2.0 — the CDR core, the SDK, and the FHIR Bridge are all inspectable and modifiable. Ocean provides free tooling (Template Designer, Archetype Editor) but the CDR itself is proprietary. Better is fully commercial with no open-source components for the core platform.

Winner: EHRbase, unambiguously. It is the only production-grade open-source openEHR CDR under a permissive license.

5. Production Scale

Ocean's Queensland deployment (150M records across 130+ sites) leads by raw record count. Better's global footprint (30M+ patients across 20+ markets, with national systems in Slovenia, Greece, Malta, and the OneLondon programme) leads by geographic breadth. EHRbase's Catalonia deployment (7.5M inhabitants) demonstrates national-scale capability with a modern cloud-native architecture.

Winner: Ocean (by record count) or Better (by geographic breadth and number of national deployments).

6. Developer Experience

EHRbase's open-source nature, clean REST API, Docker-first deployment, and SDK appeal to developers who want to build custom solutions. Better's Studio targets clinical informaticians more than developers — powerful for its audience but less flexible for custom engineering. Ocean's desktop-only tooling feels dated for modern development workflows.

Winner: EHRbase, by virtue of open-source access, container-native deployment, and clean API design.

Total Cost of Ownership: The Hidden Variables

License cost is the least important variable in CDR TCO. The real costs are implementation, integration, and ongoing operations.

Cost Component	EHRbase	Better Platform	Ocean Health Systems
License	Free (open-source) to moderate (HIP enterprise tier)	High (enterprise subscription pricing)	Moderate (commercial CDR + governance tools)
Infrastructure	Your cloud costs (full control, full responsibility)	Included in SaaS or your hosting costs	Managed hosting or on-premise infrastructure
Implementation	High (must build or source tooling layer)	Moderate (Studio accelerates clinical app development)	Moderate to high (specialized engagement model)
Ongoing maintenance	High (internal DevOps team required)	Low to moderate (vendor-managed platform)	Moderate (vendor-managed with support contracts)
Training	Moderate (developer-oriented, self-service docs)	Moderate (Studio training for clinical informaticians)	Low to moderate (established tooling, community knowledge)
Primary hidden cost	Building and maintaining missing tooling	Vendor lock-in and switching cost at tooling layer	Tool modernization and geographic accessibility

The counterintuitive finding: EHRbase's zero license cost often results in higher total cost than Better's commercial pricing — because the implementation, tooling, and DevOps costs are substantial. The cheapest CDR to license is not the cheapest CDR to operate. Organizations have spent 18 months and significant engineering budget building tooling that Better would have provided out of the box.

Conversely, Better's higher license cost often delivers lower total cost for organizations that use the full platform — because Studio, ETL, and Portal reduce implementation effort by months, not days.

Ocean's cost structure falls in between: moderate licensing with strong governance tooling included, but potential hidden costs in modernizing desktop-based workflows for web-native teams.

The Decision Framework

Rather than declaring a single winner (there is none), here is a decision framework based on what actually drives CDR selection in practice.

Choose EHRbase if:

• Source code access is a hard requirement (sovereignty, compliance, security audit mandates)
• You have a strong DevOps and engineering team with infrastructure expertise
• The CDR is one component in a larger custom-built health platform
• You want the option to graduate to HIP enterprise features without re-platforming
• Budget is heavily constrained on licensing but available for engineering talent
• You need to modify CDR internals for research or novel clinical use cases

Choose Better Platform if:

• You need a turnkey platform with integrated tooling, not a bare CDR component
• Clinical application development speed is your primary constraint
• Procurement requires analyst recognition (IDC MarketScape) and established references
• You want native openEHR + FHIR without managing a bridge
• Your team includes clinical informaticians who need low-code development tools
• You are deploying at national scale and need proven multi-country track record

Choose Ocean Health Systems if:

• Clinical knowledge governance (archetype stewardship, CKM) is as important as data storage
• You are in Australia/Oceania or working with Australian health standards
• Public health surveillance and infection control are core use cases
• You value having specification authors as your implementation partners
• You need proven massive-scale deployment (150M+ records at a single health system)
• Government and public health infrastructure alignment matters more than developer tooling

Emerging Trends to Watch

The CDR landscape is evolving rapidly. Three trends will reshape this comparison within the next 12-18 months:

AI-augmented clinical modeling. Better is leading with AI features in Studio 3.12, but EHRbase's open ecosystem makes it likely that community-built AI tooling will emerge. Expect AI-assisted template design, automated AQL generation, and intelligent data quality monitoring to become table stakes across all platforms.

FHIR convergence. The gap between openEHR-native and FHIR-native platforms is narrowing. Better already offers dual APIs. EHRbase's FHIR Bridge is maturing. Ocean is adding FHIR and OMOP mappings to CKM. Within two years, FHIR interoperability may cease to be a differentiator and become a baseline expectation.

Cloud-native deployment. EHRbase's container-first architecture positions it well for cloud-native orchestration. Better offers SaaS. Ocean's on-premise focus may need to evolve as health systems increasingly expect managed cloud options. The vendor that makes CDR deployment as simple as provisioning a managed database will capture the next wave of adopters.

How to Think About CDR Selection

Based on documented deployments and community experience, here are the patterns that emerge:

There is no wrong choice among these three — only mismatched choices. Every platform on this list is production-proven, technically sound, and backed by teams that genuinely understand openEHR. The most common failures in CDR selection come not from picking a bad platform, but from picking one whose strengths do not align with the organization's actual constraints.

A government health department that chose EHRbase for its Apache license spent 18 months building tooling that a commercial platform would have provided out of the box — not because EHRbase was wrong, but because the team underestimated the tooling investment. A national program that chose a full-stack platform found that their clinical informaticians thrived with low-code tools, but their developers felt constrained by the proprietary environment.

The right question is not "Which CDR is best?" It is "Which CDR's strengths match our constraints?"

Start with your constraints — budget, team composition, timeline, regulatory requirements, FHIR needs, governance maturity, scale trajectory — and work backwards to the platform that addresses them. The comparison above gives you the factual foundation to make that match.

And remember: openEHR's data portability is real. If you choose well and build on archetype-based data models, switching CDRs later — while not trivial — is architecturally possible. That is the strategic insurance policy that openEHR provides regardless of which vendor you select.