Data integration for Clinical Decision Support based on openEHR Archetypes and HL7 Virtual Medical...
-
Upload
arturo-gonzalez-ferrer -
Category
Documents
-
view
682 -
download
1
Transcript of Data integration for Clinical Decision Support based on openEHR Archetypes and HL7 Virtual Medical...
Data integration for Clinical Decision Support
based on openEHR Archetypes and HL7 Virtual Medical Record
Arturo González-Ferrer (University of Haifa),
Mor Peleg (University of Haifa),
Bert Verhees (ZORGGemak),
Jan-Marc Verlinden (ZORGGemak),
Carlos Marcos (ATOS)
5th International Workshop on Process-oriented Informat ion Systems in Healthcare (ProHealth’12)4th International Workshop on Knowledge Representation for Health Care (KR4HC'12)
Tallinn, Estonia – September 3rd, 2012
Clinical Decision Support Systems (CDSS) can potentially support patient-centric care
Paradigm: evidence-based system Users: clinical staff, patients and researchers Computer-interpretable Guidelines (CIGs)Integrated Personal Health Record (PHR)
Motivation
CIGPHREMR1
EMR2
BAN
Knowledge-Data mapping
CDSS
CIG
KB
recommendations
2
Comprehensive and intuitive data standardEase mappings from Knowledge to Data by modelers
Data exchange carried out using standard service-oriented interfaces
Guiding principles for PHR design
3
HL7 Reference Information Model (RIM) of HL7 v3.x ISO/ANSI standardCan express any clinical information
HL7 Virtual Medical Record (vMR)(Johnson AMIA 2001); ref. implementation in openCDS (Kawamoto)HL7 conducted an analysis of 20 CDSSs to identify data needsRIM-based model created for the purpose of developing CDSS
Clinical Document Architecture (CDA)XML standardPurpose: create and exchange clinical documentsStructured content through entry element; conforms to the RIM
Possible standards: HL 7
4
openEHR Archetypes2-level modeling: separation between clinical &technical design
Clinical: represent and communicate semantics of clinical contentTechnical : information structure, data types, ref. model
ISO/CEN 13606 Multi-part standardPart I: Reference ModelPart II : Archetypes SpecificationPart III: Reference Archetypes and Term listsPart IV : SecurityPart V: Interface Specification
Our considerations: we evaluate RIM and openEHR for the semantic level, and rely on the fact that 13606:
Proposes using a 2-level modeling approachIncludes security considerations for accessing EHRs
Possible standards: openEHR , CEN 13606
5
Represent the next examples with data standards:EMR data (quantitative ): HR result: 60bpm on 19/12/11EMR data (qualitative ): Brother of patient X has diagnosis of “Myocardial Infarction” on 19/12/11BAN data : HR waveform recorded every 5s, starting 8am 19/12/11
Abstraction : Tachycardia (HR>115) during interval 8:00-8:30 19/12/11
CDS recommendationsMeasure serum urea every 3 daysHospitalize patient nowPerform echo umbilical 2-3 weeklyGive celestone 12mg 2 times a day every 24hr for 2 days
Experiments: 5 examples, 11 data aspects
6
Experiment results
HR measurement (RIM) Substance Admin Proposal (VMR)
7
Experiment results
HR measurement (CDA)
8
Custom openEHR archetypes
Good: UI derivation
Bad: not standard like vMR
Bad: K-D mapping hard!
Experiment results
openEHR Pain archetype
9
Experiment results
Observation-related Archetype following the vMR classes (openEHR)
10
Back-end: 1. Where data is represented and stored2. Mechanisms provided for data query and vocabularies
Front-end:1. Data integration EMR-PHR2. Conceptual link DSS-PHR, knowledge-data mapping
Evaluation Criteria
11
Criteria RIM CDA vMR openEHR/vMR openEHR
Expressiveness (B)
++ ++ ++ ++ ++
User-friendly (F)
Very generic No specific classes for
recommendations, created to
exchange clinical notes
Good conceptual
model for CIG data. Similar to
EMR model, enables
hospitals to use our system.
++ Custom-made archetypes -> lack
static structure
Link Backendand Frontend
(B/F)
V2.x/CDA to vMR guidelines, knowledge-data mapping easier
++ High flexibility for adaptations, 13606
compliant
Easy to represent and
extend (B)
high learning curve, complex
Good documentationeasy to learn
++ easy to extend
Semantic integration
functionality (B)
Depends on implementation
Xpath / Xquery Depends on implementation ++ AQL; ontology
section for vocabularies
Security, privacy & scalability (B)
- - - - -
Evaluation: best support
12
HL7 vMR model ideal to address the different front-end needs
openEHR archetypes conformant to vMR, ideal to address back-end and front-end to back-end link
Our solution will comply also with requirements and standards of the European market
using 2-level modeling approach and security guidelines of ISO/CEN 13606
Selection of standards: our proposal
13
Custom archetypes are usually structured around a clinical concept and combined using templatesTo support domain -independent CIG-based CDSS, we propose to make archetypes vMR-compliant
Support of front-end and back-end considerationsSustainable PHR design, portable to many clinical domains
Future Work:Check proposal with real GDM and AF guidelinesNew SOA version of KDOM (Peleg et. al 2008) connecting to openEHR middleware
Conclusions and Future Work
14