openEHR CDR Vendor Comparison 2026: Choosing a Clinical Data Repository

An openEHR CDR (clinical data repository) is the database and API layer that stores patient records as openEHR compositions, validates every write against archetypes and templates, keeps a full version history, and answers questions through the Archetype Query Language (AQL). Among openEHR vendors in 2026, the realistic CDR choices are an open source server you run yourself (EHRbase), an enterprise distribution of that server (vitagroup HIP EHRbase and HIP CDR), a full commercial platform (Better), an openEHR platform that ships inside a hospital EHR (DIPS), and a small group of specialist and emerging repositories (Ocean Health Systems, Cadasto, CaboLabs Atomik, ArcEHR).

This guide compares those openEHR CDR vendors on the criteria that decide real projects: conformance, AQL, scale, multi-tenancy, terminology, FHIR, security, hosting and data residency, licensing, tooling and support. Every vendor fact below links to the vendor's own documentation, the openEHR specifications or a public procurement record, and reflects what was publicly stated as of September 2026. Where a vendor does not publish something, we say "not publicly stated" rather than guess.

Free to share: you can use this image in presentations or docs with a link to this page.

If you are planning a clinical data platform and want a second pair of eyes on the shortlist, our openEHR integration services team runs CDR selection workshops and builds the integrations around whichever repository you choose.

What is an openEHR CDR?

A clinical data repository is a system that stores clinical data for many applications at once, separate from any single user interface. An openEHR CDR is a clinical data repository that stores that data in the openEHR Reference Model, so the structure of every record is defined by shared clinical models (archetypes and templates) rather than by one vendor's database schema.

In practice an openEHR CDR does six jobs:

• Stores compositions. A composition is one clinical document, such as a lab result, a care plan or a discharge summary, built from archetypes and constrained by a template.
• Validates on write. A composition that does not match its template is rejected, which keeps data quality high for every application that reads it later.
• Versions everything. Every change creates a new version with an audit trail of who changed what and when.
• Answers AQL queries. The Archetype Query Language lets you query by clinical meaning (for example, every systolic blood pressure over 140) instead of by table and column.
• Exposes the openEHR REST API. The latest stable release of the openEHR REST API specification is Release 1.1.0.
• Keeps data independent of applications. Because the data model is open, a new application can read and write the same records without a migration.

That last point is the reason health systems choose openEHR at all, and it is why the CDR decision matters more than any single application decision. If the data model is new to your team, our guide to what openEHR is and the developer's explanation of archetypes, templates and compositions cover the background.

openEHR CDR vs EHR, FHIR server and data warehouse

An openEHR CDR is the long-term, model-driven store of clinical data; an EHR is the application clinicians use, a FHIR server is an exchange layer, and a data warehouse is an analytics copy. Many programmes run all four, so it pays to keep their jobs separate when you write CDR requirements.

The practical rule: put data you must keep and reuse for decades in the CDR, expose it through FHIR where other systems need it, and copy it to analytics platforms for population work. If you are replacing a custom EHR database, the CDR is the piece that replaces it.

openEHR CDR vendors in 2026 at a glance

The openEHR CDR market in 2026 has one widely used open source server, one enterprise distribution of it, one full commercial platform, one EHR vendor running its own openEHR platform, and several specialist or emerging repositories. The table summarises what each vendor publicly states.

Pricing is not in the table because no commercial vendor above publishes a price list. EHRbase itself is free to use under Apache 2.0; everything else is quoted on request. Budget planning for all of them is covered in the licensing criterion below.

How to evaluate an openEHR CDR: 11 criteria that decide the project

The best openEHR CDR is the one that passes your own requirements on conformance, query, scale, security and exit, not the one with the longest feature list. These are the eleven criteria we score in every CDR selection, in the order that most often eliminates a candidate.

1. Conformance and specification release

Ask which releases of the Reference Model, ADL and the REST API the CDR implements, and ask for evidence. EHRbase, for example, states on its GitHub repository that it implements Reference Model 1.1.0 and ADL 1.4. openEHR International has published a conformance framework covering API conformance and data validation, but its certification procedures are still marked to be determined, so today "conformant" is a vendor statement you should verify with your own test suite.

