1) The document discusses a workshop on digital health interoperability standards hosted by Dr. Ian McNicoll and several organizations. 2) It covers different approaches to digital health interoperability such as closed platforms, best of breed systems, and open ecosystems. The openEHR standard and FHIR API are discussed in detail as alternatives. 3) The workshop promotes open and collaborative development of clinical information models and apps to advance digital health interoperability.

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

9. HSPC: SMART on FHIR on Clinical Models
9

10. SMARTPlatforms API
10
• Scopes and permissions: OAuth2
• Simple sign-in: OpenID Connect
• Lightweight UI integration: HTML5
via Pluggable app framework

11. SMART-on-FHIR
11
HL7 FHIR
data model
replacing
SMARTPlatform
s
data model
(RDF)

12. HL7 FHIR API
12

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

16. openEHR
• Weaknesses
• Complex technology
• but new simplifying APIs appearing
• Strengths
• clinically-led data modelling
• sharing archetypes = interoperability
• Enterprise strength performance
• Mature versioning/governance
16

17. ‘Code4Health’
18

18. NHS Code 4 Health
19

19. MedsRecDIY: http://diy-hopd.rhcloud.com/
20

20. GWYB: http://gwyb-handihopd.rhcloud.com/
21

21. Code 4 Health Dental App challenge
22

22. Rapid connected health app development
23

23. So what is openEHR?
25

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?

27. Megasuite Information architecture
29
Application
Information Model
Persistence (Database)
Query

28. ‘Best of Breed’ Information architecture
30
Application
Information Model
Persistence (Database)
Query
Application
Information Model
Persistence (Database)
Query
Integration engine

29. Information Model
Persistence (Database)
AppApp
‘Closed Platform' Information architecture
31
App

30. ‘open Platform' Information architecture
32
open Information Model
AppApp App
Oracle MongoDbSqlServer

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

32. Vendor/technology-neutral information
34

33. Vendor-neutral querying

34. openEHR: Multi-level modelling
36

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

37. Sharing and collaboration
39

38. Clinical Information models Factory
40

39. openEHR in practice: Specifications
41

40. openEHR in practice: tools and models
42

41. openEHR in practice: Clinical Data Repositories
43

42. How is it used: underpins App development
44

43. How is it used : National standards development
45

44. openEHR … Needs you !
46
members.openehr.org

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

49. Medication ‘archetype’

50. Web-based ‘democratised’ collaborative review
52

51. Evolutionary standardisation
‘distributed Governance’
53
Implementers
Secondary
endorsement

52. 54

53. From model to software…