Introduction to openEHR - InterHealth 2022

An introduction to openEHR, clinical information modelling, pragmatic standardisation and use of ontologies.

Presented by Erik Sundvall and Silje Ljosland Bakke in CRS4, Sardinia, on 11 october 2022, as part of InterHealth 2022.

1. Introduction to
Presented11 October2022 at InterHealth2022, Sardinia, Italy
By Silje Ljosland Bakke & Erik Sundvall

2. Silje Ljosland Bakke Erik Sundvall
About us
•Registered nurse and
informatician
•Senior adviser, structured
health records,
Western Norway Regional
Health Authority
•Coordinator, National Editorial Board for
Archetypes
•PhD Medical Informatics,
MSc Information Technology
•Information architect @
Karolinska University Hospital,
Region Stockholm (Main job)
•Affiliated researcher @KarolinskaInstitutet
•Adjunct Senior Lecturer in Medical Informatics
@Linköping University
https://www.openstreetmap.org/

3. Agenda
•Introduction
•Clinical data modelling
•Use of ontologies and terminologies
•Persistence and query strategies

4. What is
openEHR?

5. https://openehr.org/about_us
and international
community!

6. What isn’t openEHR?
•An open source software
•...but you can make both open source and closed source systems based on the
open specifications
•A downloadable app
•...but there are several openEHR tools and platform components that can be
downloaded
•A panacea
•...but used wisely it can cure some root causes of bad healthIT

7. Key properties
•Multi level modelling
•Separation of data definitions and implementation
•Separation between persistence and application

8. What is openEHR good for?
•Building standards-based clinical data repositories (CDRs)
•Modelling and standardising clinical concept models (archetypes)
•Creating complex data sets using combinations of standardised
models (templates)
•Building applications on data schemas generated from templates
(operational templates)
•Persisting clinical data in a standardised way (compositions)
•Predictably retrieving clinical data (AQL)

9. What is openEHR not required for?
•Simple, static data structures
•Demographic data
•Appointment data
•Thingsthat are not going to be reused or that are not a god fit
to store in a health record

10. Think about LEGO®
•There are about 2.500 variants
of LEGO bricks in production
•They can all be combined in an
infinite number of
combinations
•Why?
Photo: lego.com

11. Reference model
•Technical foundation
•Defines building blocks
forarchetypedcontent
NO CONTENT
Illustration: https://commons.wikimedia.org/wiki/File:Lego_dimensions.svg

12. Archetypes
•Specification of clinical concepts
•Clinically oriented
•Maximum dataset
•Reusable
Photo: https://www.kindpng.com/imgv/JJmmxT_lego
-
png
-
download
-
image
-
pile
-
of
-
lego
-
bricks/STANDARDISED CONTENT

13. 3

14. Templates
•Combinations ofconstrained
archetypes
•Data setsfor forms,
messages, etc
•Case specific
•Not theUI
CASE SPECIFIC CONTENT

15. Forms and apps
•Defines UI
•Based on templates,
terminology value sets
and often some program code
•Not (yet) standardised by
openEHR
CASE SPECIFIC FUNCTIONALITY

16. Where to find more information
•General information, governance: https://openehr.org/
•Technical stuff: https://specifications.openehr.org/
•Clinical models: https://ckm.openehr.org/ckm/
•Community: https://discourse.openehr.org/(Both tech and clinical)

17. How openEHR
helps reduce
reinter-
pretation

18. AGREE WHERE?
Agree where -inside or outside the EHR systems?
The difference between interoperability and intraoperability
16 December 2021
18

19. 19
Agree where?
HL7 FHIR etc.openEHR etc. openEHR etc.

20. 20
Interoperabilityvs Intraoperability
▪A model is agreed to that allows all systems to exchange what needs to be
exchanged, without requiring any design changes to the way their systems
works ☺
▪Whatever is done can be done on the periphery. And what can be done is
therefore constrainedto the lowest common denominator of the way that the
systems function –all systems are constrained to the dumbest system ☹
(But it is a fast start for many simple use-cases ☺)
▪Smarter systems need to come up with their own (only partly standardized)
“extensions”to the basic model so they can do smarter things. Many well known
deficiencies of this (semantic scalability, fragmentation etc.) ☹
▪Examples: Messaging, HL7 FHIR etc.
Source: Grieve, G. Good Exchange Specifications: Interoperability vs Intraoperability.
Health Intersections.http://www.healthintersections.com.au/?p=820