2. AQL completeness

AQL is where differences between CDRs show up fastest. Write ten of your real clinical questions as AQL (cohorts, latest values, time windows, nested clusters, ORDER BY with LIMIT) and run them against each candidate during evaluation. Queries that fail or return different results tell you more than any datasheet.

Here is the starting AQL test pack we use. It relies only on archetypes published in the international Clinical Knowledge Manager, so every candidate can load the same templates:

-- 1. Latest systolic blood pressure per patient (ordering + limit)
SELECT e/ehr_id/value AS ehr_id,
       o/data[at0001]/events[at0006]/time/value AS measured_at,
       o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude AS systolic
FROM EHR e
  CONTAINS COMPOSITION c
  CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.blood_pressure.v2]
ORDER BY o/data[at0001]/events[at0006]/time/value DESC
LIMIT 1

-- 2. Cohort: every reading over 140 in a time window (WHERE on magnitude and date)
SELECT e/ehr_id/value,
       o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude
FROM EHR e
  CONTAINS OBSERVATION o[openEHR-EHR-OBSERVATION.blood_pressure.v2]
WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude > 140
  AND o/data[at0001]/events[at0006]/time/value >= '2026-01-01T00:00:00'

-- 3. Count compositions by template (aggregate function)
SELECT c/archetype_details/template_id/value AS template, COUNT(c/uid/value) AS total
FROM EHR e CONTAINS COMPOSITION c

Extend it with your own questions: a nested CLUSTER inside a lab result, a query across two compositions for the same patient, a coded-text filter on a SNOMED CT code, and a query over a large EHR with many versions. Run each on every candidate, compare results and latency, and record which features (aggregates, ORDER BY on nested paths, parameters) each engine supports. The AQL specification is the reference for expected behaviour.

3. Performance and scale

Define the numbers before the demo. The Catalan Health Service's CDR tender, for example, set a 95th percentile target of 40 milliseconds for queries and 60 milliseconds for create, update and delete operations, according to the award discussion on the openEHR forum. Borrow that style of requirement and test it on your own templates and data volumes.

4. Multi-tenancy

Regional platforms and software vendors serving many customers need tenant separation. Check whether it is logical (schema or database per tenant) or only an application filter, and how tenants are created. vitagroup's HIP EHRbase multi-tenancy plugin, for example, separates tenants with dedicated database schemas and OAuth2 workflows in Keycloak.

5. Terminology

Coded data is only useful if codes are validated. Ask how the CDR binds to SNOMED CT, LOINC and local code systems, and whether it can call an external terminology server. EHRbase describes automated validation against templates and FHIR terminology servers.

6. FHIR bridge

Most openEHR programmes still need FHIR for exchange with other systems. Establish whether FHIR is native to the platform, provided as a facade, or something you build with mappings. Our openEHR vs FHIR guide and the FHIR to openEHR resource mapping matrix show what that mapping work involves.

7. Security and audit

Look for role-based access, OAuth2 or OpenID Connect, encryption at rest and in transit, and audit logging in a standard format. HIP EHRbase, for example, lists ATNA audit logging over TLS among its enterprise features.

8. Hosting and data residency

UK and EU buyers usually need data held in-country or in the EU, and some public bodies need on-premises options. Ask where the managed service runs, who operates it, and which security certifications apply. Cadasto, for example, states ISO 9001, ISO 27001 and NEN 7510 (the Dutch healthcare information security standard).

9. Licensing and total cost

Compare five-year cost, not year-one licence. For open source, cost sits in hosting, operations, upgrades and support contracts. For commercial platforms, ask how pricing scales (by patient, record, facility, tenant or transaction) and what is included: tooling, environments, support tiers and upgrades.

10. Ecosystem and tooling

A CDR on its own does not give clinicians forms or give modellers a template editor. List the tools you need around it (template design, form rendering, AQL builders, ETL, analytics) and check which come with the platform and which you will source separately.

11. Support and roadmap

