This document discusses clinical information modeling and interoperability. It introduces openEHR, a two-level modeling approach using archetypes and templates to define clinical information. OpenEHR aims to support app development through a shared information model and democratize healthcare standards development. The document also discusses challenges with mismatched clinical models, the need for a shared platform and information standard, and an evolutionary approach to standards development involving clinical stakeholders.

1. Ian McNicoll
openEHR: Clinical
information modelling
Co-chair openEHR
openEHR rep. INTEROPen

2. Anatomy of an app
User interface (the app itself)
Information model
Database

3. the ‘information model’?
Any definition of the structure and
content of information that should
be collected or shared
A ‘minimal dataset’
A message or interface definition
Internally every application has
some kind of information model
Sharing information requires
developing shared information
models

4. Mismatched clinical information models

5. Megasuite + feral apps
User interface
Information model
Database

6. idea 1- ‘the platform’
‘free the data’
In the future the organisation or company that handles
your health datastore will be separate from the
company or organisation that build your applications.

7. idea 2
‘commoditise data
handling’
Handling healthcare data is a specialist activity.
In the future health data-handling will be provided as a
service by a variety of providers working to a common
standard

8. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQLVendor-neutral Information model

9. Vendor-neutral Content to support apps

10. idea 3
‘democratise
healthcare standards
development’
Healthcare providers must play a leading role in the
definition of healthcare information standards
but this is an evolutionary process

11. Stakeholders in control

12. openEHR - Two-level modelling

13. openEHR: Archetypes
open source computable models
of discrete clinical concepts
Familiar components of a health
record
Blood pressure, Body weight
Medication order, Family history
Urea, Creatinine results
‘Maximal dataset’
Capture as many clinical
perspectives as possible

14. openEHR: Templates
Templates deliver the datasets
by aggregating archetypes
together
Key clinical endpoint and start
point for generation of technical
artefacts
i.e. openEHR archetypes and
templates can be used directly
Class libraries, Message schema
GUI skeletons, API Profiles

15. Archetype re-use
Oximetry
Issue
Weight
Blood Pressure
HbA1c
Assessment
Template underpinning application Template underpinning application
Archetypes
used in template

16. New openEHR archetype/template tooling

17. Healthcare Information Standards Process
#FAIL
Clinical stakeholders engage
through top-down
governance
Committee-based
Late vendor engagement
Fixed review cycles
Unclear / unresponsive change
request mechanism
a

18. my ACP / RESPECT

19. CKM: Social media ‘standardisation’

20. Clinical Content Components

21. Web-based ‘democratised’ collaborative
review

22. Evolutionary standardisation
‘distributed Governance’
Implementers
Secondary
endorsement

23. Playing (nicely) with FHIR

24. Playing nicely with SNOMED-CT

25. Evolutionary standardisation
Sharing of structured, coded actionable information
between different applications (users)
’Semantic interoperability’
a grand plan of logics, linguistics and philosophy
‘Evolutionary standardisation’
wrangling enough computable meaning out of a horrible
mess to make useful progress
Innovation <> standardisation