This presentation provides an introduction to the concepts and principles of openEHR.

1. Dr Ian McNicoll
What is openEHR

2. What is openEHR?
An open specification for a
health information model
capable of supporting an
open platform ecosystem
vendor neutral
technology neutral
licensed to allow open and
closed source business
models openehr.org

3. openEHR - Specifications
Normal 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

4. Two-level modelling
Low-level ‘stable’ reference model (RM)
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

5. Two-level modelling

6. openEHR: Archetypes
open source computable models
of discrete clinical concepts
Familiar components of a health
record
Blood pressure, Body weight
Medication order, Family history
Urea, Creatinine results
‘Maximal dataset’
Capture as many clinical
perspectives as possible

7. openEHR: Templates
Templates deliver the datasets
by aggregating archetypes
together
Key clinical endpoint and start
point for generation of technical
artefacts
i.e. openEHR archetypes and
templates can be used directly
Class libraries, Message schema
GUI skeletons, API Profiles

8. AQL: Information-model querying
Information model querying,
independent of the actual
database querying
vendor/technology neutral
querying
To query an openEHR system
you only have to know which
archetypes are in use.

9. Vendor-neutral querying

10. life-long record:clinicians in control
Archetypes consumed
automatically by an
openEHR system
Out-of-the-box
interoperability through
archetype sharing
No transforms or other
processing required
when moving data to
other vendors
Third-party apps
Vendor-neutral Information model
Technology-neutral datastore (CDR)

11. However ….
Building an openEHR back-end is easy
just follow the specifications
BUT
building a high-quality openEHR back-end is hard
must understand archetypes
must support information-model querying
must be fast and flexible
This is not a trivial engineering exercise

12. Technical approaches
Normalised 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, Neo4J used in academic projects
Commercial offerings
RDBMS + indexed binary blobs
Postgres, Oracle, SQL Server
Minimal normalisation

13. open source implementations
ADOC EtherCis
https://github.com/ethercis
Cabolabs EhrServer
https://github.com/ppazos/cabolabs-ehrserver
http://www.slideshare.net/pablitox/design-and-
implementation-of-clinical-databases-using-
openehr

14. The good news…
You do not have to build your
own openEHR back-end
‘CDR’…
over 10 providers of openEHR
CDR services
the APIs are compact and easy
to use once you understand
the basic concepts

15. Database Vendor-neutral AQL
GDL
support
open
source
Separate
product
Think!EHR
Oracle / SQL
Server / PostgreSQL
Yes Yes Yes Yes
OceanEHR SQL server Yes Yes Yes Yes
DipsEHR SQL Server Yes Yes Yes Yes
EtherCIS PostgreSQL Yes Yes In dev Yes Yes
Base24 PostgreSQL Yes In dev In dev Yes
Cabolabs Any SQL Yes In dev Nn dev Yes Yes
Privantis PostgreSQL Yes In dev In dev In dev
Ehr.care GraphDBs/Postgres Yes Yes In dev Yes
Clever CDR Various Yes Yes In dev Yes
openEHR CDR market

16. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
Vendor-neutral Information model

17. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

18. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

19. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

20. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

21. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

22. open platform architecture
Third-party apps
Technology-neutral datastore (CDR)
openEHR Rest API + AQL

23. eHealth'('City'of'Moscow''
Reproduced'with'permission'
'h9p://bit.ly/1w9wZQy''
Does it scale?

24. App development

25. App development

26. App development

27. App development

28. The ‘bi-modal’ EHR?
Bimodal IT is the practice of managing
two separate, coherent modes of IT
delivery, one focused on stability and the
other on agility.
Mode 1 is traditional and sequential,
emphasizing safety and accuracy.
Mode 2 is exploratory and nonlinear,
emphasizing agility and speed.
open Platform
+
Legacy EPR
User interface
Information model
Database
Third-party apps
Vendor-neutral Information model
Technology-neutral datastore (CDR)

29. Registries

30. ‘Feral’ apps

31. health platform as a service

32. National ‘standards’ development

33. National ‘standards’ development

34. National ‘standards’ development

35. National ‘standards’ development

36. Web-based ‘democratised’ collaborative
review

37. Web-based ‘democratised’ collaborative
review

38. Evolutionary standardisation
‘distributed Governance’
Implementers
Secondary
endorsement

39. Evolutionary standardisation
‘distributed Governance’
Implementers
Secondary
endorsement

40. Local asset governance
In any software development environment version
control is vital
Clinical systems are continually changing
Models have multiple co-dependencies
Changing one will have an impact on another
Changes to models and software must be carefully
managed
To prevent technical incompatibilities
To prevent clinical safety problems

41. Package management

42. Managing Version control
Authoring phase
during the authoring phase frequent version/revision
changes are inevitable
Loose control is necessary
Operational phase
It is critical that new Versions or Revisions are not
introduced inadvertently
May break queries
May introduce clinical safety problems
Tight control is essential

43. Staging
Vendor authoring
repository
Working copies
Ian
Olga
Hildi
openEHR CKM
Vendor software
development
repository
Vendor
operational
repository
commit
update
comment,
review,
request,
endorse
GIT
GIT
GIT

44. openEHR summary
Designed for storing and
querying rich clinical datasets
New content defined directly
by clinicians and immediately
uploaded into the CDR
Vendor-neutral data
Technology-neutral data
GDPR-ready!!