Check release cadence, support hours in your time zone, escalation paths and who else relies on the product. EHRbase's public release history is visible on GitHub (v2.36.0 was released on 15 September 2026); commercial vendors should be able to show an equivalent record.

openEHR CDR vendors compared in depth

Each profile below covers licence, deployment, standards and APIs, public deployments, best fit and one limitation, using only what the vendor or a public record states.

EHRbase openEHR CDR (open source)

EHRbase is an open source openEHR CDR released under the Apache 2.0 licence and developed by vitagroup together with Hannover Medical School and the HiGHmed consortium, according to the EHRbase project site. It is also the base of vitagroup's commercial HIP products.

• Licence: Apache 2.0 (GitHub).
• Stack: Java (the README asks for JDK 25) on PostgreSQL 15 or later, with version 16 recommended.
• Standards: Reference Model 1.1.0, ADL 1.4, the openEHR REST API and AQL.
• Release cadence: four releases between July and September 2026: v2.34.0 (8 July), v2.35.0 (17 August), v2.35.1 (20 August) and v2.36.0 (15 September).
• FHIR: terminology validation through FHIR terminology servers. The separate EHRbase FHIR Bridge repository has been archived since April 2024, so plan FHIR exchange as its own integration.
• Public deployments: the Catalan Health Service platform runs EHRbase 2.0 within vitagroup's HIP CDR (vitagroup), and the server was co-developed within HiGHmed, a consortium of German university hospitals (HiGHmed).

Best fit: teams with strong engineering and operations that want full control of the repository, national or regional programmes that require open source, and product companies embedding a CDR in their own platform. Our openEHR REST API guide uses the same API shape EHRbase exposes.

Limitation: it is a repository, not a platform. Template design, forms, clinical portals and FHIR exchange come from elsewhere, and you own hosting, upgrades and monitoring unless you buy a support contract.

vitagroup HIP EHRbase and HIP CDR (enterprise)

HIP EHRbase is vitagroup's enterprise distribution of EHRbase with professional services and service level agreements, and HIP CDR is the clinical data repository inside vitagroup's wider Health Intelligence Platform. The EHRbase enterprise documentation lists what it adds to the open source core:

• YugabyteDB support for a distributed, PostgreSQL-compatible database.
• Event triggers that run AQL criteria when a composition is stored and forward results over HTTP or AMQP (RabbitMQ and Kafka), per the event trigger documentation.
• Multi-tenancy with a schema per tenant.
• Transaction compensation to roll back across services.
• ATNA audit logging and a Merge-EHR operation for duplicate patient records.

Public deployments: the Catalonia clinical data platform (HIP CDR with EHRbase 2.0 and YugabyteDB, delivered with IBM), and, by vitagroup's own figures on its HIP site, 150 hospitals and about 20 million lives across its projects.

Best fit: regional and national programmes that want an open source core with a commercial support contract and enterprise features already built.

Limitation: pricing is not publicly stated, and the enterprise features are part of the commercial product rather than the open source repository.

Better Platform openEHR CDR

Better Platform is a commercial digital health platform from Better, headquartered in Ljubljana, Slovenia, that combines an openEHR clinical data repository with a FHIR operational data repository and the Better Studio low-code tools, according to Better. Better states it has offices in Slovenia, the United Kingdom and Germany, more than 200 employees and EHRs for more than 40 million unique patients stored (Better, About us).

• Licence: commercial.
• Deployment: cloud and on-premises.
• Standards: openEHR CDR for clinical data; FHIR for demographic, operational and workflow data in the same platform.
• Tooling: Better Studio for building archetypes, templates, forms and applications in a low-code environment, including an AQL Builder with autocompletion and validation.
• Public deployments: the OneLondon Universal Care Plan, covering a footprint of 10 million people across five integrated care systems, with the Better CDR at its core (Better whitepaper) and integration into the NHS App (Better news); national programmes in Slovenia, Greece and Ireland; NHS trusts including The Christie, Oxford and Somerset; and university hospitals in Switzerland and Germany.

Best fit: health systems and national programmes that want one vendor for the repository, the modelling tools and application building, with clinical informaticians building forms themselves.

