Supporting HANDI apps developers Arctic dual-modelling Conf Tromso 2014

download Supporting HANDI apps developers Arctic dual-modelling Conf Tromso 2014

If you can't read please download the document

  • date post

    23-Aug-2014
  • Category

    Healthcare

  • view

    307
  • download

    0

Embed Size (px)

description

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

Transcript of Supporting HANDI apps developers Arctic dual-modelling Conf Tromso 2014

  • 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
  • INTRODUCTION 2 Ian McNicoll Former Glasgow GP Health informatics Director openEHR Foundation freshEHR Clinical Informatics Ocean Informatics UK HANDIHealth 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 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
  • 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 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
  • Closed eHealth Platform Proprietary Clinical Content / API Proprietary value- add components Proprietary Querying and Persistence Terminology Server 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 Terminology Server 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 Terminology Services Pathways KBESB/SpineITK Integration component Commit Retrieve Query
  • 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 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
  • 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 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
  • NHS HSCIC 13606 archetypes 24
  • 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
  • dev.ehrscape.com 26
  • handi-hopd.org/demo 27
  • NHS Hackday - medsrecDIY Patient-driven medication reconciliation 28
  • NICE guidance on medicines reconciliation Medication data models (RCP / GP2GP based) Dummy Patient Health Record with realistic data Data 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 providers Cross provider querying demos Cross 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