The document proposes a reference architecture for an open-source EHR platform based on openEHR standards. The platform would include components like a Knowledge Manager to maintain clinical metadata, an EHR Server for storing clinical records, a Demographic Server for patient data, and a Rule Engine for clinical decision support. These components would provide open APIs and reuse common clinical artifacts defined using openEHR to achieve maintainability, interoperability and flexibility. The goal is to define a modular, extensible platform that clinical systems can be built upon.

1. 1
Towards the Implementation of an
openEHR-based Open Source EHR Platform
(a vision paper)
Ing. Pablo Pazos Gutiérrez
pablo.pazos@cabolabs.com

2. 2
What we know *
Lots of EHR Systems are designed in a monolithic way, preventing
information (re)use, and generating silos of information.
Those EHRs unable to adapt & evolve, will be replaced in 5 .. 10 years.
* from observation and experience

3. 3
What can we do?
Design better EHR Systems by:
+ standardizing the Core Architectural Components
+ focusing on Maintainability, Information Standardization, Interoperability
+ providing a Standard set of Services and Open Specifications
* the openEHR specifications cover most of those items

4. 4
EHR Platform
Proposed Reference Architecture
defining purpose, components, responsibilities,
interfaces (services) and dependencies,
to support any clinical information system

5. 5
EHR Platform Architecture
reusing components and services
to build you own apps and systems

6. 6
Knowledge Manager
• Purpose:
– maintain all the metadata and semantic data definitions
• information models, archetypes, templates, terminologies, queries, rules, guidelines ...
• core for maintainability and interoperability
– make available those “artifacts” to other components and systems
• Services:
– create, modify (versioned), query and retrieve, sync KMs
• Standards:
– Information: openEHR IM, openEHR Archetypes, ADL, Operational Templates
– Terminology: SNOMED CT, ICD10, CIAP-2, ...
– Guidelines / Rules: openEHR GDL, ...
• Tools:
– openEHR Clinical Knowledge Manager
• http://ckm.openehr.org

7. 7
EHR Server
• Purpose:
– generic clinical data storage
– flexible data querying mechanism
– EHR audit (what, when, who, ...)
• Services:
– create & modify clinical records (commit, versioned)
– query & retrieve, sync EHRs
– might include or use a CPOE (order entry: medications, lab tests, etc.)
• Standards:
– openEHR Service Model (REST API), openEHR Information Model, openEHR
OPTs
– HL7 v2.x Order Entry (CH04), Obs. Reporting (CH07), Medical Records (CH09)
– HL7 v3 Medical Records Domain
– FHIR Clinical Resources
• Tools:
– CaboLabs EHRServer
• https://cabolabs-ehrserver.rhcloud.com/ehr-0.3

8. 8
Demographic Server
• Purpose:
– generic demographic data storage
– includes the MPI and HR
• Services:
– create, modify, query & retrieve, sync
– identity matching (candidate selection, deterministic & probabilistic algorithms)
– identifier cross-reference (e.g. != ids from != organizations for the same patient)
– people, roles, groups, organizations, addresses & contact data, ...
• Standards :
– openEHR Demographic Model
– HL7 v2.x Patient Administration (CH03), Personnel Management (CH15)
– HL7 v3 Patient Administration and Personnel Management Domains
– IHE PIX & PDQ Profiles
– FHIR Administrative Resources
• Tools:
– OpenEMPI
• http://www.openempi.org/

9. 9
Rule Engine
• Purpose:
– add logic to the EHR platform for Clinical Decision Support
• verify conditions, execute actions, send alerts, reminders, suggestions, ...
– rule evaluation uses clinical and demographic data
• using EHR & Demographic Services)
• Services:
– rule evaluation (execution) when certain events are fired (sync or async)
• e.g. new clinical document received by the EHR Server, if the document contains a lab
order, send a HL7 message to the lab system with the order.
• Standards:
– openEHR Guideline Definition Language (GDL)
– HL7 Arden Syntax
• Tools:
– Drools (Business Rules Management System)
• http://www.drools.org
– openEHR GDL (GDL Editor)
• https://github.com/openEHR/gdl-tools/wiki
– XML Rule Engine (proof of concept, release soon)
• http://www.slideshare.net/pablitox/xre-demo-presentation

10. 10
Long Term Maintenance
• Based on the openEHR dual-model
– More info:
• http://informatica-medica.blogspot.com/2015/08/openehr-y-el-modelo-dual.html
• Modification, customization and extension of the EHR Platform:
– done by adding new artifacts (by clinical domain experts, not IT professionals)
• archetypes, templates, queries, rules, terminologies, …
– or modifying existing ones
• always versioned
– the platform adapts to changes
• new clinical records with different structures
• new and historic data structures can be queried without changing the system
• we try to minimize modifications to software:
– source code and database schema doesn’t need to be modified
– no need to write new queries or stored procedures
• This is a low cost & long term solution to:
– Extends life cycle of the technology
– Minimize software updating iterations from weeks to hours

11. 11
Long Term Maintenance
Knowledge Management
same idea for queries, rules, ...

12. 12
Current Status
• EHRServer
– v0.3 deployed on the cloud (OpenShift)
• you can deploy it too!
• supports the openEHR Information Model
• works with openEHR Operational Templates (OPT)
– services
• commit (supports versioning)
• query (documents or data sets, JSON/XML)
– features
• query builder
• add new clinical record structures (OPT)
– next
• synchronization (HA, backup, scalability)
• security and multitenancy
• XML Rule Engine
– v0.1 under it’s way
• initial proof of concept filled expectations
• All open source!
– Please help us and contribute!

13. 13
Challenges & Vision
• Focus on a EHR Platform Core that can solve 80% of the use cases
• Build end-user products (the other 20%) using the platform quick and cheap
– Like an app store for healthcare
• Agree on the core artifacts and standards to model, manage and share
information (use open standards like W3C / IETF)
– Support different protocols and interchange formats
– Flexible syntactic interoperability
• Many implementations of the EHR Platform
– open specs, any vendor can implement
– sharing and reusing semantic artifacts and knowledge
– enable semantic interoperability
– like TCP/IP for the Internet and HTML for the Web
• We need to improve the way we work, design and develop EHR Systems, to
give the best of breed tools to our clinicians (focus on common solutions,
not on technology)

14. 14
Muito Obrigado
pablo.pazos@cabolabs.com
@ppazos
github.com/ppazos