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