HANDI-HOPD:
What’s 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
HANDIHealthopenEHR Foundation
freshEHR Clinical Informatics
HANDI-HOPD Planning meeting London Sept 2014
INTRODUCTION
2
Ian McNicoll
Clinician
Former Scottish GP
Health informaticsDirector 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
CentreHSCIC
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 urlhttps://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
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 queryingrich clinical dataset
• New content is defined directlyby clinicians and can be immediately uploaded into the clinical data repository
• Vendor-neutral data modelsTechnology-neutral data models
• Vendor-neutral data queryingTechnology-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
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
CentreHSCIC
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
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
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
Top Related