21. 21
▪Reworkthe corestructuresofthe systems to functionin an agreedway.
Becauseall the systems workthe same way, thenexchangebetweenthe systems
is easyand straight forward. ☺(And internalmodelmaintenance/update
workloadcanbe sharedglobally/nationally☺.)
▪Intraoperabilityhas fewerdeficiencies, buttheyaremuchbigger: it’smuchharder
to get agreement… ☹(Bothtechnicaland clinicalagreementsareneededto get
maximum benefit ofthisapproach ☹)
▪Examples: CIMI, openEHR, someusagesofISO13606etc...
Typically, at thispoint, the system designers (oftenvendors) get the blame. But–it’snot as simple as
that–vendorsdo whateversells, whichis whateverthe purchaserwantsto buy…
Based on a post by Grahame Grieve (member of FHIR-core team) on February 28, 2012:
http://www.healthintersections.com.au/?p=820. A more descriptive name for this kind of open intraoperability approach
might be something like ”shared model driven strategy” Note that the positive view of intraoperability described above is
concerning vendor neutral models, there is also another different (risky, lock-in-prone) definition of intraoperability
focused around dominating market actors described at http://www.ecis.eu/intraoperability/)
Interoperabilityvs Intraoperability

22. Exploring categories of
reinterpretation problems.
•Some conversions are possible to do automatically with an algorithm,
•some others are possible with a human in the loop (manually
reinterpreting every transfer)...
•...and yet some other conversions are (algorithmically) impossible.
16 December 2021
22

23. 23
What can conversion/reinterpretaion solve?

24. Reinterpretation
problems of
TypeI, II & III

25. Example System A System B
TypeI
A <----> B Canbe donewith
algoritm/program
Birthweight: 3300g
Date: 1954-03-13
Body weight: 3,3 kg
TImepoint: 13 Mar 1954
TypeII
A --> B
Semanticloss and distortion
dueto reinterpretations.
Hard, dangerousor impossible
withalgorithm/program…
…butoftendonemanually
by medicallyskilledstaff
over and over for each
transfer…
B --> A
Missinginformation
impossiblewith
algorithm/program
Needssurgeryat latest: 2018-01-30
Surgeryscheduled: 2018-01-20 15:30
Main diagnose*:
323291000119108 | Osteoarthritis of left hip joint|
OtherDiagnosis*: 25343008 | Secondary localized
osteoarthrosis of pelvic region|
299308007 | Hip joint painful on movement |
Procedure*: 19954002 | Reconstruction of hip with use of
methyl methacrylate|
Surgerytype**: LubinusSP II
Preferredanesthesia*: 18946005 | Epidural anesthesia|
NEWS2-score at admission: 1
Anesthesiaassessment:
-Fitness: canhandlelightphysicalexercise
-Cardiovascular: OK -Lungs: OK -Throat: OK
-Gastrointestinal*: 16331000 | Heartburn
Surgerydate: 2018-01-20
Diagnosiscode: M16.7 | Other
secondarycoxarthrosis
Surgerycode***: NFB49 | Primär total
höftledsplastik med cement (Primary
total hip arthroplasty with cement)
Anesthesiacode***: ZXH50 |
Epiduralanestesi (epidural anestesia)
ASA-classification: ASA I = normal
healthypatient
TypeIII
Reinterpretaionimpossible
(evenfor skilledhumans)
dueto aggregations etc.
Numberofcigarettessmokedper week: 6-10
…specifiedin a system withthe options:
0, 1-5, 6-10, 11-15, 16-30, 31-50, 51-100, 101+
Numberofcigarettesper week: ?
…specifiedin a system withthe options:
0, 1-3, 4-7, 8-14, 15-28, 29-69, 70+

26. Example System A System B
TypeI
A <----> B Canbe donewith
algoritm/program
Birthweight: 3300g
Date: 1954-03-13
Body weight: 3,3 kg
TImepoint: 13 Mar 1954
Type II
A --> B
Semantic loss and distortion
due to reinterpretations.
Hard, dangerous or impossible
with algorithm/program…
…but often done manually
by medically skilled staff
over and over for each
transfer…
B --> A
Missing information
impossible with
algorithm/program
Needssurgeryat latest: 2018-01-30
Surgeryscheduled: 2018-01-20 15:30
Main diagnose*:
323291000119108 | Osteoarthritis of left hip joint|
OtherDiagnosis*: 25343008 | Secondary localized
osteoarthrosis of pelvic region|
299308007 | Hip joint painful on movement |
Procedure*: 19954002 | Reconstruction of hip with use of
methyl methacrylate|
Surgerytype**: LubinusSP II
Preferredanesthesia*: 18946005 | Epidural anesthesia|
NEWS2-score at admission: 1
Anesthesiaassessment:
-Fitness: canhandlelightphysicalexercise
-Cardiovascular: OK -Lungs: OK -Throat: OK
-Gastrointestinal*: 16331000 | Heartburn
Surgerydate: 2018-01-20
Diagnosiscode: M16.7 | Other
secondarycoxarthrosis
Surgerycode***: NFB49 | Primär total
höftledsplastik med cement (Primary
total hip arthroplasty with cement)
Anesthesiacode***: ZXH50 |
Epiduralanestesi (epidural anestesia)
ASA-classification: ASA I = normal
healthypatient
TypeIII
Reinterpretaionimpossible
(evenfor skilledhumans)
dueto aggregations etc.
Numberofcigarettessmokedper week: 6-10
…specifiedin a system withthe options:
0, 1-5, 6-10, 11-15, 16-30, 31-50, 51-100, 101+
Numberofcigarettesper week: ?
…specifiedin a system withthe options:
0, 1-3, 4-7, 8-14, 15-28, 29-69, 70+

