Supporting HANDI apps developers Arctic dual-modelling Conf Tromso 2014
Download as PPTX, PDF5 likes988 views
The document discusses the role of supporting health applications (apps) and fostering a community for their development and deployment within healthcare, highlighting the importance of interoperability and open standards. It outlines the goals of HandiHealth, emphasizing a collaborative, open-source approach to clinical content management and the need for better engagement with clinicians in standards development. Additionally, it describes ongoing projects and future steps towards enhancing healthcare data exchange and app functionality in the context of a connected health ecosystem.
![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](https://image.slidesharecdn.com/handi-arcticconf2014-140529032933-phpapp01/85/Supporting-HANDI-apps-developers-Arctic-dual-modelling-Conf-Tromso-2014-20-320.jpg)
Supporting HANDI apps developers Arctic dual-modelling Conf Tromso 2014
- 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
- 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
- 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
- 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