openEHR Architecture
Dr Hugh Leslie
HIMSS AsiaPac 09 – February 26th 2009
Imagine a world where… . Your health information was available safely and securely everywhere it was needed . Health information was lifelong and future proof . Computers could reliably process clinical information from anywhere for decision support . Health information could be easily used to improve quality and reduce costs in Health systems
Session 1 The openEHR Architecture 1 openEHR Architecture
XML CEN 13606 ASTM E2369-05 (CCR)GALEN LOINC RIM Templates Archetypes XFORMS ISO/TS 18308:2004 SNOMED CT Navigating the ICD9/10 openEHR Health Informatics JungleDMIM IHE profiles SOA DICOM HL7 version 3 Google PHR
CCOW HSSP Clinical Document Architecture (CDA)
CDISC HIPAA
The Standards Solar System
Read
UML LRA
SNOMED SCG V3 HL7 V2 ICD10
CDS CFH tinua Data con OPCS Dictionary
OHT openEHR
EHR IHE ISO Data Types
Session 1 The openEHR Architecture 2 openEHR Architecture
data REALITY phenomena
Ontologies of Everything 001101010 010101001 Ontologies of Information Ontologies of Reality 011110101 Process Classification 011010010 Descriptions Templates Antenatal visit 101010100 AN guideline 111101001 ICPC 100101001 mediate guidelines 100010011 Archetypes BP measurement ICD10 001010011 010101011 Information Models Description 000000000 CEN 13606 IM 000000000 Galen Observation vocab 000000001 openEHR HL7 V3 RIM Diagnoses 111111111 SNOMED‐CT 111100100 Type Systems String 000000000 000000000 Integer Object Attribute
Languages for Models & Ontologies OWL DLs UML OOPLs ADL F‐logic
Standards v. Specifications
Standards Specifications . ANSI or ISO process . Community . Inclusive . Controlled by expert group . Sale of standard . No business model . National or international . International . Documentation template . Process to suit product . Balloting . Cohesive group with clear . Risks: aims Compromise without technical . Risks basis Irrelevant Meeting stacking Not sensitive to needs
Session 1 The openEHR Architecture 3 openEHR Architecture
13606 ‐ standard
. ISO and CEN Developed by committee meeting every 3 months Enthusiasts Academics Industry Based on past work Theoretical Balloted Political process
openEHR ‐ specification
. Develop by enthusiasts collaborating on web Academics, Engineers, Industry . Implementation trials . Engineering processes Change request Expert group decides changes
Session 1 The openEHR Architecture 4 openEHR Architecture
What do we need?
What do we need?
Information Models • Ensure interoperability – • Non proprietary and generic • Handle data like dates, times, quantities, numbers etc • Single schema for data consolidation • Basis for content specification
Information Models
Session 1 The openEHR Architecture 5 openEHR Architecture
What do we need?
Terminologies • Provide the link to real things in the world and relationships between those things • What data points need to be coded • Enable safe processing of data for decision support, application functionality • National reporting Terminology • Efficient data entry
Information Models
What do we need?
Content Specifications • Open, non proprietary • Accessible for domain experts • Mediate between IM and terminology • Single semantic model for producing software, schemas, gui, messages, queries
Terminology
Content Specifications
Information Models
Session 1 The openEHR Architecture 6 openEHR Architecture
What do we need?
A generic way to query the data • Automatic processing • Decision support • Consolidating information from different systems • Implementation independence Query
Terminology
Content Specifications
Information Models
What do we need?
Messaging Messaging simplification • Automatic generation of messages from semantic content • Methods for integrating data from messages and producing multiple outputs Query • Reduced integration cost and complexity Terminology
Content Specifications
Information Models
Session 1 The openEHR Architecture 7 openEHR Architecture
What do we need?
Messaging An EHR that is • Independent of implementation technology EHR • Independent of clinical system developer • Enables access to multiple clinical Query applications • Designed for longevity and re-use Terminology
Content Specifications
Information Models
“On the one hand, full semantic interoperability cannot be reached without a clear sharing of roles between reference model, archetypes structure and terminology which are all necessary. On the other hand, when one of the components is claiming its ability to produce full semantic interoperability alone or under the condition that the two other components conform to its needs, as it has been proposed very often in the past and still in the present, then the goal of full semantic interoperability cannot be reached.”
R E S E A R C H A N D D E P L OYM E N T R O A D M A P F O R E U R O P E
S ema n t i c H E A LT H R e p o r t, European Commission J a n u a r y 2 0 0 9
Session 1 The openEHR Architecture 8 openEHR Architecture
What do we need?
Messaging
Terminology
openEHR Information Model
• Structure • Security • Versioning • People, Dates, Times, Data types
Session 1 The openEHR Architecture 9 openEHR Architecture
The openEHR information model – structure of one EHR
EHR EHR EHR Access AccessAccess EHR EHR EHR Contribution Access Contribution StatusAccess Contribution EHR Contribution EHR_ID Contribution EHR Access DirectoryEHR Access
… … … EHR Access EHR Access EHR Access EHR Access… … EHR Access… … EHR Access… …
… … … … … … … … … Composition Composition Composition
Structure of one Composition Versioned Composition
Composition Section Observation Elements are the leaf Section Observation nodes which contain Observation things like Text, Coded
Action Text, Quantity, Boolean, Ordinal etc Instruction
Observation Cluster History Event Cluster Entries ‐ Element where the Event Element Data are Item_list Element
Session 1 The openEHR Architecture 10 openEHR Architecture
Security Features
Demographics
EHR EHR EHR EHR EHR EHR EHR Access AccessAccessParties AccessAccessParties AccessAccess EHR EHR EHR Access EHR StatusAccess Separation EHR_ID EHR Access DirectoryEHR Access Contribution Contribution Contribution Contribution Contribution
… … … EHR Access EHR Access EHR Access EHR Access… … EHR Access… … EHR Access… …
… … … … … … … … … Composition Composition Composition
= Digital Signature = Commit Audit
Distributed versioning
EHR System A (cache)
v1 v3 v2 EHR Centre 2
v1 v3 v2 EHR Centre 1
EHR v1 v3 v2 System B (cache) EHR System C v1 v3 v2 (cache) v1 v3 v2
Session 1 The openEHR Architecture 11 openEHR Architecture
openEHR Content Models
Archetypes and Templates (+ terminologies)
openEHR Archetypes
Session 1 The openEHR Architecture 12 openEHR Architecture
LEGO® design analogy
RM components = individual LEGO bricks Archetypes = instructions for creation of meaningful structures
Reference Model
Archetype A Archetype B
Archetypes put the clinician in the driver’s seat!
Session 1 The openEHR Architecture 13 openEHR Architecture
Session 1 The openEHR Architecture 14 openEHR Architecture
Archetypes and Templates
Archetypes Diabetic checkup Antenatal visit Issue Tingling feet Back pain Feeling tired Weight 66 kg 76 kg BP 102/64 mmHg 124/92 HbA1c 7.5% 142/min FH
Excellent control Assess NAD, see 4/52
Session 1 The openEHR Architecture 15 openEHR Architecture
The openEHR artefact ecosystem
Code Skeletons UI Forms
Data Reference Archetypes Templates Sets Model
XML Messages Schemas
Terminology Semantic Mappings/ HTML Subsets Queries Display
Session 1 The openEHR Architecture 16 openEHR Architecture
The universal EHR
HL7v2
HL7v2 XML (archetyped)
CDAr2 Clinical PDF (text) Archetypes CDAr2 (structured) CDAr2 (generated) CCR/CCD openEHR (structured) Repository 13606 13606 Extract Extract openEHR openEHR Extract Extract
Standard queries
Before I can query I need to know: Database type • SQL dialect • Specific data Blood Pressures structures Systolic 120 135 160 140 Diastolic 80 87 97 78
Session 1 The openEHR Architecture 17 openEHR Architecture
openEHR queries
Before I can query I
only need to know: EHR • What information do I want? Folder
• i.e. All BPs in this Antenatal GP Home visit encounter monitoring BP= 120/80 BP = 135/78 EHR BP = 145/90 mmHg mmHg mmHg lying sitting sitting
openEHR Queries
Archetype Query Language • independent of data structures • independent of systems • independent of language • portable queries possible • works with terminology for inferencing
Session 1 The openEHR Architecture 18 openEHR Architecture
AQL Query example – all BPs
SELECT o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value as systolic, o/ data[at0001]/events[at0006]/data[at0003]/items[at0005]/value as diastolic FROM EHR CONTAINS COMPOSITION CONTAINS OBSERVATION o [openEHR-EHR- OBSERVATION.blood_pressure.v1] WHERE o/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude > 150
openEHR and Terminology . Archetypes NEED terminology and terminologies NEED Archetypes . Archetypes provide a context for terminology so that clinicians can reliably use it. . Archetypes provide dates, times, and related things about a concept . Terminology (ie SNOMED) provides the controlled vocab and relationships that are needed for inferencing.
Session 1 The openEHR Architecture 19 openEHR Architecture
Who is using it?
. Primary care/Office . Registry/Research StatHealth (Australia) Cancer Council of Victoria McCauley Software (Australia) (Australia) . Regional clinical CHIME (UK) repository Zilics (Brazil) Extensia (Australia) . Hospital Queensland Health Cambio (Sweden) Division of General Practice Unusu@lvisions (Netherlands)
Session 1 The openEHR Architecture 20 openEHR Architecture
Who is using it? . Connecting for Health (UK) Clinical data specifications . Connected Digital Health in Denmark Clinical data specifications for import into vendor systems Specification of terminology use Message schema . Swedish National Board of Health Basis for national program . IHTSDO – in discussions
Imagine a world where… . Your health information was available safely and securely everywhere it was needed . Health information was lifelong and future proof . Computers could reliably process clinical information from anywhere for decision support . Health information could be easily used to improve quality and reduce costs in Health systems
Session 1 The openEHR Architecture 21 openEHR Architecture
Session 1 The openEHR Architecture 22