In this prezo I have touched upon what an information model is and what is not, especially with relation to terminology. The highlight is to demonstrate the similarities (and differences) between clinical models of openEHR (archetypes & templates) and FHIR. It is obvious that the World doesn't need more standards and a collaborative approach to content development is a necessity. Lastly I make connection with New Zealand's content model approach.
Gen AI in Business - Global Trends Report 2024.pdf
Information Models & FHIR --- It’s all about content!
1. Information Models & FHIR
It’s all about content!
Koray Atalag MD, PhD, FACHI
k.atalag@auckland.ac.nz
Vice Chair HL7 New Zealand
Chair openEHR New Zealand
openEHR Localisation Program Leader
Member HISO
2. Programmes of research in
• Health informatics & technology
• Clinical trials
• Cardiovascular disease
• Addictions
• Nutrition & physical activity
Research services
Teaching
• PG Diploma in Health Informatics
• MSc & PhD
3. (Clinical) Information Models
Myths and Facts
• They are NOT reference information models;
– as in HL7 v3 RIM, openEHR/ISO13606 or FHIR resource ontology!
• They are pure representations of health information
• They may employ a number of formats and methods; inc.
– Mindmaps, pdf, UML, XML/XSD, Archetypes, FHIR resources and even
OO language implementations
• For max semantic interoperability & computability:
formal reference information model – but can be very generic!
• Latest buzzword: Detailed Clinical Models (DCM)
4. What’s in the name?
Terminology: Labels/codes attached to atomic concepts
(mostly without explicit context)
– Diabetes Mellitus, ear ache, left hip, CT scan etc.
Some have hierarchy (ICD) & relationships (SNOMED)
Boundary Problem Terminology binding
Information Model: structure and semantics of concrete
clinical concepts w/ context
– Blood pressure measurement, lab test result, discharge
summary, adverse reaction, prescription etc.
5. The Hard Way:
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
6. Structure with terminology: SNOMED
Inconsistencies due to different post-coordination of concepts
In a vasculitis physical examination: “Vascular exams: Carotid Right/Tender”
247348008 | tenderness (finding) | :
363698007 | finding site | = 69105007 | Carotid artery structure (body structure) | :
24028007 | Right (qualifier value) |
_____________________________________________________________________________
301390006 | tenderness of cardiovascular structure | :
363698007 | finding site | = 69105007 | Carotid artery structure (body structure) |:
272741003 | laterality | = 24028007 | Right (qualifier value) |
_______________________________________________________________________________
309655006 | On examination-artery (finding) | :
69105007 | Carotid artery structure (body structure) | :
24028007 | Right (qualifier) |:
247348008 | tenderness |
_______________________________________________________________________________
401050002 | Carotid artery finding (finding) | :
363698007 | finding site | = 69105007 | Carotid artery structure (body structure) | :
272741003 | laterality | = 24028007 | Right (qualifier value) | :
247348008 | tenderness |
9. Open specs, tools and content for representing
health information & building EHR
– Based on 18+ years of international implementation experience
including Good European Health Record Project
– Origin of ISO/CEN 13606 EHR standard
Not-for-profit organisation - established in 2001
www.openEHR.org
“Inside Systems” vs HIE
Separation of clinical
and technical worlds
• Big international community
10. & Archetypes
• FHIR resources and Archetypes are closely related
– should avoid reinvention at all costs!
• Archetype FHIR resource conversion is
expected to be seamless
– Archetypes are maximal datasets; as opposed to
– FHIR resources include most commonly used items
(e.g. 80%) with an option to extend as needed (e.g.
20%)
• An opportunity exists for FHIR to leverage
openEHR content, tooling and expertise
24. What is a Content Model?
• IT IS A REFERENCE LIBRARY – of validated information models for
health information exchange (and more!)
• Consists of maximal datasets (as opposed to minimal)
– normalised using a standard EHR record organisation (openEHR)
– Expressed as reusable and computable models – Archetypes
• Top level organisation follows CCR
• Only relevant items bound to SNOMED, ICD, LOINC etc.
• Further detail provided by:
– Existing relevant sources (CCDA, Nehta, epSoS, HL7 FHIR etc.)
– Extensions (of above) and new Archetypes (NZ specific)
• Each HIE content (CDA/FHIR/v2) will include one or more models
and formally conform
26. Extending ECM
• Addition of new models
• Making existing models more specific
– powerful Archetype specialisation mechanism:
– Lab result > HbA1C result, Lipid profiles etc.
Problem
Diagnosis
Diabetes
diagnosis
Text or Coded Term
Clinical description
Date of onset
Date of resolution
No of occurrences
Coded Term
+
Grading
Diagnostic criteria
Stage
+
Diagnostic criteria
Fasting > 6.1
GTT 2hr > 11.1
Random > 11.1
First level specialisation
Second level specialisation
27. Exploiting Content Model for Secondary Use
Single Content Model
CDA
FHIR
HL7 v2/3
EHR Extract
UML
XSD/XMI
PDF
Mindmap
PAYLOAD
System A
Data Source A
Map
To
Content
Model
System B
Data Source B
Native openEHR Repository
Secondary Use
Map
To
Content
Model
Automated Transforms
No Mapping
I was trained as a medical doctor with PhD in Information Systems and a Fellow of the Australasian College of Health Informatics.
My main research interests are clinical information modelling, interoperability standards and software maintainability.
I lead the openEHR Localisation Program, vice-chair of HL7 New Zealand and chair openEHR NZ.
Based at the University of Auckland, I am using openEHR Archetypes to create computable clinical information models.
I have co-authored the national Interoperability Reference Architecture (HISO 10040) underpinned by openEHR
I lead the technical evaluation and procurement of major health IT projects and advise the government and industry.
These are the three building blocks – or pillars – of the HISO 10040 series that embodies the central ideas of the Reference Architecture for Interoperability
10040.1 is about regional CDRs and transport
10040.2 is about a content model for information exchange, shaped by the generic information model provided by CCR, with SNOMED as the default terminology, and openEHR archetypes as the chief means of representation
10040.3 is about CDA structured documents as the common currency of exchange – not every single transaction type, but the patient information-laden ones
Published by HISO (2012); Part of the Reference Architecture for Interoperability
“To create a uniform model of health information to be reused by different eHealth Projects involving HIE”
Consistent, Extensible, Interoperable and Future-Proof Data
We will work with Australia and share their Archetype repository as health systems and culture is very similar.
Content is ‘clinician’s stuff’ – not techy; yet most existing standards are meaningless for clinicians and vice versa for techies
openEHR Archetypes are in ‘clinical’ space – easily understood and authored by them
Archetypes can be transformed into numerous formats – including CDA
Archetypes are ‘maximal datasets’ e.g. They are much more granular than other models when needed.
Support more use cases – indeed almost anything to do with EHR (including some workflow). Scope not limited to HIE but whole EHR.
One agreed way of expressing clinical concepts – as opposed to multiple ways of doing it with HL7 CDA (CCDA is a good first step though)
ECM invest in information fulfilled completely – future proof technology today with ECM for tomorrow’s implementation technology (e.g. FHIR etc., distributed workflows etc.)
Definition of health information in each use case (different CDA documents or using Web services based exchange) comes from the same library.
With Archetype specialisation all data collected using definitions of different granularities are semantically compatible.
For example a query retrieving all Lab Tests (not specifically HbA1c) will also fetch all specialised versions of Lab Tests.
A significant opportunity arises for secondary use in this scheme by the use of a data repository that can natively persist and query standardised datasets. Since all health information in transit in various formats (e.g. HL7) within a standard message (payload) conforms to the Content Model, all data persisted in this repository can safely be linked, aggregated and analysed.