27. Example System A System B
TypeI
A <----> B Canbe donewith
algoritm/program
Birthweight: 3300g
Date: 1954-03-13
Body weight: 3,3 kg
TImepoint: 13 Mar 1954
Type II
A --> B
Semantic loss and distortion
due to reinterpretations.
Hard, dangerous or impossible
with algorithm/program…
…but often done manually
by medically skilled staff
over and over for each
transfer…
B --> A
Missing information
impossible with
algorithm/program
Needssurgeryat latest: 2018-01-30
Surgeryscheduled: 2018-01-20 15:30
Main diagnose*:
323291000119108 | Osteoarthritis of left hip joint|
OtherDiagnosis*: 25343008 | Secondary localized
osteoarthrosis of pelvic region|
299308007 | Hip joint painful on movement |
Procedure*: 19954002 | Reconstruction of hip with use of
methyl methacrylate|
Surgerytype**: LubinusSP II
Preferredanesthesia*: 18946005 | Epidural anesthesia|
NEWS2-score at admission: 1
Anesthesiaassessment:
-Fitness: canhandlelightphysicalexercise
-Cardiovascular: OK -Lungs: OK -Throat: OK
-Gastrointestinal*: 16331000 | Heartburn
Surgerydate: 2018-01-20
Diagnosiscode: M16.7 | Other
secondarycoxarthrosis
Surgerycode***: NFB49 | Primär total
höftledsplastik med cement (Primary
total hip arthroplasty with cement)
Anesthesiacode***: ZXH50 |
Epiduralanestesi (epidural anestesia)
ASA-classification: ASA I = normal
healthypatient
TypeIII
Reinterpretaionimpossible
(evenfor skilledhumans)
dueto aggregations etc.
Numberofcigarettessmokedper week: 6-10
…specifiedin a system withthe options:
0, 1-5, 6-10, 11-15, 16-30, 31-50, 51-100, 101+
Numberofcigarettesper week: ?
…specifiedin a system withthe options:
0, 1-3, 4-7, 8-14, 15-28, 29-69, 70+

28. 28
Agree on what, where?
Type I can be
solved here
Type II & III must
be solved here
also solves type I
Type II & III must
be solved here
also solves type I

29. 29
Agree on what, where?
Type I can be
solved here
Type II & III must
be solved here
also solves type I
Type II & III must
be solved here
also solves type I
Fax is a common workaround today

30. 30
Agree on what, where?
Type I can be
solved here
Type II & III must
be solved here
also solves type I
Type II & III must
be solved here
also solves type I
Many reinterpretation problems remain even if fax is replaced by PDF sharing…
…but may become less visible

31. 31
Alsowithinthe same organisation…
”swivelchairintegration”

32. 32
Agreeon what, where? -Repetition
Type I can be
solved here
Type II & III must
be solved here
also solves type I
Type II & III must
be solved here
also solves type I

33. Templates,
archetypes,
reference model
and applications

34. Archetypes, templates and forms
Maximal dataset vs least common denominator

35. Archetypes
Reusable documentation patterns
Template
Specific for a use case Combines and
configures (several) archetypes
Form
Autogenerated from template, then manuelly adjusted
https://tools.openehr.org/

36. ”Template” selects and configures/adjusts archetypes, for example:
= active data capture
= sets suitable default values (that can be changed i fneeded)
no arrow= fields not needed in this example/use case. Thus not visible in forms etc
Example of an”archetype”
Clinically interesting things regarding blood pressure measurement?
"Maximum dataset” approach instead of lowest common denominator.
There are methods/formalisms/tools to capture and requirements in, and forums to discuss in.

37. ”Template” selects and configures/adjusts archetypes, for example:
= active data capture
= sets suitable default values (that can be changed i fneeded)
no arrow= fields not needed in this example/use case. Thus not visible in forms etc
Exempel of an”archetype”
Clinically interesting things regarding blood pressure measurement?
"Maximum dataset” approach instead of lowest common denominator.
There are methods/formalisms/tools to capture and requirements in, and forums to discuss in.

38. https://ckm.openehr.org/
"Adopt" the archetypes
you want to follow and e.g.
get invitation to review for.
Multilingual support.
Here Swedish is
selected
Version and
publicationstatus
visiblein list
Powerful search
Limited name search
Version history

39. https://ckm.openehr.org/
"Adopt" the archetypes
you want to follow and e.g.
get invitation to review for.
Multilingual support.
Here Swedish is
selected
Powerful search
Limited name search
Version history
Version and
publicationstatus
visiblein list

40. Technical
reference
model
Separation ofconcerns&
reusable(very) general
patterns.

