How do we support healthcare apps developers - HANDI and the HANDI-HOPD Open Platform Demonstrator (SMART on FHIR on openEHR)

1. Supporting the health ‘apps’ revolution
Software apps to support health and care - Supporting the app paradigm –
Creating a community of interest - That's HANDI
www.handihealth.org
Dr Ian McNicoll
HANDIHealth
openEHR Foundation
freshEHR Clinical Informatics

2. INTRODUCTION
2
Ian McNicoll
Former Glasgow GP
Health informatics
Director openEHR Foundation
freshEHR Clinical Informatics
Ocean Informatics UK
HANDIHealth
Commercial software developer
‘GP Accounts’

3. HANDI Health CIC
• A not-for-profit Community Enterprise
Company
• There to support:
– Developers
– Health and care professionals
– Patients, service users and carers

4. Apps: Lightweight Digital Tools
Not just about mobile
Narrow scope,a “connected thing”
Makes heavy use of pre-existing components
and services
Built using a well defined development and
deployment framework
Order of magnitude(s) faster and cheaper to
develop and deploy
Allows niche solutions and “fail fast”

5. What does HANDI do?
• Lobby for an environment (technical, cultural
and commercial) in which apps can flourish
interoperate and be orchestrated

6. HANDI is agnostic
• About
– Platforms
– Business models
– Standards
– Tools, services and approaches
• Show the community the possibilities and let
individuals decide

7. ‘open’
• Open data
– Analytics, quality monitoring
• Open APIs / standards
• ITK, GP2GP
• SMARTPlatform, FHIR
• Open source
– openEyes, Wardware
– Leeds Care Record
– Spine2
– “Safer Wards” Fund
7

8. Time for ‘open Platforms’?
• USA
• SMARTPlatforms
• Healthcare Services Collaboration Platform
• Intermountain, Cerner, Harris Healthcare
• GP Systems of Choice (GPSOC) refresh
• Phase 1 GP systems open APIs
• Phase 2 GP systems Common APIs
• De-facto ‘open platform’
8

9. SMART : ‘Substitutable’ Apps
9

10. ‘clinical engagement’
• Formal clinical ownership
– Joint GP IT Committee (RCGP / BMA)
– RCP ITU / Professional Records Standards Body
– UK – increasing 4-countries engagement
• ‘Guerilla activity’
– ‘Clinicians who code’, #digidoc13
– NHS Hackday
– Renal PatientView
– ‘Feral’ departmental systems
• Multiple MS Access databases
10

11. ‘clinicians who code’
11

12. ‘Code4Health’
12

13. The ‘HANDI Vision’
13
Apps
EPR
EHR PHR
PHR EMR
Meds
Repository
Drug KB
Terminology
Server
Service
Directory
CDS Service Pathways KB
Services/Repositories
Infrastructural Services
PDS/Record Discovery EWS ESB/Spine
Security
Broker

14. ‘Closed’ eHealth Platform
Proprietary Clinical Content / API
Proprietary value-
add components
Proprietary Querying and Persistence
Terminology
Server
Pathways KBESB/SpineITK Integration component

15. An open standards 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

16. ‘openEHR’ open Standards platform
Closed
source
Open
source
Open
source
openEHR
CDR
Vendor DVendor B Vendor CVendor A
Open source Archetype-based clinical
content information / querying model
OSS Value-add
components
Vendor
solutions
Terminology
Services Pathways KBESB/SpineITK Integration component
Commit
Retrieve
Query

17. Interoperability is not a tech problem
• Interoperability is a clinical problem
– Diverse recording practice (sometimes arbitrary)
– Diverse recording requirements
– Complexity / contextual nature of health data
– Lack of clinical involvement in standards development
• Too technical, too philosophical
• Too time-consuming, too slow
17

