HANDI-HOPD:

Whats in the box?

Software apps to support health and care - Supporting the app paradigm
Creating a community of interest - That's HANDI

www.handi-hopd.org

Dr Ian McNicoll

HANDIHealth
openEHR Foundation
freshEHR Clinical Informatics

HANDI-HOPD Planning meeting London Sept 2014
INTRODUCTION
2
Ian McNicoll

Clinician
Former Scottish GP

Health informatics
Director openEHR Foundation
freshEHR Clinical Informatics
Ocean Informatics UK
HANDIHealth
NHS Scotland SCIMP

Commercial software developer
GP Accounts

3
SMARTPlatforms
Pluggable Webapp
API
HL7 FHIR
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
Apps developers
What is an API?
Application Programming interface
allows one application to talk
directly to another.
The app world runs on APIs
how Gmail calendar talks to
Apple Calendar
how my Train app knows my
next train home
4
What is in an API
Modern API restful requests look like web
page url
https://api.twitter.com/1.1/statuses/user_timelin
e.json?screen_name=twitterapi&count=2

and carries some
sort of
structured content
5
SMARTPlatforms API
6
Scopes and permissions: OAuth2

Simple sign-in: OpenID Connect

Lightweight UI integration: HTML5
via Pluggable app framework
SMARTPlatforms : Substitutable Apps
7
SMART-on-FHIR
8
HL7 FHIR
data model

replacing

SMARTPlatform
s
data model
(RDF)
HL7 FHIR API
9
What is FHIR good at?
Communication of information between
systems with limited querying

Strengths
Developer friendly
Lightweight approach
Great documentation / community
10
Where might FHIR be weaker?
Not designed for persistence
can work but will it scale?
partial querying only

Resources will not work out of the box in
the real world
Need local extensions and profiles
Version control / governance of the profiles
11
openEHR API
12
Designed for storing and querying
rich clinical dataset

New content is defined directly
by clinicians and can be immediately
uploaded into the clinical data repository

Vendor-neutral data models
Technology-neutral data models

Vendor-neutral data querying
Technology-neutral data querying
openEHR
Weaknesses
Complex technology
but new simplifying APIs appearing

Strengths
clinically-led data modelling
sharing archetypes = interoperability
Enterprise strength performance
Mature versioning/governance
13
dev.ehrscape.com
14
MedsRecDIY: http://diy-hopd.rhcloud.com/

15
Vendor-neutral querying
Vendor-neutral querying
Vendor/technology-neutral platform
19
Building out the platform
SMART and HL7 FHIR support
BlackPear , Marand
More openEHR providers
Lockheed Martin - OceanEHR
Medvision360
Code24
More demo apps
LiveCode mobile App demo
Knowledge resources
FirstDataBank
Indizen cloud terminology service

CDS resources
openClinical - PROFORMA
Cambio GDL
20

SMARTPlatforms
Pluggable Webapp
API
HL7 FHIR
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
Apps developers
Interoperability is not a tech problem
The real barriers to practical interoperability are
cultural and clinical

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
23
Traditional Standards Process
24
Clinical stakeholders
engage through top-down
governance

Committee-based

Late vendor engagement

Fixed review cycles

Unclear / unresponsive
change request
mechanism
Formal standards process is a barrier
Standards can be a barrier to progress
Ewan Davis, HANDI
http://www.woodcote-
consulting.com/farwell-to-ruthless-
standardisation/

Technical (ISO / SCCI)
Still largely a paper and committee-
bound process
No clear problem report/change
request mechanism
Slow review cycles

Professional (PRSB)
Valuable clinical requirements input
but distant from implementation
25
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
26
GP2GP medication archetype
Web-based clinical review
28
Archetypes: open source GitHub mirror

29
https://github.com/ClinicalModelsUK/ckm
FHIR + openEHR joint resource/archetype
30
Clinically-led Content Service
31
Clinical content
service
Clinical stakeholders,
vendors engage directly with
clinically-led content service

Continual dialogue with all
stakeholders via web-based
collaborative tooling

No fixed review cycles

On-demand change request
directly to clinical content
service

PRSB has high-level
governance role
Evolutionary standardisation
distributed Governance
32
Implementers
Secondary
endorsement
Publication and Secondary Endorsement
33
Project editors decide on
formal publication, acting as
Benign Dictators

Professional bodies, vendors
and PRSB may Endorse a
resource as a secondary
exercise

this does not restrain the
formal publication process
By Royal Appointment

PRSB hires and fires Editors
Blogs
34
http://www.woodcote-
consulting.com/farwell-
to-ruthless-
standardisation/
http://coiera.com/201
3/11/01/are-
standards-
necessary/
That the fraction of standards
produced that are actually complied with,
will with time asymptote toward zero
Links
twitter: @ianmcnicoll

HANDI-HOPD: handi-hopd.org
http://diy-hopd.rhcloud.com/
hopdscape-hopd.rhcloud.com
minimal-hopd.rhcloud.com

Marand Ehrscape API: dev.ehrscape.com
Leeds Innovation Lab Health Platform : http://leedslabplatform.com

openEHR Foundation : www.openehr.org
SMARTPlatforms: smartplatforms.org
HL7 FHIR: hl7.org/implement/standards/fhir/

International archetype repository: www.openehr.org/ckm
UK archetype repository: www.clinicalmodels.org.uk
35