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

Thanks for your attention!

arturogf@gmail.com

www.mobiguide-project.eu

15