41. 41
openEHR Reference Model = ”RM”
▪“Normal” object-orientedreferencemodel-a foundation,
withdata types, data (tree)structures, etc
▪Archetypes+ templates combineobjectpatternsinto
structuresand set id + name+ constraints/configuration
usedto createvalid instancesofEHR-content
▪Thenyoucanstore, share, read and ask (AQL) questions

42. Figure 20. High-level Structure of the openEHR EHR

45. The objects inherit from LOCATABLE.
When storing EHR content, then:
•name= the name the archetype author gave the node
•archetype_node_id= at/id-codes inside archetypes e.g.
at0008, or -at archetyperootnodes,the archetype ID .

48. openEHR’s
”multi-tool”

49. Infofrom imports etc.
Linksbetwen
parts of the EHR
Extra ID (if
needed )

51. Instancestructures
•Helpsunderstanding, seetechnicalspecifications, e.g. EHR spec

52. Formats for instancedata
General use(for anyopenEHR instancedata)
•”canonical” JSON
–https://specifications.openehr.org/releases/ITS-JSON/latest
–AlsoseeupcomingOpenAPIspecfor openEHR
•”canonical” XML
–https://specifications.openehr.org/releases/ITS-XML/latest
Template specificformats
(ofteneasierfor integration programmersto read/use)
•SimplifiedJSON (both”flat” & ”structured”)
–https://specifications.openehr.org/releases/ITS-REST/latest/simplified_data_template.html
•SimplifiedXML (TDS/TDD) onlyusedfor import to CDRs
–https://specifications.openehr.org/releases/ITS-REST/Release-
1.0.2/simplified_data_template.html#_xml_schema_formats

53. Clinical
information
modelling with
openEHR

54. How do you
model the
clinical
world?
Photo: HaukelandUniversity Hospital https://www.flickr.com/people/haukeland/

55. •Life and death
•Complexity
•Constant change
•Life long scope
•Mobile population
Why is clinical information
so hard?

60. What do we need structure for?
•Avoid duplication
•Predictable retrieval
•Decision support
•Research/registries
•Performance indicators
primary uses
secondary uses

61. Information context

62. Information contextin healthcare
Diagnosis
Clinically recognised: 1997
Severity: Moderate
Clinical description: Insulin dependent
Health risk
Risk factor: High BMI
Risk factor: Family history of diabetes
Diabetes mellitustype 2Diabetes mellitustype 2

63. Health record / quality registry divide
Diagnosis: Diabetes mellitustype 2
Clinically recognised: 1997
Severity: Moderate
Clinical description: Insulin
dependent
Does the patient have diabetes type 2?
☐Yes
☐No
☐Unknown
?
???
??
?
?
?

64. How long are you planning to live?
•Are you expecting your healthcare
information to last that long?
•If it even still exists, will it be readable for
future applications and users?
Kreditering: Ricardo Correia

65. Structure is not the nirvana
•Structured information is not a goal in itself
•Structuring should be done only when it
has a clear value
•It must always be possible to add nuances
using free text
•Sometimes free text is better

66. Pragmatic
standard-
isation

67. Clinical engagement
•Clinicians can best define
which information is
relevant for clinical work
•Clinicians are busy treating
patients
•Traditional standardisation
processes unsuitable
Photo:
Haukeland
University Hospital
https://www.flickr.com/people/haukeland/

70. Clinical engagement
•Make models clinically
oriented
•Make participation quick and
easy
•Give something back
•Seeing is believing
Photo:
Haukeland
University Hospital https://www.flickr.com/people/haukeland/

71. Principles for clinical modelling
•Low participation threshold
•Manage changeover time
•Strong governance
•Vendor independence
•Model once and share
•Use case independence
Photo: https://pixabay.com/no/vectors/kompassrose
-
retning
-
vind
-
rose
-
305424/

72. Pragmatic standardisation
•Gradually and step by step
instead of all at once
•Constant maintenance
instead of 5 year revision cycles
•Careful selection of what to standardise
•Some standardisation is better than none

73. What must be standardised?
•Only information for reuse or sharing mustbe
standardised
•If the information is only relevant within the context
where its originally recorded, the definition can be
local
Misunderstanding alert!
Reuse or sharing does not necessarily imply exchange between solutions.

74. Three questions about the need to standardise
1.What kind of information is this, and what is its context?
2.Will the information be reused in a structured way
withinthe context where it was recorded?
3.Is it likely the information will be reused outside of the
context where it was recorded?

75. Example:

77. 1.Cancer diagnosis w/ ICD-10 code, diagnostic certainty and
date of confirmation. Context: Cancer investigation and treatment
2.Yes, both for clinical and registry use
3.Yes, for example for CDS, analytics, or reimbursement
Answer: Should be standardised

78. 1.TNMclinical classification 6th edition, primary tumour, colon
cancer. Context: Cancer investigation and treatment.
2.Yes, both for clinical and registry use
3.Perhaps?
Answer: Should be standardised if possible