Limitation: the tooling around the repository is proprietary, so a later move to another CDR keeps your data (it is openEHR) but not your forms and applications; pricing is not publicly stated.

DIPS openEHR platform (EHR Store)

DIPS runs its own openEHR platform inside DIPS Arena, the hospital EHR that DIPS states is in use in more than 85% of Norwegian hospitals. DIPS EHR Store is the openEHR server at the centre of that platform, managing compositions and supporting AQL, and DIPS has described an AQL-based ETL service for analytics in its openEHR suite presentation.

Best fit: Nordic hospitals choosing DIPS Arena, where openEHR comes with the EHR rather than as a separate purchase.

Limitation: it is not publicly offered as a standalone CDR for other applications to buy on its own terms; detailed API and FHIR documentation is not published on the DIPS product pages.

Ocean Health Systems

Ocean Health Systems, based in Australia, developed early openEHR specifications and tooling and runs the Clinical Knowledge Manager (CKM), which by openEHR International's account has registered users from 114 countries (openehr.org). OceanEHR is listed on the openEHR platform page, and Ocean's Multiprac infection surveillance solution runs on openEHR across more than 130 Queensland public hospital sites, managing 150 million patient records according to the same openEHR International article.

Best fit: organisations that want deep clinical modelling and governance expertise alongside the repository, and Australian public health buyers already using Ocean's solutions.

Limitation: OceanEHR's API, deployment options and FHIR support are not detailed on Ocean's public product pages, so plan a technical deep-dive early in any evaluation.

Cadasto (with CODE24)

Cadasto is a vendor-neutral, openEHR based "care data storage" platform from Alkmaar, the Netherlands, launched at the beginning of 2026 and built on the data layer of CODE24's mConsole EHR, according to Cadasto. Cadasto is an openEHR International Platinum Partner (openehr.org), holds ISO 9001, ISO 27001 and NEN 7510, and CODE24 acts as a reseller.

Best fit: Dutch and wider EU care providers that want an openEHR data platform with Dutch healthcare security certification and local support.

Limitation: as a 2026 launch, its public reference list, API documentation and deployment options are still limited on its website.

CaboLabs Atomik and EHRServer

CaboLabs, based in Montevideo, Uruguay, offers Atomik, a commercial clinical and demographic data repository built on openEHR with AQL querying, automatic versioning and audit trails, clustering, and a FHIR facade exposing R4 and R5 resources (CaboLabs Atomik). Atomik is a production refactoring of CaboLabs' earlier EHRServer, which CaboLabs describes as the first open source openEHR clinical data repository and now positions for training and non-production use (CaboLabs EHRServer).

Best fit: health software companies that want a hosted openEHR backend with a FHIR facade, and teaching or proof-of-concept work on EHRServer.

Limitation: public reference deployments are not named, and the EHRServer repository has not been updated since March 2023 (GitHub).

ArcEHR (private beta)

ArcEHR is an openEHR CDR built on the ArcadeDB multi-model database by Medical Ltd in Slovenia. It is in private beta under proprietary terms, with a stated goal of releasing under Apache 2.0 at public launch, and it answers AQL alongside SQL, Cypher, Gremlin, GraphQL and MongoDB QL, with PostgreSQL wire protocol compatibility (ArcEHR).

Best fit: teams that want to query clinical data with graph and SQL tools their analysts already know, and are willing to co-develop with an early-stage product.

Limitation: no named customers yet and supported openEHR specification versions are not stated.

Emerging and inactive open source servers

Two more open source projects come up in CDR searches. FerroEHR is a Rust openEHR CDR started in July 2026 that targets REST API 1.1.0, AQL 1.1 and PostgreSQL 18; it is worth watching but young for production use. EtherCIS, an earlier open source server, has had no commits since March 2019, so we do not include it in the comparison.

Where Nirmitee fits: implementation partner, not a CDR vendor

Nirmitee does not sell or host an openEHR CDR. We are an engineering partner that implements and integrates the repository you choose: modelling templates, building applications on the openEHR REST API, migrating legacy data, and connecting the CDR to the rest of the estate with FHIR, HL7 v2 and Mirth Connect.

