1. 5th International Workshop on Process-oriented Information Systems in Healthcare (ProHealth’12)
4th International Workshop on Knowledge Representation for Health Care (KR4HC'12)
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)
Tallinn, Estonia – September 3rd, 2012

2. Motivation
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)
EMR1
PHR CIG
EMR2 Knowledge-Data
mapping
CIG
BAN KB
recommendations
CDSS
2

3. Guiding principles for PHR design
Comprehensive and intuitive data standard
Ease mappings from Knowledge to Data by modelers
Data exchange carried out using standard
service-oriented interfaces
3

4. Possible standards: HL7
HL7 Reference Information Model (RIM) of HL7 v3.x
ISO/ANSI standard
Can 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 needs
RIM-based model created for the purpose of developing CDSS
Clinical Document Architecture (CDA)
XML standard
Purpose: create and exchange clinical documents
Structured content through entry element; conforms to the RIM
4

5. Possible standards: openEHR, CEN 13606
openEHR Archetypes
2-level modeling: separation between clinical &technical design
Clinical: represent and communicate semantics of clinical content
Technical : information structure, data types, ref. model
ISO/CEN 13606 Multi-part standard
Part I: Reference Model
Part II: Archetypes Specification
Part III: Reference Archetypes and Term lists
Part IV: Security
Part 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 approach
Includes security considerations for accessing EHRs
5

6. Experiments: 5 examples, 11 data aspects
Represent the next examples with data standards:
EMR data (quantitative): HR result: 60bpm on 19/12/11
EMR data (qualitative): Brother of patient X has diagnosis of
“Myocardial Infarction” on 19/12/11
BAN 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 recommendations
Measure serum urea every 3 days
Hospitalize patient now
Perform echo umbilical 2-3 weekly
Give celestone 12mg 2 times a day every 24hr for 2 days
6

7. Experiment results
HR measurement (RIM) Substance Admin Proposal (VMR)
7

8. Experiment results
HR measurement (CDA)
8

9. Experiment results
Custom openEHR
archetypes
Good: UI derivation
Bad: not standard like vMR
Bad: K-D mapping hard!
openEHR Pain archetype
9

10. Experiment results
Observation-related Archetype following the vMR classes (openEHR)
10

11. Evaluation Criteria
Back-end:
1. Where data is represented and stored
2. Mechanisms provided for data query and vocabularies
Front-end:
1. Data integration EMR-PHR
2. Conceptual link DSS-PHR, knowledge-data mapping
11

12. Evaluation: best support
Criteria RIM CDA vMR openEHR/vMR openEHR
Expressiveness ++ ++ ++ ++ ++
(B)
User-friendly Very generic No specific classes Good Custom-made
for conceptual ++ archetypes -> lack
(F) recommendations, model for CIG static structure
created to data. Similar to
exchange clinical EMR model,
notes enables
hospitals to use
our system.
Link Backend V2.x/CDA to High flexibility for
vMR guidelines,
++ adaptations, 13606
and Frontend knowledge-data compliant
(B/F) mapping easier
Easy to high learning curve, Good easy to extend
complex documentation
++
represent and easy to learn
extend (B)
Semantic Depends on Xpath / Xquery Depends on AQL; ontology
implementation implementation
++ section for
integration vocabularies
functionality (B)
Security, privacy - - - - -
& scalability (B)
12

13. Selection of standards: our proposal
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
13

14. Conclusions and Future Work
Custom archetypes are usually structured around a
clinical concept and combined using templates
To support domain-independent CIG-based CDSS,
we propose to make archetypes vMR-compliant
Support of front-end and back-end considerations
Sustainable PHR design, portable to many clinical domains
Future Work:
Check proposal with real GDM and AF guidelines
New SOA version of KDOM (Peleg et. al 2008) connecting
to openEHR middleware
14

15. Thanks for your attention!
arturogf@gmail.com
www.mobiguide-project.eu
15