79. 1.Obscure registry specific questions about lymph node metastases,
no standardised codes, phrased as a questionnaire.
Context: Cancer registry
2.Yes, for registry use
3.Probably not
Answer: Choose your battles…

80. Local definitions
•Using local information models doesn’t mean the
information can only exist in one solution, but that
it isn’t considered relevant outside the context
where it’s recorded
•Data sets using local information models can still
be used in several different solutions

81. What if you want to standardise,
but run out of time?
•Make sure there’s agreement on a
modelling pattern
•Agree on a way to differentiate drafts from
published models
•Next time, start modelling work at an
earlier stage? ??????

82. Let’s make a
template
together!
Photo: https://www.flickr.com/photos/haukeland/49383659916/in/album-72157712662890601/

83. Three rules of template building
•Ask someone who
knows the
archetype library
•Read what the
archetypes say
•If something is
missing, first check
the data types

84. Let’s make an
archetype
together!
Photo: https://pixabay.com/no/photos/tobakk-nicotiana-tabacum-blader-4457185/

85. Tools and
toolchains

86. Workflow, Toolchains, Tools
Platforms & Deployments
How do openEHR parts fit together?

87. Context for openEHR, Image from: https://www.openehr.org/about/what_is_openehr
Can also include patients!
Other (non-EHR) server functions
Non-EHR storage
openEHR API
API
How do openEHR parts fit together?
Archetypes,
Templates,
CDS rules etc.
SNOMED CT,
ICD, ICF etc.
Archetype
Designer tools etc.
Clinical Knowledge
Manager (CKM),
GitHub etc.
Upload
template to
platform
Open template
in a tool

88. API
openEHR API
Archetype
Designer toolsetc.
Archetypes,
Templates,
CDS rules etc.
https://tools.openehr.org/designer

89. API
openEHR API
CKM, GitHub etc
Free to use. Search, visualisation, review/versioning,
adoption, and translation archetypes and templates
Archetype
CKM = Clinical Knowledge Manager
https://ckm.openehr.org/

90. Context for openEHR, Image from: https://www.openehr.org/about/what_is_openehr
openEHR API
API
How do openEHR parts fit together?
Archetypes,
Templates,
CDS rules etc.
SNOMED CT,
ICD, ICF etc.
Archetype
Designer tools etc.
CKM, GitHub etc
Upload
template to
platform
Open template
in a tool
Focus of next slide

91. openEHR modeling toolchain
Form builder
openEHR ”template”
For specific use case, e.g. local,
regional or national.
Free archetype and template
editing tool at
https://tools.openehr.org/designer/
openEHR ”archetypes”
Clinical data models.
Found in internatioinal repository
https://ckm.openehr.org/ckm/
Maximi-datasets, intended for many
use cases. Multilingual
”Form renderer”
Web-component that can be
included in any webapp. It
displays forms and submits
validated data to openEHR
backends via standardized API.
Conditional logic

93. https://openehr.org/openehr_in_use/deployed_solutions/
…not complete, for example missing some providers, missing recent projects and missing China!

95. Ontologies,
terminologies
and openEHR

96. Terms/knowledge about
health/healthcare:
Concept models
Vocabularies,
classifications,
ontologies; ICD-10,
SNOMEDCT, ICF
Framework for information
about each patient:
Information models
Data structures; openEHR
archetypes, FHIRresources
Rules to be applied to
recorded information:
Inference models
Rules and knowledge bases
used in decision support
and alerts
Some overlap

97. Terminologies vs information models
Information models represent the
“questions”
Terminologies can give (some of) the
“answers”
Complementary concepts
ICD_10::L40.0::Psoriasis vulgaris
and
SCT::74757004::Skin structure of elbow
SCT::6736007::Moderate
???

98. Where terminologies rule
•Hundreds of thousands of concepts
•Diagnoses, symptoms, lab results, body structures,
organisms, procedures, …
•Inference based on relations between concepts

99. Inference based on relations
11
4

100. n levels

101. Where terminologies fall short
•Context
•Quantitative data
•Complex concepts

102. Context
•“We’ll just stuff some codes in somewhere, so we can
get refunded for this cancer treatment.”
•15 years later, from the new Dr. Google:
•“I’m afraid you have ovarian cancer.”
•“What?! But those were removed 15 years ago!”

103. Quantitative data
•“We’ll just make a simple code set for specifying the
number of times a woman has
been pregnant!”
•“Great idea! Ten should be enough
for anybody!”
Famous last words…

104. Complex concepts
•Combinatorial explosion
•All permutations of “type of rash” per “area of skin”
•Post coordination can help, but comes with its own set
of challenges

106. Fra: Ocean Informatics, 2014

107. …jo, på 601 forskjellige måter…
ID
Test name
Timing
Dose
Route
Specimen
Substance
Fra: Ocean Informatics, 2014

108. …jo, på 601 forskjellige måter…
Fra: Ocean Informatics, 2014