• Engagement model: a CDR selection workshop, then delivery teams for integration, migration and application build.
• Best for: organisations that have chosen, or are choosing, a CDR and need the integrations and migration built around it, and product companies building on openEHR for the first time.
• Limitation: the repository licence, hosting SLA and product roadmap come from the CDR vendor, not from us.

Examples of that work: our HL7 v2 to openEHR integration with Mirth Connect and our guide to migrating a custom EHR schema to openEHR.

openEHR clinical data repository vendors in the UK and Europe

openEHR clinical data repository vendors active in the UK and Europe include Better (offices in Slovenia, the UK and Germany), vitagroup with EHRbase and HIP (Germany), DIPS (Norway), and Cadasto with CODE24 (Netherlands), with ArcEHR in private beta in Slovenia. The table shows the public UK and European programmes each is linked to.

Buying in the UK: openEHR configuration and integration services are listed on the Crown Commercial Service G-Cloud marketplace (for example this openEHR configuration and integration service), which gives NHS bodies a compliant route for services around a CDR. Check the current framework for the specific CDR product you want to buy, since listings change between framework iterations.

Catalonia's openEHR CDR: who built it and what it runs

Catalonia's openEHR clinical data repository was built by a joint venture of IBM and Viewnext, which won the Catalan government's CDR tender on 26 April 2023 for €8.5 million excluding tax over 30 months, and it transitioned to production on 30 November 2023, according to the award notice shared on the openEHR forum. The companies publicly named on the platform are IBM, Viewnext, vitagroup (HIP CDR and EHRbase 2.0), Kyndryl (infrastructure) and Yugabyte (database), per vitagroup and Yugabyte.

• Scale: a region of more than 8 million people, with 13 million electronic health records migrated from existing systems. vitagroup describes the infrastructure as complete, with integration into clinical care delivered in later phases.
• Service levels: 95th percentile targets of 40 milliseconds for queries and 60 milliseconds for writes, set in the tender.

For buyers, Catalonia is the clearest public example of the open source core plus enterprise distribution model at regional scale, and of writing measurable performance targets into a CDR procurement.

Open source vs commercial openEHR CDR

An open source openEHR CDR gives you code access, no licence fee and freedom to host anywhere, in exchange for running it yourself or buying support. A commercial CDR gives you a supported product, usually with tooling and managed hosting, in exchange for licence cost and dependency on one vendor's roadmap.

Full-stack platform vs CDR-only

A full-stack platform bundles the CDR with modelling tools, form builders, application builders and often a FHIR store; a CDR-only product gives you the repository and APIs and leaves the rest to you. Choose full-stack when clinical teams need to build forms and apps quickly with one vendor accountable. Choose CDR-only when you already have application teams, want to mix best-of-breed tools, or are building your own product on top.

Build, buy or self-host an openEHR CDR?

Very few organisations should build an openEHR CDR from scratch in 2026, because mature open source and commercial options already implement the Reference Model, template validation, versioning and AQL. The real choice is between self-hosting open source, buying an enterprise distribution, and buying a platform.

• Self-host open source when you have platform engineers, need code access, and can own upgrades and 24/7 operations.
• Buy an enterprise distribution when you want the open source core with a vendor on the hook for SLAs and enterprise features.
• Buy a platform when time to first clinical application matters more than infrastructure control.
• Build your own only if you are a platform vendor with a clear reason the existing servers cannot meet (for example a different storage engine, as ArcEHR and FerroEHR are exploring).

Testing vendor neutrality: your openEHR CDR exit strategy

openEHR makes the data portable, but an exit from a CDR still needs a tested plan for data, models, queries and applications. Test these four things before you sign, not when you want to leave.

1. Export every composition in canonical openEHR format (canonical JSON or XML) through the REST API or a bulk export, including all versions and audit data. Run a full export of your pilot data during evaluation.
2. Own your templates and archetypes in your own repository, not only inside a vendor's modelling tool.
3. Keep AQL portable. Avoid vendor-specific query extensions in production reports, or document every one you use.
4. Import the export into a second CDR (EHRbase is the usual test target because it is free) and compare record counts and a sample of query results. If this works in the pilot, the neutrality claim is real for you.

