This is the prezo I used during the CellML workshop in Waiheke Island, Auckland, New Zealand on 13 April 2015. The aim was to introduce information modelling methods and tools for the purpose of inspiring computational modelling work in the area of semantics and interoperability.

1. Linkages to EHRs and
Related Standards
What can we learn from the Parallel Universe of
Medical Informatics?
Koray Atalag, MD, PhD, FACHI
Senior Research Fellow (ABI & NIHI)
k.atalag@auckland.ac.nz

2. Outline
• Models defined
• Clinical information modelling (CIM)
• EHR interop standards stack
• Clinical Terminology resources
• openEHR & HL7 modelling
• Shared semantics – how to?
• Q/A

3. What is a “Model”?
3: structural design <a home on the model of an old farmhouse>
4: a usually miniature representation of something; also: a
pattern of something to be made
5: an example for imitation or emulation
6: a person or thing that serves as a pattern for an artist;
especially : one who poses for an artist
7: archetype
8: an organism whose appearance a mimic imitates
9: one who is employed to display clothes or other merchandise
10: a type or design of clothing/product
11: a description or analogy used to help visualize something (as
an atom) that cannot be directly observed
12: a system of postulates, data, and inferences presented as a
mathematical description of an entity or state of affairs
Source: Merriam-Webster online (accessed yesterday)

4. Setting the context: Models?
• Biophysical realm: mathematical & anatomical models
– CellML, FieldML, SBML, SEDML, BiosignalML etc.
– But also image or measurement based models
• Medical informatics/EHR realm: information models
– openEHR, HL7, ISO 13606, CIMI, OMG etc.
• Software engineering: many models
– UML, data models (ER, EER)
• Business/Management:
– Business Process, workflow etc.
• Probably many more;
– e.g. generic conceptual models

5. Clinical Information Models
Archetypes, Detailed Clinical Models, Clinical Models etc.
• Depict how clinical information is organized and
described inside an EHR system or repository, or for
EHR communication
• Define both the information structure and formal
semantics of documented clinical concepts
• CIM Facilitate:
– Clinical  technical communication
– Organizing, storing, querying, & displaying data
– Data exchange & distributed computing
– Data linkage, analytics & decision support
* Main purpose is to support healthcare delivery

6. Clinical Information Models - Why?
• Hardcoding domain knowledge into software is bad:
clinical software is difficult (=expensive) to build and
even more difficult to maintain!
– Size and complexity of Biomedicine
– Changeability of requirements (mostly clinical information)
– Variability of practice
• Propriety clinical applications form silos of data
– Non-compatible information hinders data reuse
• One big goal is to employ Model Driven
Architecture/Engineering principles by defining
reusable models with non-ambiguous/shared semantics
 Provides scientific rigour for clinical information
required for Research (e.g. EHR data are dirty!)

7. Example:Blood Pressure Measurement
mindmap representation of openEHR Archetype

8. Example: Clinical Problem/Diagnosis
8
mindmap representation of openEHR Archetype

9. Example: NZ
Cardiac
Registry
9
Screenshot of openEHR Template from a tool

10. Where to they fit?
• Biophysical models: best-effort approximation of
biophysical phenomena (entity & process)
– Quantitative; using math equations for laws of physics &
chemistry acting on biological material properties
– Formal semantics using annotations w/ ontology
• Clinical Information Models: patterns/blueprints
– Capture structure & semantics of clinical information
– Formal semantics using terminology bindings & annotations
– Designed for instantiation  data instances carry real world
data
CIM key to obtaining reliable computable data from EHR
– Can be used to validate biophysical models
– provide parameter values for patient-specific models
– Key to understand effects of environment & random
(unexplained) phenomena

11. Some early explorations
• Physiome/VPH context
Digital Patient (ref: Discipulus Digital Patient Roadmap)
“digital representation of the integration of the different
patients-specific models for better prediction and treatment
of diseases in order to provide patients with an affordable,
personalised and predictive care”
 Use multi-scale integrated biophysical models + CIM

12. Patient Avatar:
digital representation
of all health-related data that is
available for the individual,
as the general basis
for the construction of
Virtual Physiological Human workflows

13. Can the Physiome community learn from this?

14. EHR Interoperability Standards

15. Clinical Terminology
(The study of terms and their use in healthcare)
• Umbrella term for:
– Pure coding: LOINC
(assigning a code to an object or concept)
– Coding/classification: ICD, ICPC, ATC, ICNP
(coding and ordering/grouping within a domain for a
specific purpose; i.e. mortality statistics, costing)
– Nomenclature: GMDN, UMDNS
(assigning a word or phrase to an object or concept)
– Controlled vocabulary: SNOMED, MEDCIN
(all of above plus formal relationships - a way to organize
knowledge). Also known as Semantic Nets
– Also at times ontology

16. Popular Terminologies
• ICD - International Classification of Diseases (by WHO)
– First edition published in 1900! Revised every 10 years
• SNOMED CT - Systematized Nomenclature of Medicine -
Clinical Terms
• LOINC – Lab test orders and results
• READ Codes – v3 used in UK/NZ General Practice
– > 7,000 anatomic concepts, 16,000 operative procedures
and 40,000 disorders
– Hierarchical; code + term or a short phrase about a
healthcare concept
 A big problem is that there are so many alternative