109. Strengths and weaknesses for ontologies and information models
Ontology What, Howand Why
+++
Disease, Symptom, Sign, Procedure, Body structure,
Morphology, Substance, Drug, Equipment, Organism
++
Semantic constraints,
Refinement of concepts (e.g. laterality)
+ +
Context-dependent clinical situations, Present / absent / uncertain,
Family history, Previous history, Referred / planned / completed
++
Structural constraints of classes and attributes,
Relationships between journal notes
+++
Date, Time, Duration, Quantity, Text,
Instance (e.g. of people, organization and place), Context
Information model Who, Whenand Where
openEHR
SNOMED CT
Diagram made by Mikael Nyström, Cambio

110. Terms as “questions” in archetypes
Fra: Ocean Informatics, 2014

111. •Default values
•Value sets
•Sometimes difficult to
find a complete set
Terms as “answers” in templates

112. Terms as answers in archetypes 1: Bindings
As terminology bindings to internal value sets

113. Terms as answers in archetypes 2: External value sets

114. Persistence and
query

115. Architecture Overview: paths_and_locators
https://specifications.openehr.org/releases/BASE/latest/architecture_overview.html#_paths_and_locators
ArchetypeQuery Language(AQL)
https://specifications.openehr.org/releases/QUERY/latest/AQL.html
+
https://specifications.openehr.org/releases/QUERY/latest/AQL_examples.html
Query API & Definitions API
https://specifications.openehr.org/releases/ITS-REST/latest/query.html
https://specifications.openehr.org/releases/ITS-REST/latest/definitions.html#definitions-stored-query

118. Tools simplifyingdata entry–form builders,
severalavailable
https://openehr.org/products_tools/platform/

119. Tools simplifyingQuery building
https://openehr.org/products_tools/platform/
Screenshotsfrom
BetterEHR Studio

124. ImplementingnewopenEHRCDR storage/persistence
•First ruleofopenEHRCDR/storageis:
don'tbuildyourown.
•SecondruleofopenEHR CDR/storage is:
don'tbuildyourown,improveexisting
ones instead-orspend time using them
to doclinically useful stuff.
(Wouldyou for example reallybuildyourownDBMS?)
•Third ruleofCDRsis: ifbuildingyourown
becausestoragetechnologyis one of your
main(research) interests, firstread what
has beendone andpublished, both
theory and implementations, thenbuild,
test, publish and share with the world!

127. ImplementingtheopenEHRReferenceModel (RM)
•First ruleofopenEHRRMimplementationis:
don'tbuildyourown.
•SecondruleofopenEHR RMImplementation
is: don'tbuildyourown,improveexisting
ones instead-orspend time using them to
doclinically useful stuff.
•Third ruleofopenEHR RMis:
ifbuildingyourown becauseyou need
support for another programming language,
licence model etc, then firstlearn about the
available machine processable BMM and
OpenAPI formats of the specifications,
thenbuildcompile, test, document and share
with the world!

128. Sharedmodelsand AQL in practice-
Examplefrom a Swedish pilot project;
Data collection in
pathology and
reporting to
quality registries
Basedon images from
Torbjörn Eles, RCC Väst
Eva-Lena Engman, RCC Väst

129. The Interhealth 2022 ”runningexample” (alternative on nextslide)
openEHR
CDR

130. CDR
Receiving system
Lab/Pathology-systems
EHR system+ referral and reply
system
RIS/PACS
System
Forms
Refering
vlinician
BMA Pathologist Radiologist
Source systems
FormsForms
Regional part ofclinical data storage
Cancer registry
*VHS
and other services for sharing
versions, e.g. the
eHälsomyndigheten’s“NGS”
NAG Patologi,
KVAST (expert groups),
openEHR admin and mgmt
Care givers/regions etc.
openEHR CKM
Tools
for templates,
forms, AQL etc.
Example
form
KvalitetsregisterY
System-specific
forms
Patient
forms
Patient
overview
app
*-app
Overview-app
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Surgeon
Orange arrows shows configuration
data/models, not patient data
Algorithm for
narrative
* Version handling usinge.g. GitHub,
GitLab, BitBucket
Integration platform
Quality registry X
Internet
OpenEHR
Templates
for pathology

131. CDR
Receiving system
EHR system+ referral and reply
system
RIS/PACS
system
Pathologist
Source systems
Macro, MicroReferral
Regional part ofclinical data storage
Cancer registry
Internet
GitHub
NAG Patologi,
KVAST (expert groups),
openEHRadmin and mgmt
Care givers/regions etc.
openEHRCKM
Tools
for templates,
forms, AQL etc.
Example
form
KvalitetsregisterY
Patient
forms
IPÖ
Users that want
to continue
working as they
do today
CDR
Read-only
DB
OpenEHR
Templates
for pathology
Quality registry X
System-specific
forms
Order and
result
Orange arrows shows configuration
data/models, not patient data