18. Current clinical content
standards methodology
• Antithesis of ‘agile’ development
– Inaccessible to clinicians
– Slow to develop, difficult to implement
– CDA implementation mostly ‘dumb documents’
– SNOMED has key role but ? oversold as whole solution
• Uncontrolled
– Multiple definitions of technical messaging models
• Approx 20 definitions of ‘allergy’ across UK
– No clear change request / problem report mechanism
18

19. Formal standards development
• “Arguably standards just get in the
way”
– Ewan Davis, HANDI
• Technical (ISB / ISO)
– Still largely a paper and
committee- bound process
• No clear problem
report/change request
mechanism
• Slow review cycles
• Professional (RCP ?PRSB)
– Aspirational guidelines
– Divorced from implementation
19

20. openEHR
Repository
(vendor #1)
openEHR
Repository [10]
(open source)
openEyes
(Moorfields)
“Safer Wards” Orsini
openEHR
Repository
(vendor #2)
openEHR API openEHR API
Local
SQL DB
openEHR API
Wardware2
(Kings)
NHS API
ESB / ITK / Spine components [2]
NHS Reporting
API
NHS
Care API
LCR apps
(Leeds)
openENT
(UCLP)
Clinical content
openEHR API integration [7]
EHRPaaS [9]
NHS API-
openEHR
Adaptors [8]
Professional
Records
Standards
Board
Professional oversight

21. open, shared data models: Archetypes
• Clinically-led + collaboratively authored
– open-source ‘crowd-sourcing’ methodology
– Shared open repository ‘CC-BY-SA’ licence
• Agility in response to continually changing clinical
demand
– Clear ownership, change request mechanism
– Tight version control
21

23. Leeds NHS Care Record: open
Platform
openEHR Foundation accredited
Open Standards CDR Service layer
N3
hosted
ESB/Spine ITK Integration component
Commit
Retrieve
Query
OpenEHR Clinical Content “Archetypes”:
• Medication, allergies (GP2GP/ RCP/NHSS)
• Problems, procedures (international)
• End of Life content (ISB)
• Vital Signs, NEWS (international)
SMARTPlatforms
Open
APIs:
Leeds Clinical Portal via
SMARTPlatform APIs
‘OceanEHR’ Clinical
data repository

24. NHS HSCIC 13606 archetypes
24

25. 25
SMARTPlatforms
Pluggable Webapp
API
HL7
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
A new mobile app
developer requires
plug in for care
record to test pulse
app functionality.
ITK+N3

26. dev.ehrscape.com
26

27. handi-hopd.org/demo
27

28. NHS Hackday - medsrecDIY
• Patient-driven medication reconciliation
28

29. NICE guidance on medicines reconciliation
Medication data models (RCP / GP2GP based)
Dummy Patient Health Record with realistic data
Data accessible via RESTful API

30. What did we set out to do?
• Create a patient-facing web-page for medication
reconciliation
• Populate existing medication list from GP system or
other source
• Enable patient to mark each item as
– Taking as prescribed / Changed dose
– No longer taking / Add new medication
• Save reconciled record back to server for onwards
transmission to GP
30

31. 31

32. 32

33. 33

34. 34

35. 35

36. HOPD in EhrExplorer

37. openEHR composition
37

38. next tech steps for HANDI-HOPD
SMART and HL7 FHIR support
More openEHR providers
Cross provider querying demos
Cross provider transfers
Focus for openEHR ‘in-vivo’ API alignment
discussions
38

39. next steps for HANDI-HOPD?
• Direct discussion with NHS England
• possible use by Code4Health
• possible direct support for the ‘open
standards platform’ approach
• HOPD-HACKD hackday event in
September
39

40. Links
• twitter: @ianmcnicoll
• HANDI-HOPD handi-hopd.org/demo
• Ehrscape: dev.ehrscape.com
• Leeds Innovation Lab Health Platform : http://leedslabplatform.com
• openEHR Foundation : www.openehr.org
• International archetype repository: www.openehr.org/ckm
• UK archetype repository: www.clinicalmodels.org.uk