1. Digital Health Assembly:
HOPD / openEHR workshop
www.handihealth.org
Dr Ian McNicoll
ian@freshehr.com
ian@handihealth.org
HANDIHealth
openEHR Foundation
freshEHR Clinical Informatics
Digital Health Assembly Cardiff Feb 2015
2. Introduction
• Dr Ian McNicoll
• Clinician
• Former Glasgow GP
• Health informatics
• Director HANDIHealth
• Director openEHR
Foundation
• freshEHR Clinical Informatics
• Commercial software developer
• ‘Clinical Hacker’
2
3. HANDIHealth CIC
• A not-for-profit Community Enterprise
Company
• There to support:
– Developers
– Health and care professionals
– Patients, service users and carers
4. HANDI is agnostic
• About
– Platforms
– Business models
– Standards
– Tools, services and approaches
• Show the community the possibilities and let individuals
decide
• Lobby for an environment (technical, cultural and
commercial) in which apps can flourish interoperate and
be orchestrated
5. The Holy Grail : eHealth ‘interoperability’
5
http://cyber.law.harvard.edu/research/interoperability
6. Interop:
Towards an Open Digital Care Ecosystem
Megasuite
Best of
Breed
Platform
Open
Ecosystem
“One system to rule them all”
• NPfIT
• Enterprise/GP Systems
• Limited external integrations
Many systems ~ 100
• Portals
• Integration engines
• Bespoke integrations
“Own the Platform”
• Health Vault, Apple, Lorenzo, etc
• ~1000 apps
• Partner interfaces (Woodcote L3)
The “Internet “of Digital Health
• HANDI-HOPD
• The Healthcare Services Platform
Consortium
7. An open Ecosystem platform?
Closed OSS ClosedOSS
Vendor DVendor B Vendor CVendor A
API and messaging content based on open
source clinical content definitions
OSS
components
Vendor
solutions
Terminology
Server Pathways KB
ESB/SpineITK Integration component
Commit
Retrieve
8. 8
SMARTPlatforms
Pluggable Webapp
API
HL7 FHIR
Clinical Content
Exchange NHS API
‘inVivo’
Datastore API
Detailed
Clinical Content
Development
Clinical leadership PRSB
Terminology
Centre
HSCIC
Non
openEHR
systems
Archetype+ SNOMED Clinical
Content definitions
Apps developers
13. What is FHIR good at?
• Communication of information between
systems with limited querying
• Strengths
• Developer friendly
• Lightweight approach
• Great documentation / community
13
14. Where might FHIR be weaker?
• Not designed for persistence
• can work but will it scale?
• partial querying only
• Resources will not work ‘out of the box’ in
the real world
• Need local extensions and profiles
• Version control / governance of the profiles
14
15. openEHR API
15
• Designed for storing and querying
rich clinical dataset
• New content is defined directly
by clinicians and can be immediately
uploaded into the clinical data repository
• Vendor-neutral data models
Technology-neutral data models
• Vendor-neutral data querying
Technology-neutral data querying
24. What IS openEHR?
• NOT a downloadable ‘open source’
application
• e.g. openEMR , openMRS
• an open Specification for an EHR or EHR
platform
• Defines an technology-neutral/ vendor-
neutral ‘information model’
26
25. Copyright 2012
Ocean
What is an ‘information model’?
• Any definition of the structure and content of information
that should be collected or shared, including terminology
• A simple paper form - check boxes or Y/N questions
• A ‘minimal dataset’
• A message or API definition
• Internally every program or application
has some kind of information model
• Sharing information requires developing
shared information models
27
26. Data entry definition
28
What exactly do you
mean by record pulse and
blood pressure?
What are reasonable
min/max limits to put on
a temperature record?
What are the allowable
sizes of pupils in a drop-
down box?
28. ‘Best of Breed’ Information architecture
30
Application
Information Model
Persistence (Database)
Query
Application
Information Model
Persistence (Database)
Query
Integration engine
31. ‘open Platform' Information architecture
• Technology and Vendor neutral
• Define information structures independent of
application layer
• Rich enough to support eHealth apps
• Handle audit/versioning
• Define information structures independent of
persistence layer
• rapid incorporation of new datasets
• vendor/tech neutral querying
33
35. openEHR: Archetypes
• open source computable models of discrete clinical
concepts
• Familiar components of a health record
• Blood pressure, Body weight, Symptom
• Medication order, Family history
• Urea, Creatinine results
• ‘Maximal dataset’
• Capture as many clinical perspectives as possible
• Universal use case
37
36. openEHR: Templates
• Templates deliver the datasets by aggregating
archetypes together
• Key clinical endpoint and starting point for generation
of technical artefacts
• i.e. openEHR archetypes and
templates can be used directly
• Class libraries
• GUI skeletons
• Message schema
• Define API Profiles
38
45. 47
SMARTPlatforms
Pluggable Webapp
API
HL7 FHIR
Clinical Content
Exchange NHS API
‘inVivo’
Datastore API
Detailed
Clinical Content
Development
Clinical leadership PRSB
Terminology
Centre
HSCIC
Non
openEHR
systems
Archetype+ SNOMED Clinical
Content definitions
Apps developers
46. Interoperability is not a tech problem
“The real barriers to practical interoperability
are cultural and clinical”
Healthcare records are not just
buckets of biological facts
48
47. Healthcare Information Standards Process #FAIL
49
Clinical stakeholders
engage through top-down
governance
Committee-based
Late vendor engagement
Fixed review cycles
Unclear / unresponsive
change request
mechanism
48. Clinically-led Content Service
50
Clinical content
service
Clinical stakeholders,
vendors engage directly with
clinically-led content service
Continual dialogue with all
stakeholders via web-based
collaborative tooling
No fixed review cycles
On-demand change request
directly to clinical content
service
PRSB has high-level 4-
country governance role