132. CDR
Receiving system
EHR system+ referral and reply
system
RIS/PACS
system
Pathologist
Source systems
Macro, MicroReferral
Regional part ofclinical data storage
Cancer registry
Internet
KvalitetsregisterY
Patient
forms
IPÖ
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Quality registry X
Order and
result

133. CDR
Receiving system
EHR system+ referral and reply
system
RIS/PACS
system
Pathologist
Source systems
Macro, MicroReferral
Regional part ofclinical data storage
Cancer registry
Internet
KvalitetsregisterY
Patient
forms
IPÖ
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Quality registry X
Order and
result

134. CDR
Receiving system
EHR system+ referral and reply
system
RIS/PACS
system
Pathologist
Source systems
Macro, MicroReferral
Regional part ofclinical data storage
Cancer registry
Internet
KvalitetsregisterY
Patient
forms
IPÖ
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Quality registry X
Order and
result

135. CDR
Receiving system
EHR system+ referral and reply
system
RIS/PACS
system
Pathologist
Source systems
Macro, MicroReferral
Regionalclinical data
Cancer registry
Internet
KvalitetsregisterY
Patient
forms
IPÖ
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Quality registry X
Order and
result

136. CDR
Receiving system
EHR system+ referral and reply
system
RIS/PACS
system
Pathologist
Source systems
Macro, MicroReferral
Regionalclinical data layer
Cancer registry
Internet
KvalitetsregisterY
Patient
forms
IPÖ
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Quality registry X
Order and
result

137. CDR
Receiving system
EHR system+ referral and reply
system
RIS/PACS
system
Pathologist
Source systems
Macro, MicroReferral
Regionalclinical data layer
Cancer registry
Internet
KvalitetsregisterY
Patient
forms
IPÖ
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Quality registry X
Order and
result

138. CDR
Receiving system
EHR system+ referral and reply
system
RIS/PACS
system
Pathologist
Source systems
Macro, MicroReferral
Regional part ofclinical data storage
Cancer registry
Internet
KvalitetsregisterY
Patient
forms
IPÖ
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Quality registry X
Order and
result

139. CDR
Receiving system
Lab/Pathology-systems
EHR system+ referral and reply
system
RIS/PACS
System
Forms
Order and
result
BMA Pathologist Radiologist
Source systems
FormsForms
Regional part ofclinical data storage
Cancer registry
*VHS
and other services for sharing
versions, e.g. the
eHälsomyndigheten’s“NGS”
NAG Patologi,
KVAST (expert groups),
openEHR admin and mgmt
Care givers/regions etc.
openEHR CKM
Tools
for templates,
forms, AQL etc.
Example
form
KvalitetsregisterY
System-specific
forms
Patient
forms
Patient
overview
app
-app
Overview-app
Users that want
to continue
working as they
do today
CDR
Read-only
DB
Surgeon
Orange arrows shows configuration
data/models, not patient data
Algorithm for
narrative
* Version handling usinge.g. GitHub,
GitLab, BitBucket
Integration platform
Quality registry X
Internet
OpenEHR
Templates
for pathology

140. Questions?
Discussion!

141. Bonus tracks
for questions,
extra reading etc.

142. How to transition
to a standardized
approach
Challenges at Karolinska
University hospital that will
use a mix of
-openEHR
-FHIR
-OMOP
-SNOMED CT
etc.

143. Three solution patterns(changingover time)
to correctdata qualityproblems at the source!
162
Old EHR
UsingopenEHR
templates (at least
as a pattern) when
configuring
data input screens
in current
proprietaryEHR
1
openEHR
CDRETL
Old EHR
2
openEHR
CDR
Write-
back
Embedd
openEHR
basedform
in currentEHR
Old EHR
3
openEHR
CDR
Buildappson
openEHRbased
platform
Qualityimprovement& clinicalresearch in collaborationwithpartners Internalneedsat Karolinska

145. INTEGRATION
STRATEGIES
•Core system
•Mapping/conversion-based
•Shared, model-driven ☺

146. Buy the same system, installthe same wayat all organizationsthatwillshareor
exchangeinformation. Pretend“thereis no system B”
Consequence: Causesvendordependencyand anti-competitiveeffectsat the level
wherethe strategyis applied. A singlesystem rarelydoeseverythingwell.
It is a common strategylocally/regionally: Largesystems exist, buttheyarenot
comprehensiveand thusneedto be combinedwithotherstrategies
… and thenthe interoperabilityproblems usuallyreappear!
Example: A region procureslargeEHR system + encouragesmunicipalitiesand others
withinthe geographicarea to usethe same system for the information to be shared.
Stockholm startedbutcancelleda coresystem procurement. VGR (Gothenburg etc) and
Skåne (Malmö etc) haveboughtand arenowinstallingCernerMillniumas a coresystem
1. Coresystem strategy

