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

dev.ehrscape.com

26

handi-hopd.org/demo

27

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