terminologies!

17. SNOMED-CT
(Systematized Nomenclature of Medicine)
• >300,000 biomedical concepts
• ~800,000 English language descriptions (terms)
• ~1.4 million semantic relationships (i.e. IS_A)
• Hierarchically organised in multiple axes
• Addressing the whole EHR space
• Governed by IHTSDO (intl. and powerful)
• Mapped to ICD and through UMLS to 100s others
• Aligned/harmonised with LOINC and HL7
• Considered as formal ontology (OWL representation)
 The single most important terminology now

18. SNOMED Example

19. Coronary
arteriosclerosis
Structural
disorder of heart
Heart disease
Cardiac finding
Cardiovascular
finding
Finding by site
Clinical finding
SNOMED CT
Concept
Mediastinal
finding
Finding of region
of thorax
Finding of trunk
structure
Finding of body
region
Viscus structure
finding
Disorder of
mediastinum
Disorder of
thorax
Disorder of trunk
Disorder by
body site
Disease
Disorder of body
system
Disorder of body
cavity
Disorder of
cardiovascular
system
Disorder of
coronary artery
Coronary artery
finding
Arterial finding
Blood vessel
finding
General finding
of soft tissue
Disorder of soft
tissue of thoracic
cavity
Disorder of soft
tissue of body
cavity
Disorder of soft
tissue
Disorder of
artery
Vascular
disorder
Arteriosclerotic
vascular disease
Soft tissue
lesion
Degenerative
disorder

20. Expressing Composite Clinical
Statements in SNOMED
• Pre-coordinated terms present for most commonly seen
concepts; i.e. gastric ulcer
• Post coordination; more “meaning” can be added by
appending other terms and relationships
– i.e. ulcer | has site: stomach | has severity: low
• Formal mathematical basis (Description Logics)

21. Refining precise semantics
(aka clinical expressions)
 Can be useful for the Biophysical
community for tackling composites??
^ 1111000000132 |allergy event|:
246075003 |causative agent| =
< 373873005 |pharmaceutical / biologic product|
OR
< 105590001 |substance|
HL7 & OMG: CTSII - Common
Terminology Services
-common functional characteristics
-basic functionality to query and access

22. UMLS: Integrating Biomedicine
Unified Medical Language System
Biomedical
literature
MeSH
Genome
annotations
GO
Model
organisms
NCBI
Taxonomy
Genetic
knowledge bases
OMIM
Clinical
repositories
SNOMED CTOther
subdomains
…
Anatomy
FMA
UMLS
By NLM - UMLS integrates and distributes key terminology and ontology (knowledge sources)

23.  Open source specs & software for representing health
information and person-centric records
– Based on 20 years of international research, including Good European
Health Record Project (GEHR)
– Superset of ISO/CEN 13606 EHR standard
 Not-for-profit organisation - established in 2001
www.openEHR.org
 Extensively used in research
 Separation of clinical
and technical worlds
• Big international community
• Recently been elected to Board

24. Archetype
Editor

25. Semantics in openEHR
• Whole-of-model meta-data:
– Description, concept references (terminology/ontology),
purpose, use, misuse, provenance, translations
• Item level semantics (implicit information related)
– Trees/Clusters (Structure)
– Leaf nodes (Data Elements)
• Explicitly: different types of terminology bindings:
– linking an item concept (structure or element) to external
terminology for the purpose of defining its meaning
– Linking of data element values to external terminology
(e.g. a RefSet or terminology query)
– Linking of runtime data element names to external
terminology (e.g. a RefSet or terminology query)
• Instance level semantic annotations – applies to actual
data collected (to be discussed on Tuesday)

26. Example:Blood Pressure Measurement
mindmap representation of openEHR Archetype

27. 32
OnlineModelRepository

28. HL7 FHIR
Fast Healthcare Interoperability Resources
• Very recent! A draft standard but crazy adoption!
– ONC supports, Epic, Cerner, Orion…all big vendors support
• Developer oriented / pragmatic
• RESTful API
• Inspired by modern Web technologies – leveraging W3C
standards and Services oriented App world
• Purpose: Health Information Exchange
– But can underpin an EHR, clinical data repository
• Clinical information defined by Resources;
– 80/20 rule – only model majority of use cases
(as opposed to Archetypes being maximal datasets)
– 20% go into extensions
– Terminology bindings supported

29. Example FHIR
Resource
(Medical Device)

30. Some concluding thoughts
Linking the two universes – shared semantics!
• Semantic annotation mechanisms & tooling already
exist in both universes
– CellML annotations, SemGen, Chaste etc.
– openEHR Archetypes, SNOMED, CTSII etc.
 Key considerations should be:
• Shared ontologies / identifiers
– SNOMED>UMLS> FMA/GO etc.
– But SNOMED and FMA anatomy not same but similar!
Bodenreider O, Zhang S. Comparing the Representation of Anatomy in the
FMA and SNOMED CT. AMIA Annu Symp Proc. 2006;2006:46–50.
• Shared annotation approach (inc. repository)
– RICORDO, PMR2, SemGen etc.
– More research on joint semantic annotations.
• Shared modelling patterns & governance?