EHRServer

Backend / Server

The Problem

Before there was an open-source reference implementation, building a clinically interoperable data repository based on openEHR meant two options: purchasing a proprietary system, or implementing the specification from scratch. Neither was realistic for small teams, university projects, or early-stage health startups. The openEHR specification is detailed and rigorous — implementing a conformant CDR is months of work even for experienced developers.

The absence of a working, deployable open-source CDR made it difficult to teach the standard in practice, run proof-of-concept integrations, or evaluate whether openEHR was the right architectural choice. There was nothing to point to and say: "Here is a working implementation you can run today."

Why We Built It

EHRServer started in 2012 as an internal CaboLabs project with two goals: validate our understanding of the openEHR specification by actually implementing it, and give our training students something real to work with during courses. If we were teaching openEHR, we needed an environment where students could observe the API, load compositions, and query live data — not just read diagrams.

Over time it grew into a fully functional CDR. We used it in university research projects, in health integration initiatives, and as the backend for early client proof-of-concept work. Other teams began using it independently. By the time we decided to release it publicly, EHRServer had become what we believe was the first known open-source implementation of a complete openEHR CDR globally.

Atomik is a refactoring of EHRServer — we removed multi-tenancy, added demographic data support, and redesigned several internals for production SaaS use. Everything we learned operating EHRServer in real environments informed how Atomik was designed and built. EHRServer remains available for teams that want to study the implementation or run a low-cost CDR for non-production work.

Widely used for openEHR education and training

EHRServer is the CDR behind many openEHR training programs and university courses. Its open-source nature and low setup cost make it the practical choice when students need a real server to run compositions against, inspect API responses, and see the openEHR data model in action.

Key Capabilities

What EHRServer implements and provides out of the box.

EHR and Contribution APIs

Implements the core openEHR service model APIs, allowing applications to create and manage patient EHRs, clinical compositions, and contributions in a specification-compliant way.

Multi-tenant architecture

Supports multiple organizations on a single deployment, each with isolated data, users, and template definitions. Suitable for shared research infrastructure or training environments.

Visual query engine and stored queries

Design queries visually using a built-in query editor, save them as stored queries, and execute them via the REST API. Enables structured clinical data retrieval without writing raw query syntax.

SNOMED CT integration

Integrates with a SNOMED CT terminology service to enable semantic queries — retrieve compositions by clinical meaning, not just stored values.

Administrative web console

Browser-based management interface for EHRs, templates, compositions, stored queries, users, and audit logs. Useful for hands-on exploration during development and training.

Cluster-ready deployment

Supports clustered deployments via a dedicated sync API, enabling high-availability configurations for environments that need redundancy without switching to a commercial product.