openehr medinfo2015 brazil sponsor session
TRANSCRIPT
Dr Ian McNicollCo-chair, openEHR
Medinfo 2015, São Paulo
openEHR: the open platform revolution
www.openehr.org
What is openEHR?An open specification for a health information model
capable of supporting an open ecosystem
vendor neutral
technology neutral
licensed with Apache/CC-BY-SA to allow open and closed source business models
What is openEHR not?openEHR is NOT
an open source health application
a downloadable app
owned by a single vendor or commercial organisation
commercially unfriendly
Megasuite architecture
‘open ecosystem’ architecture
Two-level modelling
openEHR - SpecificationsNormal technical specifications with UML diagrams etc
openEHR Reference model
how the health data is represented in a patient record
openEHR Archetype object model
how the clinical content definitions are represented separately from the Reference model
openEHR:Supporting an open eHealth Pl
Megasuite
Best of Breed
Platform
Open Ecosystem
“One system to rule them all”• English NHS NPfIT• Enterprise/GP Systems• Limited external integrations
Many systems ~ 100• Portals• Integration engines• Bespoke integrations
“Own the Platform”• Health Vault, Apple, Lorenzo, etc• ~1000 apps• Partner interfaces
The “Internet “of Digital Health• Healthcare Services Platform
Consortium• Moscow eHealth• devoManc
Separation of concerns…Allows system developers to optimise the RM layer without having to make any changes to accommodate new clinical concepts
Allows a relatively small, optimisable ‘kernel’ to be maintained
no data model reconfiguration
no database schema reconfiguration
Separation of concerns…All of the ‘clinical content’ is defined in archetypes, developed and maintained by clinicians
The native archetype format is ADL (Archetype Definition Language), but it is also expressible in XML, JSON, UML (AML)
ADL is an ISO-standard also used by ISO 13606 and CIMI
openEHR: Archetypes• open source computable
models of discrete clinical concepts
• Familiar components of a health record• Blood pressure, Body weight• Symptom,Medication order, Family
history• Urea, Creatinine results
• ‘Maximal dataset’• Capture as many clinical perspectives
as possible• A Universal use case
openEHR: Templates• Templates deliver the
datasets by aggregating archetypes together
• Represent real-world datasets: ‘Vital signs data entry screen’, ‘Discharge summary’, ‘End of Life Care plan’
• Key clinical endpoint and starting point for generation of technical artefacts
Clinical Information models factory
AQL: Information-model querying
openEHR systems support information model querying, independent of the actual persistence layer/ querying mechanism
vendor/technology neutral querying
To query an openEHR system you only have to know which archetypes are in use.
you do not have to know the physical persistence schema
Stakeholders in control• Two-level modelling gives
healthcare stakeholders control of their information, safe in the knowledge that whatever they design into archetypes will be consumed safely by an openEHR system
• If they share archetypes with another system, they have interoperability out-of-the box
• If they need to move data to a different vendor, this requires no transforms or other processing
‘Best of breed’ architecture
‘Closed platform’ architecture
SMARTPlatformsPluggable Webapp
API
HL7 FHIR Clinical Content
Exchange NHS API
‘inVivo’Datastore
API
Detailed Clinical Content Development
Clinical leadership PRSB
Terminology CentreHSCIC
NonopenEHR systems
Archetype+ SNOMED Clinical Content definitions
openEHR - key goalProvide specifications that allow a system developer to meet the very difficult requirements of health system building
but keep the data in any openEHR system completely interoperable and queryable
regardless of programming language
regardless of human language
regardless of internal database technology
Two-level modellingLow-level ‘stable’ reference model
Basic classes, structures, datatypes
Version control, auditing
Separate ‘clinical modelling’ layer which is applied as a ‘constraint’ on the RM
Clinical content is defined and managed separately but is always conformant to the RM and can always be consumed by the RM
Vendor-neutral querying
However ….Building an openEHR back-end is easy if you follow the specifications
BUT
building a performant openEHR back-end is hard
must accept new semi-arbitrary tree-like structures
must support information-model querying
must be fast and flexible
This is not a trivial engineering exercise
Technical approachesNormalised RDBMS
hard to respond to content changes
O-R mapping such as Hibernate
does not scale well
NoSQL solutions
seemingly a good fit but not much real-world experience
Mumps implementation
MongoDB used in academic ‘big data project’
Commercial offerings
RDBMS + indexed binary blobs
Postgres, Oracle, SQL Server
minimal normalisation
minimal use of SQL features
The good news…You do not have to build your own back-end
you have to be mad or have a very big budget to do so (for starters)
There are at least 10 commercial providers of back-end openEHR servers and more being developed
The APIs are small and easy to use once you understand the basic concepts
Does it scale?
openEHR: National ‘standards’ development
Healthcare Information Standards Process #FAIL
Clinical stakeholders engage through top-down governance
Committee-based
Late vendor engagement
Fixed review cycles
Unclear / unresponsive change request mechanism
Evolutionary standardisation‘distributed Governance’
Implementers
Secondary endorsement
HSCIChave adopted openEHR as primary ‘clinical content standards methodology’
acquiring a separate ‘English CKM’
developing archetypes for
PRSB Discharge summary
GPOC-R / GP2GP
Allergies, Blood pressure, Document metadata
http://www.infostandards.org/
documents/data-structures-v1-0-richard-
kavanagh-pptx.pptx
HSCIC
openEHR: Clinical Data Repositories
openEHR: App development
open-source Collaborative clinical content
Faster, safer app developmentFaster and easier to build
new apps based on openEHR
use existing archetypes
Much faster to respond to changes in clinical practice
Interoperability out-of-the-box
Growing ‘open platform’ market
From Russia with Love?http://www.woodcote-consulting.com/moscow-ehealth-a-model-for-the-uk/
SMARTPlatformsPluggable Webapp
API
HL7 FHIR Clinical Content
Exchange NHS API
‘inVivo’Datastore
API
Detailed Clinical Content Development
Clinical leadership PRSB
Terminology CentreHSCIC
NonopenEHR systems
Archetype+ SNOMED Clinical Content definitions
HSPC: SMART on FHIR on Clinical Models
NHS England NHS Code4Health/Open source program
Using openEHR EHRscape engine for SME / clinical training
Supporting openEHR-based ‘Open platform’ approach
OPENeP
HANDIHealth / Integration Pioneers
‘HSCIC CKM’ licence
‘NHS Code4Health’
SMARTPlatformsPluggable Webapp
API
HL7 FHIR Clinical Content
Exchange NHS API
‘inVivo’Datastore
Detailed Clinical Content Development
Clinical leadership PRSB
Terminology CentreHSCIC
NonopenEHR
datastores
Archetype+ SNOMED Clinical Content definitions
Code4Health Ehrscape
openEHR summary• Designed for storing and querying
rich 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
Come and visit …