Upload
arturo-gonzalez-ferrer
View
682
Download
1
Embed Size (px)
Citation preview
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