Maybe you already have these components in your system, maybe they are coupled and are not independent, maybe their roles, responsibilities and interfaces are not 100% defined. We will see each component in detail.
Computerized Physician Order Entry
Demographic server is separated from the EHR server for security and to allow clinical information reuse
Is like an extension point for the EHR Platform http://www.jessrules.com/docs/71/xml.html http://www.easyrules.org/ Variable resolution: when the rule references a concept and the value of that concept should be established when evaluating the rule, for example if the rule references “blood pressure”, we need the value.
Extension: for example you will need more clinical documents, or update current ones to add or remove fields.
technical and methodological challenges
Towards the Implementation of an openEHR-based Open Source EHR Platform (a vision paper) - #MedInfo2015
Towards the Implementation of an
openEHR-based Open Source EHR Platform
(a vision paper)
Ing. Pablo Pazos Gutiérrez
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
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
Proposed Reference Architecture
defining purpose, components, responsibilities,
interfaces (services) and dependencies,
to support any clinical information system
EHR Platform Architecture
reusing components and services
to build you own apps and systems
– 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
– create, modify (versioned), query and retrieve, sync KMs
– Information: openEHR IM, openEHR Archetypes, ADL, Operational Templates
– Terminology: SNOMED CT, ICD10, CIAP-2, ...
– Guidelines / Rules: openEHR GDL, ...
– openEHR Clinical Knowledge Manager
– generic clinical data storage
– flexible data querying mechanism
– EHR audit (what, when, who, ...)
– create & modify clinical records (commit, versioned)
– query & retrieve, sync EHRs
– might include or use a CPOE (order entry: medications, lab tests, etc.)
– openEHR Service Model (REST API), openEHR Information Model, openEHR
– HL7 v2.x Order Entry (CH04), Obs. Reporting (CH07), Medical Records (CH09)
– HL7 v3 Medical Records Domain
– FHIR Clinical Resources
– CaboLabs EHRServer
– generic demographic data storage
– includes the MPI and HR
– 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
– 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)
– 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.
– openEHR Guideline Definition Language (GDL)
– HL7 Arden Syntax
– Drools (Business Rules Management System)
– openEHR GDL (GDL Editor)
– XML Rule Engine (proof of concept, release soon)
Long Term Maintenance
• Based on the openEHR dual-model
– More info:
• 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
Long Term Maintenance
same idea for queries, rules, ...
– v0.3 deployed on the cloud (OpenShift)
• you can deploy it too!
• supports the openEHR Information Model
• works with openEHR Operational Templates (OPT)
• commit (supports versioning)
• query (documents or data sets, JSON/XML)
• query builder
• add new clinical record structures (OPT)
• 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!
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)