Our guide to archetype versioning in production covers how to keep models portable as they change, and why openEHR data is AI-ready explains why that portability pays off beyond exit.

A six-week openEHR CDR proof of concept

A six-week proof of concept, run the same way on two or three shortlisted CDRs, turns vendor claims into evidence you can put in a business case. This is the plan we use.

1. Week 1: scope and data. Pick three to five templates from a real service (for example vital signs, a lab result and a care plan), prepare synthetic patients at production-like volume, and write down the performance and security requirements.
2. Week 2: install and load. Stand up each candidate in the hosting model you will use in production, upload templates, and bulk-load compositions through the REST API. Record errors and how long loading takes.
3. Week 3: query. Run the AQL test pack and your own clinical questions; measure 95th percentile latency under concurrent load.
4. Week 4: integrate. Connect one inbound feed (for example HL7 v2 results) and one outbound FHIR use case, so you see the integration effort, not just the repository.
5. Week 5: operate and secure. Test backup and restore, upgrade to a new version, rotate credentials, review audit logs and run a basic penetration test.
6. Week 6: exit and decide. Export everything, import it into a second CDR, compare results, then complete the scorecard with all four roles.

Vendors that cannot support a structured proof of concept on these terms are telling you something about how the rest of the project will go.

Want to run this proof of concept with an experienced openEHR team? We plan it with you, build the test pack on your templates and run it against your shortlisted CDRs, so the decision rests on evidence. Book a CDR selection call.

A reusable openEHR CDR selection scorecard

Score each candidate from 1 to 5 on every criterion, multiply by your weight, and require a minimum score on the criteria you cannot compromise on. The weights below are the defaults we start workshops with; change them to match your programme.

Run the scorecard with four roles in the room: a clinical informatician, a solution architect, a security lead and procurement. Each role catches problems the others miss.

Twelve questions to ask every openEHR CDR vendor

The twelve questions below surface the differences between openEHR CDR vendors that datasheets hide. Ask them in writing and keep the answers in the evaluation file.

Free to share: you can use this image in presentations or docs with a link to this page.

1. Which releases of the Reference Model, ADL, AQL and the REST API do you implement, and which parts are not implemented?
2. Can we run our own conformance and AQL test suite against a trial environment?
3. What are your measured 95th percentile read and write latencies at our data volume, and can we reproduce them?
4. How are tenants isolated, and how is a tenant created, suspended and deleted?
5. How do you validate coded data, and which terminology servers do you integrate with?
6. Is FHIR native, a facade, or a mapping project, and who maintains the mappings?
7. Which authentication standards and audit log formats do you support?
8. Where is the managed service hosted, who operates it, and which certifications apply?
9. How does pricing scale, and what is included in each tier?
10. Which tools come with the platform, and which will we need to source separately?
11. How often do you release, how long is each version supported, and how are upgrades delivered?
12. Can we export every composition, version and audit record in canonical openEHR format, and have other customers done it?

Choosing an openEHR CDR: our recommendation by situation

• Regional or national programme with open source mandate: EHRbase, with an enterprise distribution (HIP) or a support partner for SLAs.
• Health system that wants one vendor for data, modelling and apps: a full-stack platform such as Better.
• Nordic hospital buying an EHR: DIPS Arena brings its own openEHR platform.
• Dutch or EU provider needing local certification: include Cadasto in the shortlist.
• Software company embedding a CDR in its product: EHRbase self-hosted, or a hosted backend such as Atomik; test the FHIR facade against your needs.
• Analytics-heavy team curious about graph and SQL on clinical data: track ArcEHR's public launch.

Whichever you pick, the integration work around the CDR usually costs more than the CDR. Our openEHR and FHIR architecture patterns show where that work sits.

Choosing an openEHR CDR, or already committed and need it connected to the rest of your estate? Our healthcare interoperability engineers integrate openEHR with FHIR, HL7 v2 and existing EHRs, and our healthcare product engineering teams build applications on top. Book a CDR selection workshop and we will run the scorecard with your team against your shortlist.