This document provides an overview of the openEHR CDR open source project called EHRbase. EHRbase aims to provide an open standard-compliant backend platform for electronic health records and clinical applications using the openEHR specification. It has a team of developers across multiple continents and uses modern development practices like Scrum and BDD. EHRbase provides a REST API and SDK for creating, querying, and managing openEHR objects in a clinical data repository, and also integrates with FHIR through a FHIR bridge. It is being used as the backend platform for a national COVID-19 system in Germany.

1. Open Source openEHR CDR
(https://ehrbase.org/)
Christian Chevalley, Khon Kaen, Thailand
christian@adoc.co.th

2. About me
● Born in Geneva, Switzerland
● Studied Physics and Computer Science
at Geneva University
● Worked for several blue chip companies
(HP, Sun Microsystems)
● Developed 5 commercial enterprise
systems for Finance and Healthcare
● Founded ADOC Software in 2009: a
Thailand based operation, BOI
supported
● Wrote EtherCIS in 2011
● Migrated EtherCIS to EHRbase in 2019

3. Project Background
● Major/Industrial Evolution of EtherCIS
● Team of 10 persons (https://github.com/orgs/ehrbase/people, +6 coming
soon) distributed on 3 continents (Asia, Europe, Latin America)
● Modern Development Methodology and Project Management
● Modern Platform Architecture (Springboot)

4. EHRbase Mission Statement
● Open source backend for clinical application systems and electronic health records (ASL2.0)
● Based on the openEHR specification
● Aims to bring down barriers for vendors, hospitals, national programs and others to adopt open standards and
thereby foster the establishment of semantic interoperability.
● Be an alternative to proprietary platform products or self-development: EHRbase gives organizations a
modern, standard-compliant and bedrock-solid foundation for their mission critical business operations and
their next generation eHealth solutions.
● EHRbase provides the backbone for data-driven medicine and interoperable app ecosystems in 21st century
healthcare systems around the globe.
● Able to serve as foundation for complex, full-blown clinical application systems like electronic prescription or
patient data management systems within intensive care units
● Bootstrapping next generation healthcare applications is easy:
○ through a clear REST interface,
○ comprehensive documentation with plenty of examples,
○ good tooling and model-driven application development approach of openEHR,
○ develop prototypes within minutes. Changes in the data models can be directly consumed from
EHRbase during runtime, allowing the needed agility to keep up with ever changing requirements.

5. Project Governance
● Hanover Medical School (https://www.mhh.de/en/)
● Vitasystems Gmbh (https://www.vitagroup.ag/de_DE/Ueber-
uns/vitasystems)
● HiGHmed Medical Informatics (https://highmed.org/), sponsored by:
○ German Ministry of Education and Research (https://www.bmbf.de/en/index.html)
○ Medical Informatics Initiative Germany (https://www.medizininformatik-
initiative.de/en/about-initiative)
● Open Source Governance

6. Methodology: Behavior Driven Development

7. Methodology: Scrum Approach
Sprint EHRbase
Duration: 2 weeks

8. Methodology: Tool Chain
● General Project Planning: Confluence
● Story/Issue Tracker: GitHub
● Development: Java 11, jOOQ, Archie, SQL
● Test Automation, Continuous Integration: Robot, Circle CI
● Load Testing: jmeter
● Quality Checking: Sonar Analysis (sonarcloud.io)
● Code Peer Review
● Packaging/Releasing: Maven Central, Docker
● Communication: Slack
● HiGHMED CKM: https://ckm.highmed.org

9. Platform Architecture

10. EHRbase Platform Context

11. EHRbase Server
● Secure REST API (OAuth2)
● Performs openEHR object transactional CRUD operation w/validation
● Queries openEHR objects (AQL)
● Maintains local knowledge models
● Data Centric Architecture
○ Minimize Code
○ Maximize Data
○ -> Easier to Maintain
○ -> Easier to Debug
● Compliant with openEHR latest specifications
○ REST API Specification (https://specifications.openehr.org/releases/ITS-REST/latest/ehr.html)
○ RM (https://specifications.openehr.org/releases/RM/latest/index), Not supported yet (in progress):
■ Demographics
■ Extract
■ Integration Package
○ AQL w/FHIR Terminology Service
○ DIRECTORY, CONTRIBUTION, VERSIONED OBJECT
○ Canonical XML, canonical JSON

12. EHRbase SDK
● Handles knowledge representations (templates)
● Convert templates to POJOs classes to ease client implementation
● Provide EHRbase client API endpoints using JAVA methods
○ EHR
○ Template
○ Composition
○ Querying (AQL builder)
○ Directory
● Supports serialization and validation of openEHR objects
● Generates REST API payload

13. EHRbase SDK: Creating and Storing a Composition
// Initializing a new Composition
EhrbaseBloodPressureSimpleDeV0Composition composition = new
EhrbaseBloodPressureSimpleDeV0Composition();
// Adding values
[...].setSystolicMagnitude(120.0);
[...].setSystolicUnits("mm[Hg]");
[...].setDiastolicMagnitude(120.0);
[...].setDiastolicUnits("mm[Hg]");
// Committing and altering the object with the response data
client.compositionEndpoint(ehrId).mergeCompositionEntity(composition);
// For instance, the specific Version UID can now be accessed
composition.getVersionUid();

14. FHIR-Bridge
● Based on EHRbase SDK
● Capture FHIR profiles and convert them as openEHR RM objects (based
templates)
● Processing
○ Identify mapping between FHIR profile and openEHR template(s)
○ Generate respective template(s) SDK classes (POJO)
○ Implements resolution FHIR -> openEHR programmatically
■ Scan FHIR profile (json)
■ Wire FHIR value points to openEHR composition DataValues (multiple compositions
might be created depending on UC)
■ Resolve context (subject, clinical context etc.)
○ Perform translation, store in CDR

15. Link with FHIR Terminology Service
Based on AQL MATCHES operator:
SELECT o/data[at0002]/events[at0003] AS systolic FROM EHR [ehr_id/value='1234']
CONTAINS COMPOSITION c CONTAINS OBSERVATION o [openEHR-EHR-
OBSERVATION.blood_pressure.v1] WHERE c/archetype_details/template_id/value
matches {'Flormidal', INVOKE(https://r4.ontoserver.csiro.au/fhir/ValueSet/942e1d78-
d481-416f-bebd-5754ba4d0b69/$expand/),
'Kloralhidrat'}
Invocation format discussed at:
https://openehr.atlassian.net/wiki/spaces/spec/pages/624754994/Terminolog
y+Server+Invocation+in+AQL+SEC+proposal

16. Operation
● Deployment
○ Standard Java Application (e.g. java -jar ...)
○ Docker (https://hub.docker.com/r/ehrbaseorg/ehrbase)
● An Admin Console is in progress for general administrative tasks

17. National COVID-19 Platform
The German Federal Ministry of Science and
Education provides a funding of 150M € to help
tackle the CORONA crisis.
Target: Establishment of a national platform that
should process data from all German university
hospitals
Covers:
● A national clinical registry for COVID
● A COVID self-assessment application
● The HiGHmed Smart Infection Control
System (SMICS)
● COVID Risk Assessment App for
hospitals

18. CORE Platform Dashboard