what is openehr? - code4health · what is openehr? an open ... hl7 fhir clinical content exchange...
TRANSCRIPT
What is openEHR?An open specification for a health information model
capable of supporting an open ecosystem
vendor neutral
technology neutral
licensed with Apache 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
openEHR Foundation
Not-for-profit company based at University College, London, UK.
Owns the Intellectual Property and has high-level governance role
New Management Board recently elected
Alliance of Industry and Clinical representatives
openEHR activitiesOwns the Intellectual Property
all openly licensed Apache, CC-BY-SA, CC-BY-ND
Supports revision of specifications
Website / communications
maintains an international repository of freely available clinical content models - ‘archetypes’
openEHR Software
open source/free Modelling tools
Archetype Editor, Template Designer
Archetype Workbench
Guideline Definition Language editor
open source demo code
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
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
Separation of concerns…Allows system developers to optimise the RM layer without having to make any changes to accomodate 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, and is developed and maintained by clinicians using dedicated tooling
The native file format is ADL (Archetype Definition Language), a DSL but it is also expressible in xml, json etc
ADL is an ISO-standard also used by the ISO 13606 and CIMI
Everything in an archetype is based on and conformant with the reference model
AQL: Information-model queryingopenEHR systems support information model querying, independent of the actual persistence layer/ querying mechanism
Archetype Query language
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 persistence layer schema
It is the responsibility of the system developer to create a mapping between the AQL statement and the native querying mechanism
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
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 crazy or have a very big budget to do so
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
Stack Compositions
Templatevalidation AQL GDL
supportopen
source Separate product
Think!EHR Oracle Yes Yes Yes Yes Yes
OceanEHR SQL server Yes Yes Yes Yes Yes
DipsEHR SQL Server Yes Yes Yes Yes ?
EtherCIS PostgreSQL Yes Yes In dev In dev Yes Yes
Infinni SQL Server Yes Yes ? Yes
Base24 PostgreSQL Yes Yes In dev In dev Yes
Cabolabs Yes Yes Yes Yes
Nousco ? Yes Yes Yes
Privantis PostgreSQL Yes Yes In dev In dev In dev
Medrecord360 ? Yes Yes
Current CDR market
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
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
openEHR summaryDesigned 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