147. Translate, where possible, from system specific semantics and structures to a standardized exchange format
(message format, API, etc.).
Consequences:
▪Reinterpretations increase risk of loss or distortion of information,
Data that is too different may need to be omitted (Sometimes no data may be better than incorrect data…)
▪Can sometimes require health-IT systems to be rebuiltinternally to be able to capture and export required
shared data in some agreed form (This can be expensive, time/resource consuming, and dependent on
vendors’ priorities).
It is a common strategy today in national cross-regional information exchanges.
Examples: HL7 v2, HL7 v3 CDA, HL7 FHIR, certain applications of ISO 13606, Swedish national "service contracts"
in the service platform coordinated by SKR/Inera.
2. Mapping/conversionbasedstrategy

148. Handledata (semanticsand information structure) the same way
withinsystems usingopenstandardizationofthe content.
Consequences:
▪facilitatesvendorindependence
▪limits selectionto productsthatcaninternallyusethe openstandardizedmodels, or thatcanbe configured
flexiblyenoughto broadlymatch the standardized
Usedtodayin the Nordic region in componentsofseveralEHR systems (butis rarelya requirementin
procurements). Furtherdevelopmentis underwayat severalsuppliers, includingopen-source alternatives
Examples: openEHR, HL7 CIMI and someapplicationsofISO 13606
Region Stockholm mightchoosethis, Karolinska University Hospital has procuredand aresetting
upan openEHR basedsystem.
Most Swedish regions useor willuseCambio Cosmic thatis pieceby piececonverting
modulesto openEHR (NorwegianDIPS startedsucha transitionseveralyearsago.)
3. Sharedmodel-driven strategy

149. 16 December 2021Karolinska Institutet –A medical university 168
The threeintegration strategiescombined
Not mutuallyexclusiveand canbe combineddependingon e.g.
▪Geographicalgranularity
(international, national, regional and local)
▪Timeframe–gradualchanges(1 year, 5 years, 20 years)
Canbe usedto plan a strategictransitionsbetweenstrategies

150. HL7 FHIR AND
OPENEHR
COMBINED?

151. HL7 FHIR openEHR
Main focus •Interoperability (find & use similarity?)
•Exchange and access
”FHIR is not written for clinicians, it's
written for software developers” [2a]
(and other implementation experts)
•Intraoperability [1] (reduce differences inside?)
•Clinical documentation
”openEHR … working at the clinical semantics level with
implementation as a downstream activity” [2b]
Clinical content
selection
•Common patterns implemented in existing
systems. (Plus some other new needs that
can be agreed widely upon.)
•”The 80/20-principle”. [3]
•Reqirements expressed by clinicians and implementing organisations
via an international (sometimes national) online consensus process,
open to all.
Technical focus •Easy/fast to understand and implement •Easy to maintain & extend EHR systems
(new RESTful I/F make it easier to implement)
Local and
speciality-specific
adjustments
Extensions & Profiling
Only non-extended FHIR resources guarantee
easy international interoperability/similarity.
(Extensions can be retrieved and analyzed. Data
entered using previously unseen extensions follow
the FHIR model and can thus be transferred and
read by any system.)
Templates & Archetypes
Only templates and archetype specializations based on international
archetypes guarantee easy interoperability/similarity.
(Local archetypes etc. can be retrieved and analyzed. Data entered using
previously unseen archetypes follow the openEHR model and can thus be
transferred and read by any system.)
Final decisions HL7 member balloting Clinical: mainly consensus in online review rounds –mostly clinicians
Technical:Specifications Editorial Committee (SEC) –mostly EHR
system implementers
[1] Open internal clinical models as in Grahame Grieve’s: Interoperability vs Intraoperability http://www.healthintersections.com.au/?p=820
(Above we do notmean intraoperability around a dominating proprietary vendor as in the definition at http://www.ecis.eu/intraoperability/)
[2a] Lloyd McKenzie 2016 March 28 and [2b] Thomas Beale at March 29, both in https://chat.fhir.org/#narrow/stream/openehr
[3] Grahame Grieve, FHIR and confusion about the 80/20 rule, http://www.healthintersections.com.au/?p=1924

152. OPTIONS WHEN USING FHIR ANDOPENEHR TOGETHER
No alignment(just mapping)
•To FHIR, openEHR canbe seenjust as anyotherEHR-system
(and mappingscanbe donefor somethings)
•To openEHR FHIR canbe seenjust as anyotherexchangeformat
(and mappingscanbe donefor somethings)
Partial alignment(givingbettermappingpossiblilities)
•Alignthe clinicalcontentofsomeimportantresourcesand archetypes. Thenkeepeachother
updatedregardingnew versions. (Alreadydonee.g. for AdverseReactionRisk)
•Createsharedand (inter)nationallymaintainedFHIR extensions/profilesto carrythe extra
datapointsfrom openEHR systems.
Encapsulateonein the other
•Technically possible sometimes, but why do you want it? Semantic differences will be
encapsulated, not solved…
•May create counfusionbecause suddenly there are multiple possibly incompatible models for
the same thing the official and the encapsulated

153. End of
bonus track.
Havea
niceday!