supporting handi apps developers arctic dual-modelling conf tromso 2014
DESCRIPTION
How do we support healthcare apps developers - HANDI and the HANDI-HOPD Open Platform Demonstrator (SMART on FHIR on openEHR)TRANSCRIPT
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
HANDIHealthopenEHR Foundation
freshEHR Clinical Informatics
INTRODUCTION
2
Ian McNicoll
Former Glasgow GP
Health informaticsDirector openEHR FoundationfreshEHR Clinical InformaticsOcean Informatics UKHANDIHealth
Commercial software developer‘GP Accounts’
HANDI Health CIC
• A not-for-profit Community Enterprise Company
• There to support:– Developers– Health and care professionals– Patients, service users and carers
Apps: Lightweight Digital Tools
Not just about mobileNarrow 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 deployAllows niche solutions and “fail fast”
What does HANDI do?
• Lobby for an environment (technical, cultural and commercial) in which apps can flourish interoperate and be orchestrated
HANDI is agnostic
• About– Platforms– Business models– Standards– Tools, services and approaches
• Show the community the possibilities and let individuals decide
‘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
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
SMART : ‘Substitutable’ Apps
9
‘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
‘clinicians who code’
11
‘Code4Health’
12
The ‘HANDI Vision’
13
Apps
EPREHR PHR
PHR EMRMeds
Repository
Drug KBTerminology
ServerService
DirectoryCDS Service Pathways KB
Services/Repositories
Infrastructural ServicesPDS/Record Discovery EWS ESB/Spine Security
Broker
‘Closed’ eHealth Platform
Proprietary Clinical Content / API
Proprietary value-add components
Proprietary Querying and Persistence
TerminologyServer Pathways KBESB/SpineITK Integration component
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
TerminologyServer Pathways KB
ESB/SpineITK Integration component
Commit
Retrieve
‘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
TerminologyServices Pathways KBESB/SpineITK Integration component
Commit
RetrieveQuery
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
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
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
openEHR Repository(vendor #1)
openEHR Repository [10](open source)
openEyes(Moorfields)
“Safer Wards” Orsini
openEHR Repository(vendor #2)
openEHR API openEHR API
LocalSQL DB
openEHR API
Wardware2 (Kings)
Orsini Clinical Content Service
Persistence Mgr
Industry :VistA, EMIS, TPP, HANDI …
NHS API
ESB / ITK / Spine components [2]
NHS Reporting API
NHS Care API
Leeds LCR
LCR apps(Leeds)
OpenEyes/ openEHR Toolkit
openENT(UCLP)
Clinical content
openEHR tech/spec dev.
openEHR API integration [7]
EHRPaaS [9]
NHS API- openEHR
Adaptors [8]
Professional Records
Standards Board
Professional oversight
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
Leeds NHS Care Record: open Platform
openEHR Foundation accreditedOpen 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)
SMARTPlatformsOpen APIs:
Leeds Clinical Portal via SMARTPlatform APIs‘OceanEHR’ Clinical
data repository
NHS HSCIC 13606 archetypes
24
25
SMARTPlatformsPluggable Webapp
API
HL7 Clinical Content
Exchange NHS API
inVivoDatastore
API
Detailed Clinical Content Development
Clinical leadership PRSB
Terminology CentreHSCIC
NonopenEHR systems
Archetype+ SNOMED Clinical Content definitions
A new mobile app developer requires plug in for care record to test pulse app functionality.
ITK+N3
NHS Hackday - medsrecDIY
• Patient-driven medication reconciliation
28
NICE guidance on medicines reconciliationMedication data models (RCP / GP2GP based)
Dummy Patient Health Record with realistic dataData accessible via RESTful API
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
32
33
34
35
HOPD in EhrExplorer
openEHR composition
37
next tech steps for HANDI-HOPD
SMART and HL7 FHIR support
More openEHR providersCross provider querying demosCross provider transfers
Focus for openEHR ‘in-vivo’ API alignment discussions
38
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
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