Embed Size (px)
Citation preview
1
Towards the Implementation of an openEHR-based Open Source EHR
Platform(a vision paper)
Ing. Pablo Pazos Gutié[email protected]
2
What we know *
Lots of EHR Systems are designed in a monolithic way, preventinginformation (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
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
EHR PlatformProposed Reference Architecture
defining purpose, components, responsibilities,interfaces (services) and dependencies,
to support any clinical information system
5
EHR Platform Architecture
reusing components and servicesto build you own apps and systems
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
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
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
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
Long Term Maintenance• Based on the openEHR dual-model
– More info:• http://informatica-medica.blogspot.com/2015/08/openehr-y-el-modelo-du
al.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
Long Term MaintenanceKnowledge Management
same idea for queries, rules, ...
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
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)
