Data integration for Clinical Decision Support based on openEHR Archetypes and HL7 Virtual Medical Record
5th International Workshop on Process-oriented Information Systems in Healthcare (ProHealth’12) 4th International Workshop on Knowledge Representation for Health Care (KR4HC12) 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
MotivationClinical Decision Support Systems (CDSS) canpotentially 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
Guiding principles for PHR designComprehensive and intuitive data standard Ease mappings from Knowledge to Data by modelersData exchange carried out using standardservice-oriented interfaces 3
Possible standards: HL7HL7 Reference Information Model (RIM) of HL7 v3.x ISO/ANSI standard Can express any clinical informationHL7 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 CDSSClinical Document Architecture (CDA) XML standard Purpose: create and exchange clinical documents Structured content through entry element; conforms to the RIM 4
Possible standards: openEHR, CEN 13606openEHR Archetypes 2-level modeling: separation between clinical &technical design Clinical: represent and communicate semantics of clinical content Technical : information structure, data types, ref. modelISO/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 SpecificationOur considerations: we evaluate RIM and openEHR forthe semantic level, and rely on the fact that 13606: Proposes using a 2-level modeling approach Includes security considerations for accessing EHRs 5
Experiments: 5 examples, 11 data aspectsRepresent 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
Experiment resultsCustom openEHRarchetypes Good: UI derivation Bad: not standard like vMR Bad: K-D mapping hard! openEHR Pain archetype 9
Experiment results Observation-related Archetype following the vMR classes (openEHR) 10
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
Evaluation: best support Criteria RIM CDA vMR openEHR/vMR openEHRExpressiveness ++ ++ ++ ++ ++ (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 vocabulariesfunctionality (B)Security, privacy - - - - - & scalability (B) 12
Selection of standards: our proposalHL7 vMR model ideal to address the differentfront-end needsopenEHR archetypes conformant to vMR, idealto address back-end and front-end to back-endlinkOur solution will comply also with requirementsand standards of the European market using 2-level modeling approach and security guidelines of ISO/CEN 13606 13
Conclusions and Future WorkCustom archetypes are usually structured around aclinical 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 considerations Sustainable PHR design, portable to many clinical domainsFuture Work: Check proposal with real GDM and AF guidelines New SOA version of KDOM (Peleg et. al 2008) connecting to openEHR middleware 14
Thanks for your attention! email@example.com 15
A particular slide catching your eye?
Clipping is a handy way to collect important slides you want to go back to later.