Presentation is loading. Please wait.

Presentation is loading. Please wait.

openEHR Architecture Overview

Similar presentations


Presentation on theme: "openEHR Architecture Overview"— Presentation transcript:

1 openEHR Architecture Overview
Thomas Beale

2 What are we trying to do today?

3 Ultimate ICT goals To Compute with health information Cross-enterprise
Patient-centric Over time & technology changes

4 Ultimate ICT goals In particular:
X-enterprise patient care pathway tracking Decision support for doctors Business process analysis for provider orgs Business intelligence for payers & public health Medical research ‘study’ analysis Person-centred data analysis, ethically targetted marketing etc Integrate health data with social & educational media streams in patient-centred portals

5 Ultimate ICT goals While dealing with relentless change in
Medicine, esp. drugs, interactions, procedures... Information Care processes Patient needs Legislation

6 Getting there requires...
A ~change-immune semantic architecture, allowing meaning of information and healthcare process steps etc to be reliably defined convertability of information from proprietary / legacy sources to common formats computability of information by inferencing engines, decision support, business intelligence, using knowledge bases

7 Getting there requires...
A systems and services architecture defining groupings and access protocols enabling: Aggregation of information from source systems Varying levels of conformance, esp. for existing systems Incremental deployment Satisfying changing business needs

8 Assumptions A services architecture with no semantic underpinning can deliver: Human – human information transmission Very basic search facilities Limited computability, where information is already widely standardised, e.g. HL7v2 lab, ADT Some security / privacy support But not generalised patient-centric computability – can’t access the main economic potential

9 The clock is ticking... Today we are still creating peta-bytes of non- interoperable, non-computable health data Post-hoc ‘re-engineering’ of the data to make it computable is too expensive to be realistic We know this because medical research projects regularly burn their entire budget on data re-engineering

10 The semantic part

11 Historical Industry Structure
Write docs, create message specs docs Stds orgs + Professional bodies Msg specs terminology & SYSTEMS APPS Present’n PROVIDERS Buy (poor) Solutions DOCs & Patients ...use systems ... Write data specs, minimum data sets, schemas for DS, referral etc data dictionaries GOVs / MoHs ...consume documents and msg specs developers ... make up what they don’t understand VENDOR / INTEGRATOR ...manual XSD GUI code Proprietary form definitions

12 Historical Industry Structure
Stds orgs + Professional bodies DOCs & Patients GOVs / MoHs VENDOR / INTEGRATOR docs GUI Proprietary form definitions ...use systems Lock-in Chaotic, Expensive, non-computable & SYSTEMS APPS Present’n data dictionaries Poor interop- erability code terminology Ad hoc XSD Msg specs ...manual Expensive, low reuse Write docs, create message specs ... Write data specs, minimum data sets, schemas for DS, referral etc ...consume documents and msg specs developers ... make up what they don’t understand PROVIDERS Buy (poor) Solutions

13 openEHR approach terminology GUI Present’n Collaborative TDO
build archetypes & terminology that define their Information – e.g. via IHTSDO archetypes TOOL Stds orgs + Professional bodies terminology & Services APIs Present’n Platform PROVIDERS buy Solutions DOCs & Patients ...use systems ...build templates and issue as standards e.g. Discharge Summary templates TOOL GOVs / MoHs ...consume std templates and create their own, making OPTs developers build SOLUTIONS based on the platform VENDOR / INTEGRATOR Operational template TOOL templates XSD TDO GUI TOOLS Collaborative knowledge repository

14 Knowledge engineering
openEHR approach GUARANTEED SEMANTICS Stds orgs + Professional bodies DOCs & Patients GOVs / MoHs VENDOR / INTEGRATOR terminology GUI ...use systems Collaborative knowledge repository Open, reusable templates Operational template & SYSTEMS APPS Present’n Platform TOOL TDO Interop- erable archetypes templates XSD Easy Development Standard tools TOOLS TOOL TOOL TOOL build archetypes And terminology that define their Information – e.g. via IHTSDO ...build templates and issue as standards e.g. Discharge Summary ...consume std templates and create their own, making OPTs Cheaper, faster developers build SOLUTIONS based on the platform PROVIDERS buy Solutions Knowledge engineering Software engineering

