openEHR CDR selection guide: how to compare vendors and what to test
Once a team has chosen openEHR, the next decision is the clinical data repository that stores its compositions. Vendor sheets all claim the same features, so compare deployment models and evidence instead: which specification releases the CDR implements, how it behaves on your templates and data, and what you can take with you if you leave.
How do you compare openEHR CDR vendors before you sign?
Quick answer
An openEHR CDR vendor comparison should rest on tests, not feature lists: confirm the REST API release, AQL behaviour, template formats, version history, FHIR bridging and tenancy against your own templates, whether the repository is self-hosted or managed. Agnotic Technologies runs these proof-of-concept tests and builds the applications on the chosen repository.
| Criterion | Self-hosted CDR | Managed CDR |
|---|---|---|
| REST API release | Ask which ITS-REST release is implemented; 1.1.0 is the current release (July 2026). Run the System, EHR, Query and Definition calls on your install | Same question; run the same calls against a trial tenant with your own credentials |
| APIs still in development | Demographic and Admin APIs are marked development in ITS-REST; ask what the product offers instead | Same, plus which admin functions the provider exposes to tenants |
| AQL behaviour | Load your templates and sample data; run your own clinical queries with containment, ORDER BY and LIMIT; time them on your hardware | Run the same queries on the provider's tier you would buy, at your expected data volume |
| Template formats | Upload your ADL 1.4 operational templates and, if you model in ADL2, ADL2 templates through the Definition API | Same; ask how template versions are rolled out across tenants |
| Versioning and audit | Update a composition, then read its revision history and the version at a past time; check commit audit fields | Same; ask how long versions and audit data are retained |
| FHIR bridge | Is FHIR mapping part of the product or a separate service you run? Test one round trip with your profiles | Is it included, licensed separately or not offered? Test the same round trip |
| Terminology binding | Connect your terminology server and test validation of coded values | Ask which terminology services the provider connects to and who licenses them |
| Multi-tenancy | Your design: one install per tenant or a shared install with separation | Ask how tenants are isolated and how one tenant's data is exported or deleted |
| Conformance evidence | openEHR conformance specifications are still in development; ask for results against the Platform Conformance Test Schedule | Same; ask whether results are for the hosted version you will use |
| Exit and export | Data sits in your database, but test an export of compositions, templates and versions anyway | Test a full export of compositions, templates and version history before signing |
| HIPAA (US deployments) | Your safeguards on your infrastructure | A business associate agreement before the provider receives ePHI |
What they are
What is Self-hosted CDR
A self-hosted CDR runs in your own data center or cloud account, from an open-source project or a commercial licence. You own the database, upgrades, backups and security controls, and you can inspect the stored data directly.
What is Managed CDR
A managed CDR is run by a provider as a hosted service, with your organization as a tenant. The provider handles infrastructure and upgrades; you get API endpoints, credentials and a contract that covers uptime, support, data protection and export.
Key differences
Open-source or commercial when you self-host?
Both run in your environment; the difference is who stands behind the code. With an open-source project your team or a support contract handles fixes and upgrades. With a commercial licence the vendor does, on its release schedule. Compare the support terms and the upgrade path as carefully as the feature list.
What does a managed CDR change for compliance?
A provider that creates, receives, maintains or transmits ePHI for you is a business associate, and HIPAA requires a business associate agreement before it receives that data (45 CFR 164.502(e)). Ask for the agreement, the hosting region, the backup policy and the breach process during the comparison, not after you choose.
Why test AQL on your own data?
The Archetype Query Language specification, QUERY Release 1.1.0, is marked stable, so two repositories should accept the same query text. How fast and how completely each one answers depends on the implementation and your templates. A query that looks fine on demo data can behave very differently on deep containment paths across years of compositions.
Which template formats must the repository accept?
The ITS-REST Definition API has separate endpoints for ADL 1.4 operational templates and for ADL2 templates, plus stored queries. Check which format your modelling tools export, confirm the repository accepts it through the matching endpoints, and upload your real templates rather than the vendor samples.
What does conformance evidence look like today?
The openEHR Conformance component, with its Conformance Guide, Platform Conformance Test Schedule, Platform Profiles and Conformance Certificate, is marked as development. Treat a vendor's conformance claim as a statement to verify: ask which test schedule version it ran, which profile it targeted and whether you can rerun the tests.
When to use each
When to use Self-hosted openEHR CDR
- You need the data in your own cloud account or data center for policy or residency reasons.
- Your team can run a database-backed service with on-call, patching and backups.
- You expect to extend the repository or tune queries at the database level.
- You want to avoid a provider's upgrade schedule deciding when your API changes.
When to use Managed openEHR CDR
- You want a working repository for a pilot without building an operations team first.
- You run several products or clinics and want tenant isolation handled by the provider.
- The provider will sign a business associate agreement for ePHI in a US deployment.
- You accept the provider's upgrade cadence in return for less operational work.
How do you run an openEHR CDR proof of concept?
1. Pick three real templates. Choose ones your product will use in its first release, such as a vital signs, an encounter and a problem list template, and bring sample data for each.
2. Write ten queries you will actually run. Include a patient summary, a cohort count and a longitudinal trend. These become your AQL test set for every candidate.
3. Run the same script on each candidate. Create an EHR, commit compositions, update them, read revision history, run the queries and export everything. Record what failed and what needed vendor help.
4. Test the FHIR edge. Map one template to your FHIR profiles and back. For the standards question itself, see our FHIR vs openEHR guide.
5. Test the exit. Export compositions, templates and version history, then load them into a second repository. If you cannot, you have found your lock-in.
6. Decide on evidence. Score each candidate on the table above with what you observed, then let support terms, hosting and cost decide between the ones that passed.