15 The basic plan A general theoretical paradigm or framework
An architecture specific to the domain, including Actual specifications for formalisms, models etc Actual models

16 Flexible Semantic Architecture
4 levels of organisation of information sharing same semantics: The cognitive user interface – flexible approach to data capture and viewing The data capture sets for each event in a business process, e.g. patient journey through ED Standardised semantics of the data points in data capture sets Standardised data representation, enabling interoperability Standardised querying capability Standardised interface to terminology for inferencing … ‘BP’ must have the same meaning everywhere!

17 Levels of Semantic Organisation
Screen Forms - GUI 1:N Business-event specific data sets - Templates 1:N Terminology Interface Theme-based models of content - Archetypes 1:N Querying Data Representation and sharing - Reference Model

18 In other words…. It is not just about what is ‘on the wire’ between two systems…. A message-based approach to semantic interoperability will be largely deficient in the semantics of data capture, definition, re-use and querying. We must think about what is in the application ‘stack’

19 GUI & Templates The cognitive User interface: Different ways of
Presenting & Capturing the Same information Logical data-sets: Achieved by templates That re-use and Organise underlying Standardised data Points according to Business process event

20 Templates & Archetypes
Logical data sets: Templates – using only Selected items from a Number of archetypes Standardised models of The data: Achieved by archetypes Organised by topic, Independent of use

21 Archetypes and Reference Model
Standardised clinical models of the data: Archetypes – all based On same reference model Standardised technical representation of the data: The reference model – Enables interoperability

22 Why Current Health Information Systems don’t solve the problem
They have a form-builder Possibly a library of ‘elements’ And only SQL, against The proprietary database And a proprietary database

23 The openEHR framework Use-case specific data-set definitions
Defined connection to terminology Templates 1:N Terminology interface All possible item definitions for health Terminologies Archetypes Snomed CT ICDx ICPC 1:N Querying Portable, model-based queries Reference Model Defines all data

24 openEHR Archetype

25 AQL query SELECT com2/context/start_time/value as START_DATE, obs1/data[at0001]/events[at0006]/data[at0003]/items[at0004]/value/magnitude as SYSTOLIC, obs1/data[at0001]/events[at0006]/data[at0003]/items[at0005]/value/magnitude as DIASTOLIC, obs3/data[at0002]/events[at0003]/data[at0001]/items[at0004]/value/magnitude as PULSE_RATE, obs4/data[at0001]/events[at0002]/data[at0003]/items[at0004]/value/magnitude as RESPIRATORY_RATE.... FROM EHR e[ehr_id/value='f271cd26-23fc-43a1-b411-34cdadaea067'] CONTAINS COMPOSITION com2 [openEHR-EHR-COMPOSITION.encounter.v1] CONTAINS (OBSERVATION obs3 [openEHR-EHR-OBSERVATION.heart_rate-pulse- zn.v1] OR OBSERVATION obs1 [openEHR-EHR-OBSERVATION.blood_pressure-zn.v1] OR OBSERVATION obs4 [openEHR-EHR-OBSERVATION.respiration.v1] .... WHERE com2/name/value matches {'Vital functions', 'Respiratory assessment', 'Assessment scales'} AND obs9/name/value = 'PEF before' AND obs10/name/value = 'PEF after' AND com2/context/start_time >= ' T ' AND com2/context/start_time < ' T '

26 Properties - software Generated software Developed software
Consume Templates 1:N Terminology interface Terminologies Archetypes Snomed CT ICDx ICPC 1:N Querying Software core Reference Model

27 The architecture java C# etc terminology f re s e ts Template- based
Int’l archetypes terminology f re Nat’l / local archetypes Nat’l / local templates s e ts Template- based artefacts OPT Msg XSD DocXSD Reference Model GUI XML All data = same information model data canonical openEHR Querying

28 Evaluate inclusions, flatten constraint inheritance
The key... Is the operational template (OPT) – this is the joining point between the semantic specifications and deployable software artefacts that can be used by normal developers OPT s e ts Evaluate inclusions, flatten constraint inheritance

29 Key Outcomes Normal developers can engage – openEHR + Snomed become economic and ~quick Semantic connection exists between definitions and implementations  now we know what the meaning of data are, and DS and BI can work...

30 The openEHR framework Templates Terminology interface Terminologies
Archetypes Snomed CT ICDx ICPC 1:N Querying Reference Model

31 The reference model Will continue to grow, to accommodate process, workflow etc Data Structures Data Types Primitive types, Ids Security Participations Composition Audit Versioning EHR EHR Extract Demographics Party

32 The openEHR framework Templates Terminology interface Terminologies
Archetypes Snomed CT ICDx ICPC 1:N Querying Reference Model

33 The archetype architecture
Downsteam software artefact transformations Template model & serialisations Archetype Query Language (AQL) Archetype Object Model (AOM) Archetype Def. Language (ADL) Data Types Primitive types, Ids

34 Managing knowledge artefacts
Content models & terminology ref sets managed outside of software process & people Needs: Governance Methodology Identification Sharing and release rules etc

35 Key Outcomes We can now start to situate existing standards in the framework Concrete content-specific standards like HL7 message definitions, CDAs, CCRs etc are DOWNSTREAM generations and/or mappings of operational templates Meaning we can connect them into a semantic framework and potentially guarantee their semantics Rather than manually building them in a standalone fashion

36 data Tool-based standards Querying HL7v2 CDA XSD epSOS XSD 13606 XSD
java C# etc CDA XSD OPT Msg XSD Reference Model DocXSD epSOS XSD GUI XML re f s e ts terminology Querying 13606 XSD data

37 The Services Part

38 Security / access control
Old view… portal Allied health patient PAYER other provider Secondary users Enterprise HILS Msg gateway Imaging lab ECG etc Path lab LAB PAS billing Comprehensive UPDATE QUERY demographics guidelines protocols Interactions DS Local modelling notifications DSS Security / access control Basic EHR Multimedia genetics workflow Patient Record identity Clinical ref data models terms realtime gateway telemedicine Online drug, Interactions DB Online archetypes terminology Demographic registries

39 General approach Build from bottom up – ‘Native’ services
Needed services, consistent with information and model artefacts And from top-down – ‘Standard’ services Connect IHE, HSSP etc to native services

40 Services data Querying IHE Nat ive HSSP HL7v2 CDA XSD epSOS XSD
Reference Model OPT s e ts terminology f re GUI XML Msg XSD DocXSD data java C# etc Querying CDA XSD epSOS XSD 13606 XSD HL7v2 HSSP

41 Key elements that MUST WORK
Standardised querying of data, based on knowledge artefacts, not physical DB  standardised knowledge artefact identification, including versions  standardised ability to designate finest grain items in the data Enabling URI to any data item

42 Key elements that MUST WORK
Everything in openEHR relies on archetype paths, which are X-path compatible The two tests are being able to: Write portable queries Create URIs to finest grain of data

43 openEHR URI ehr: / D4B-4e3d-A3F3- content[openEHR-EHR-SECTION.vital_signs.v1]/ items[openEHR-EHR-OBSERVATION.heart_rate- pulse.v1]/data/events[at0006, 'any event']/ data/items[at0004]

44 Where paths come from

45 Conclusions

46 Basic premise If we want to share and compute with health data at any level of detail, we need a knowledge-based architecture

47 Architecture data Knowledge-enabled services Semantic underpinning
Nat ive IHE Semantic underpinning Reference Model OPT s e ts terminology f re GUI XML Msg XSD DocXSD data java C# etc Querying CDA XSD epSOS XSD 13606 XSD HL7v2 Connect to standards HSSP Model-based querying

48 Knowledge awareness means...
Service layer understands: knowledge artefact identification system Fine-grained data item identification Which means we need standardised knowledge models Aka Detailed Clinical Models

49 The ultimate test If you can create a URI to ‘my instantaneous resting, lying down systolic BP, recorded 7/jan/2011’ then you can communicate at any level of detail about health information If you can share the URI, we have all the information standardisation we need

50 openEHR summary Semantic coherence in the application stack (all layers of software know what the data mean) A high level of re-use of artefacts – define once, reuse many times A single, stable reference model for sharing clinical and related information A standardised query language for writing portable queries A standardised, re-usable way of connecting to terminology

51 It’s all about the framework


Download ppt "openEHR Architecture Overview"

Similar presentations


Ads by Google