CIMI Modelling
Taskforce Report
Dr Linda Bird
14th May 2012
Agenda
•
•
•
•
•
Members
Mission & TOR
Overview of work
Call For Models
Modelling Approach
o Background
o Foundations
o Summary of Approach
Taskforce Members
Core Members:
• Linda Bird
• Tom Beale
• Dave Carlson
• Stephen Chu
• Stan Huff
• Mike Lincoln
• Rahil Qamar Siddiqui
• Gerard Freriks
• Josh Mandel
• Mark Shafarman
• Michael van der Zel
Technical Resources:
• Peter Hendler
• Galen Mulrooney
• Grahame Grieve
• Dipak Kalra
• Daniel Karlsson
• Cecil Lynch
• David Moner
Clinical Modelling Resource:
• William Goossen
• Jay Lyle
• Ian McNicoll
• Anneke Goossen
• Heather Leslie
• Marcelo Rodrigues dos Santos
• Sarah Ryan
• Hendry Wijaya
Mission
To develop a CIMI modelling methodology,
style guide and a set of models, which
together demonstrate and test the
approach to CIMI clinical modelling.
Terms of Reference
This taskforce has been established to:
• Further develop and document CIMI's modelling
methodology, including modelling patterns and
modelling style guides;
• Create an initial set of CIMI clinical models to
demonstrate the approach and test the
technical artefacts;
• Further test and develop CIMI technical models
and documentation, including the CIMI
reference model, the Archetype Object Model
1.5, and CIMI terminology.
Planned Deliverables
D1 CIMI Reference Model
D2 CIMI RM Documentation
D3 CIMI Modelling Patterns
D4 CIMI Clinical Models
One or more computable representations (UML & BMM)
One or more artefacts documenting the CIMI RM (Word)
A set of modelling patterns (UML & ADL)
Based on call for models (UML & ADL)
– Heart rate, BMI, Apgar score, Glucose tolerance, Adverse Reaction,
Medication Order, Problem List, Nausea, Wound Culture
– Example instance data
D5 CIMI Modelling MethodologyModelling Style Guide / Best Practices Guidelines Document
– Iterative approach to methodology development
D6 CIMI Terminology
CIMI value sets, semantic concepts, and CIMI SNOMED CT extension
– Documentation of approach to terminology binding
D7 Updates to AOM
Computable representation of AOM to meet CIMI requirements
D8 CIMI Taskforce Report
A report describing the activities of the modelling taskforce, including:
– Mission, Terms of Reference, Planned Deliverables
– Outcomes of work item and summary of results
– Gap analysis and evaluation between UML & AOM approaches
– Methodology for transforming CIMI models into other artefacts, and the
degree of semantic interoperability that is supported by these transformations
– A methodology for subsumption testing of models
– A methodology for providing multiple visualisations of clinical models for
different audiences (both clinical and technical)
– Recommendations
D9 Meeting Minutes
A summary of taskforce meetings
Planned Deliverables
D1 CIMI Reference Model
D2 CIMI RM Documentation
D3 CIMI Modelling Patterns
D4 CIMI Clinical Models
One or more computable representations (UML & BMM)
One or more artefacts documenting the CIMI RM (Word)
A set of modelling patterns (UML & ADL)
Based on call for models (UML & ADL)
– Heart rate, BMI, Apgar score, Glucose tolerance, Adverse Reaction,
Medication Order, Problem List, Nausea, Wound Culture
– Example instance data
D5 CIMI Modelling MethodologyModelling Style Guide / Best Practices Guidelines Document
– Iterative approach to methodology development
D6 CIMI Terminology
CIMI value sets, semantic concepts, and CIMI SNOMED CT extension
– Documentation of approach to terminology binding
D7 Updates to AOM
Computable representation of AOM to meet CIMI requirements
D8 CIMI Taskforce Report
A report describing the activities of the modelling taskforce, including:
– Mission, Terms of Reference, Planned Deliverables
– Outcomes of work item and summary of results
– Gap analysis and evaluation between UML & AOM approaches
– Methodology for transforming CIMI models into other artefacts, and the
degree of semantic interoperability that is supported by these transformations
– A methodology for subsumption testing of models
– A methodology for providing multiple visualisations of clinical models for
different audiences (both clinical and technical)
– Recommendations
D9 Meeting Minutes
A summary of taskforce meetings
Overview of Work
Meeting Summary
July 5
Mission, TOR, Deliverables, Call for Models, Secretary
July 12
Tasks & Activities Planning, Secretary
July 19
Model Submissions, Storage/Github, Modelling Process
July 26
Modelling Patterns: openEHR, NHS LRA
August 2
Modelling Patterns: ADL workbench, SNOMED
August 9
Modelling Patterns: VA, MOHH, R4C, EN13606 Assoc
Heart Rate model submissions: comparative analysis
August 16
HL7 v3, Modelling Pattern Review, CIMI Entry patterns
August 23
CIMI Entry patterns, Heart Rate Model & Style Guide
August 30
Terminology: NHS, Extensions to AOM, Binding Syntax
September 6
Model granularity, Time Series, Heart Rate Terminology
Planning for Rockville
Overview of Work
•
•
•
•
•
•
Infrastructure
Call For Models
Model Submissions - Review
CIMI Modelling Patterns
CIMI Style Guide
CIMI Models
Infrastructure
• Issue tracking (github)
– https://github.com/clinicalmodels/cimi/
• Google doc repository
– Documents, clinical models, reference model, modelling
patterns, model submissions
– http://content.clinicalmodels.org
• Google groups email list
– cimi-modelling-taskforce
– http://groups.google.com/group/cimi-modellingtaskforce?hl=en-GB
• CIMI website
– CIMI models tab, Quick links, Links to the Doc repository
CIMI Modelling
• CIMI Reference Model
– Published draft
– Outstanding issues discussed on github
• CIMI Style Guide & Patterns
– Early draft includes draft quality criteria and modelling principles
• CIMI Modelling Patterns
– ENTRY types (e.g. Observation)
– Isosemantic patterns
– Time series
• CIMI Models
– First draft of CIMI Heart Rate model, based on:
• Comparative analysis of CIMI model submissions
• Proposed OBSERVATION design pattern
Call For Models
Call For Models
• Modelling Patterns
plus:
• Heart Rate
• Body Mass Index
• Apgar Score
• Glucose Tolerance Test Result
• Adverse Reaction
• Medication order
• Problem list
• Nausea
• Wound Culture Result
Model Submissions
• CIHI/Infoway – Allergy/Intolerance, Medication Order
• EN13606 Association – Blood Pressure, Investigation,
Observation, Description of others
• Intermountain Healthcare – All requested models
• Kaiser Permanente – HealthConcern
• MOHHoldings – All models (some generalisations)
• NEHTA – Adverse Reaction, Problem/Diagnosis, Med Order
• NHS – Allergies/Adverse Reaction, Problem&Issue, Diagnosis,
Medication Activity
• openEHR – All models
• Results4Care – Heart rate, BMI, Apgar Score
• Tolven – All models (except Apgar score & wound culture)
• VA – Problem List
Modelling Approach
CIMI Architectural Overview
CIMI Modelling Layers
CLUSTER
ENTRY
SECTION
COMPOSITION
Add
Implementation
Purpose Context
Dispensed
Medications GUI
Neonatal Blood
Pressure in EHR
Current
Medication List in
EHR
Discharge
Summary Doc or
Message
Add Care Setting
Context
G.P. Dispensed
Medication Item
Home Blood
Pressure
Outpatient Clinic
Current
Medication List
Inpatient Discharge
Summary
Add Specialty
Context
Paediatric
Medication Item
Neonatal Blood
Pressure
Nephrologist
Medication List
Cardiology
Discharge
Summary
Add Use Case
Context
Dispensed
Medication Item
Standing Blood
Pressure
Current
Medication List
Medication
Reconciliation
Report
Clinical Models
Medication Item
Blood Pressure
Medication List
Discharge
Summary
Modelling
Patterns
Schedule,
Address,
Material
Observation,
Action
Clinical List
Event Summary,
Assessment
Reference Model
IsoSemantic Models – Example of Problem
e.g. “Suspected Lung Cancer”
IsoSemantic Models – Example Instances
e.g. “Suspected Lung Cancer”
IsoSemantic Models – Graph-based Model
IsoSemantic Models – Compositional Grammar
Problem Diagnosis = $ProblemDiagnosisName:
246090004 |associated finding| = (404684003|Clinical Finding|:
363698007 | finding site | = ($BodySite:
272741003|laterality| = $Laterality),
246112005 | severity| = $Severity),
408729009 | finding context | = $FindingContext
GP Problem Diagnosis = 86049000|Cancer| :
246090004 |associated finding| = (404684003|Clinical Finding| :
363698007 | finding site | = 39607008|Lung|),
408729009 | finding context | = 415684004|Suspected|
Polyclinic Problem Diagnosis = 162572001 |Suspected cancer|:
246090004 |associated finding| = (404684003|Clinical Finding|:
363698007 | finding site | = 39607008|Lung|)
RH Problem Diagnosis = 86049000|Suspected lung cancer|
Overview
• Foundations
1.
2.
3.
4.
CIMI Reference Model
Archetype Object Model
CIMI Modelling Patterns
CIMI Style Guide
• Modelling Approach
1.
2.
3.
4.
5.
6.
Analyse clinical models submitted (with value sets)
Identify maximal set of data elements
Remove ‘out of scope’ data elements (Style Guide)
Select appropriate CIMI Modelling Patterns(Style Guide)
Define CIMI model (Mindmap, ADL, UML)
Add Terminology bindings
o
o
7.
8.
Meaning (nodes, node relationships)
Value sets (maximal set from submitted models)
Add Example Model Data Instances
Technical Validation
o
ADL, UML
9. Clinical Validation / Review
10. Confirm mappings from submitted models
F1. Define CIMI Reference Model
class CIMI Core Reference Model
LINK
+
+
+
meaning :TEXT
target :EHR_URI
type :TEXT
+links
LOCATABLE
0..*
+
+
+
ARCHETYPED
+archetype_details
archetype_node_id :String
name :TEXT
uid :UID_BASED_ID [0..1]
+
+
+
0..1
archetype_id :ARCHETYPE_ID
template_id :TEMPLATE_ID [0..1]
rm_version :String
+participation
PARTICIPATION
0..*
+
+
+
COMPOSITION
+
+
+
category :CODED_TEXT
language :CODED_TEXT
territory :CODED_TEXT
+party
function :CODEABLE_TEXT
time :INTERVAL<DATE_TIME> [0..1]
mode :CODED_TEXT
PARTY_PROXY
1..1
+content 0..*
CONTENT_ITEM
0..*
+items
1..*
+data
ITEM
+items
1..*
DATA_VALUE
SECTION
+value
0..1
1
ENTRY
+
language :CODED_TEXT
CLUSTER
+
structure_type :CODED_TEXT [0..1]
ELEMENT
+
null_flavor :CODED_TEXT [0..1]
F1. Define CIMI Reference Model
class CIMI Data Value Types
IDENTIFIER
+
+
+
YESNO
+
CODED_TEXT
id :String
type :CODED_TEXT
issuer :String
EHR_URI
value :Boolean
+
+
+
+
+
URI
+
value :String
PARSABLE
+
+
code_string :String
terminology_id :TERMINOLOGY_ID
terminology_version :String [0..1]
term :String [0..1]
term_id :String [0..1]
+target
CODEABLE_TEXT
TEXT
formalism :CODED_TEXT
value :String
DATA_VALUE
+
+
1..1
+mappings
0..*
value :String
language :CODED_TEXT [0..1]
TERM_MAPPING
PLAIN_TEXT
+
+
ENCAPSULATED
match :Character
purpose :CODED_TEXT [0..1]
T : ORDERED
MULTIMEDIA
+
+
+
ORDERED
0..1 +upper
INTERVAL
+
+
+
+
+lower
alternate_text :String [0..1]
media_type :CODED_TEXT
uri :URI [0..1]
0..1
«is_im_runtime»
+ data :Byte [0..*] (Array)
+ integrity_check :Byte [0..*] (Array)
upper_unbounded :Boolean
lower_unbounded :Boolean
upper_included :Boolean
lower_included :Boolean
ORDINAL
+
+
symbol :CODED_TEXT
value :Integer
QUANTIFIED
+
magnitude_status :String [0..1]
ABSOLUTE_QUANTITY
AMOUNT
COUNT
+
magnitude :Integer
+
+
accuracy :Real [0..1]
accuracy_is_percent :Boolean [0..1]
TEMPORAL
PROPORTION
QUANTITY
+
+
+
+
numerator :Real
denominator :Real
precision :Integer [0..1]
type :CODED_TEXT
DATE
DURATION
+
+
+
magnitude :Double
units :CODED_TEXT
precision :Integer [0..1]
+
+
value :String
magnitude :Double [0..1]
+
+
value :String
magnitude :Integer [0..1]
TIME
+
+
value :String
magnitude :Double [0..1]
DATE_TIME
+
+
value :String
magnitude :Double [0..1]
F1. Define CIMI Reference Model
•
•
•
•
Updated documentation
Discussion on GitHub regarding issues raised in reviews
Create BMM file to load CIMI Reference Model in ADL Workbench
Automated EA UML to BMM file generation
F2. Archetype Object Model
•
•
•
•
Extend to support relationship meaning
Terminology binding syntax
Review to identify other gaps
Test through use
F2. Archetype Object Model
Relationship_id[0..1]:String
F2. Archetype Object Model
F2. Archetype Object Model
Terminology Binding Syntax
• Semantics/meaning (node and relationships)
• Value sets
• Options
– CTS2
– FHIR
– IHTSDO: URI Specification (Draft)
• E.g. http://snomed.info/sct/{sctid}/version/{timestamp}
– MOHH: URI Specification (Generic binding)
• terminology : <code system id>[:version] ? <query type> = <query
expression> [& <extension key> = extensionvalue]*
• query_type: concept, conceptlist, refset / refsetlist, escg, ocl
• E.g. terminology:2.16.840.1.113883.6.96:20110123?refset=284296007
&scope=CIMI
F3. CIMI Modelling Patterns
Modelling Patterns Reviewed:
• openEHR
• NHS LRA
• SNOMED CT
• results4Care DCMs
• IMH CEMs
• MOHH LIM
• VA’s Discernables
• EN13606 Association
• HL7 v3 RIM
• Tolven
F3. CIMI Modelling Patterns
• Modelling Patterns Considered
– Clinical Statement/Entry Types
• Observation, Evaluation/Finding, Instruction, Action
– Isosemantic Patterns
• Name (focal concept), Details
– Event History/ Time Series
• E.g. Heart rate time series, Apgar score (1, 2, 5, 8, 10 mins)
– Clinical process links
• E.g. interprets, caused by, evidence for, derived from
• Review: ISO13606, LRA, SNOMED CT
– Other Patterns & Reusable Model Components
• E.g. Event summary, Reference Range, Schedule, Material,
Score/Assessment Scale
– State machine / Careflow
• E.g. Medication activity state transitions, Contsys
Clinical Investigator Record (CIR) Ontology
Clinical Statement Types
(Observation)
• openEHR
– Observation, Evaluation, Instruction, Action, Admin Entry
• MOHH
– Observation, Finding, Activity (Medication, Laboratory), Administration
• NHS LRA
– ELEMENTs: Property Observation, Finding Observation, Activity (Investigation,
Material, General), Material Entity
– ENTRYs: GenericFinding, GenericProcedure, GenericProblemAndIssue, ....
• Intermountain/GE
– Observed, StandardLabObs, Procedure, Order, Intolerance, Allergy, Adverse
Reaction Summary, Admit/AdminDiagnosis, ...
• SNOMED CT
– Observable Entity, Clinical Finding, Procedure, ...
• EN13606 Association
– Observation, Evaluation, Instruction, Action
• HL7 v3
– Act (Observation, Procedure, Exposure, Patient Encounter, Financial Contract,
Financial Transaction, Account, Invoice Element, Context Structure, Device,
Task, Supply)
Observation
(Existing Definitions)
• openEHR
– Observation: the observation of any phenomenon or state of interest to do with
the patient.
• NHS LRA
– Property Observation: Used to represent the results of investigations undertaken
to find out more information about a patient's state of health or wellbeing and
device or procedure related parameter settings. (Meaning-value pairs)
• SNOMED CT
– Observable Entity: represents a question or procedure which can produce an
answer or a result. Used to code elements on a checklist or any element where a
value
• EN13606 Association
– Observation/Inspection: Used to define all that can be documented about a
specific state of a process in the Patient System at a point in time using the
faculties of seeing, hearing, tasting, touching, smelling, or directly via a medical
device or service.
• HL7 RIM
– Observation: An Act of recognizing and noting information about the subject, and
whose immediate and primary outcome (post-condition) is new data about a
subject. Observations often involve measurement or other elaborate methods of
investigation, but may also be simply assertive statements.
Observation
(Suggested CIMI Definition)
Used to represent the results of investigations
undertaken to find out more information about a
patient’s state of health or wellbeing, and related
settings.
Comments:
• E.g. Heart rate, Blood glucose
• Represented using the common name-value or questionanswer pattern
• Supports isosemantic representation of Observation
Names that may include method, patient_state, device,
body location and other related information in pre or postcoordinated form.
F3. CIMI Modelling Patterns
(Clinical Entry)
Who
When
Where
What/How/Why
F3. CIMI Modelling Patterns
(Observation)
When
Who
What/Why/How
Where
What
F4. CIMI Style Guide
To describe and demonstrate the approach to CIMI clinical modelling
Goal: Consistency and reproducibility of CIMI models
Table of Contents:
– Background & Architectural Framework
– Reference Model
– Modelling Layers
– Modelling Patterns
– Modelling Principles
• Quality Criteria
• Scope of Clinical Models
• Granularity of Clinical Models
• Consistency and Reuse
• Isosemantic Models
• Terminology Binding
• Additional Principles
– Modelling Methodology
– Appendix: Example models and instance data
F4. CIMI Style Guide
(Quality Criteria – 6.1)
CIMI models will be:
• Able to satisfy the URU principles – that is they will be
–
–
–
–
Understandable (cohesive and coherently expressed)
Reliable and reusable (consistency)
Useful (fit for purpose)
Uptodate (currency)
•
•
•
•
•
Clinically accurate
Clinically valid
Evidence based
Adequate to express required clinical statements
Able to maintain contextual integrity (when transformed into isosemantic
models)
• Able to maintain semantic fidelity (when transformed into isosemantic
models)
• Clear and precise, minimizing the potential for:
– Misinterpretation and
– Misuse or inconsistency in use
• With low complexity (suitable for easy implementation and avoid cognitive
overload of users)
F4. CIMI Style Guide
(Scope – 6.2)
The following information will be included in CIMI clinical
models:
• Information that is considered to be directly relevant to
the clinical concept being modelled.
• Information that describes the who, what, when, where,
how and why of the clinical concept being modelled.
• Information that may either be represented using precoordination or post-coordinated in the structure – for
example, the body location of a diagnosis.
• Information that is not described in the exclusion list.
• To be decided: Information that provides a classification
for other items in the model
F4. CIMI Style Guide
(Scope – 6.2)
The following information will be excluded from CIMI clinical models:
• Information that is specific to an implementation use-case - for example,
recordkeeping metadata (unless the model is specifically designed for
this purpose).
• Information that is specific to a care-setting - for example, hospital ward
details (unless the model is specifically designed for this purpose).
• Information that is specific to a clinical specialty – for example, neonatal
care information (unless the model is specifically designed for this
purpose).
• Information that is used for administrative purposes only – e.g. financial
details (unless the model is specifically designed to include this)
• Information that is specific to a local environment (e.g. to satisfy local
legislation requirements).
• Information that is included in the pattern on which the model is based
• Information that is considered not to be directly related to the clinical
concept being modelled.
F4. CIMI Style Guide
(Granularity of Models – 6.3)
More than one piece of atomic data can be included in the same clinical
model when the following conditions hold:
• The atomic pieces of data are all directly related to the concept being
modelled
• It is considered to be good clinical practice for instances of these data
items to be observed, evaluated or performed together, using the
same who, what, when, where and how information.
For example:
• Systolic and diastolic blood pressures will be included together within
a single ‘Blood Pressure’ observation model.
F4. CIMI Style Guide
(Isosemantic Models – 6.5)
CIMI clinical models will support isosemantic models in terms are both:
• The ability to transform CIMI models to/from isosemantic representations in other
languages/ standards (e.g. CDA, openEHR, ISO13606, DCM, CEM), and
• The ability to transform CIMI models between isosemantic representations that
use a different split between terminology pre-coordination and structure.
The first category of isosemantic models (alternative language representations) will
be supported by defining mappings to other languages. It is not anticipated that
CIMI will provide these mappings, although some exemplars may be provided to
demonstrate the capability.
The second category of isosemantic models (terminology pre-coordination versus
structure) will be supported by:
• Identifying where in the model intensional description logic applies
• Including the structural representation, for any information which may be
represented using a separate attribute in some clinical contexts;
• Defining the semantics of each of these structural attributes using terminology
bindings;
• Defining the semantics of the relationships between these structural attributes
using terminology bindings;
• Identifying the focus attribute of the isosemantic pattern (i.e. the attribute which
may be represented using a precoordination of the other attributes)
• Providing an expression formalism to show the relationship between different
isosemantic forms (e.g. compositional grammar)
F4. CIMI Style Guide
(Terminology Binding)
All finalised CIMI Clinical Models will:
• Include a terminology semantic binding from each node in
the model to a terminology concept (or expression), which
represents the meaning of the node.
• Include a terminology semantic binding from each node
relationship in all isosemantic patterns to a terminology
concept that represents the meaning of the relationship.
All finalised CIMI Clinical Models may (where appropriate):
• Include a terminology semantic binding from other node
relationships to a terminology concept that represents the
meaning of the relationship.
• Include a terminology value binding from a node of type
Codeable Text to a terminology reference set, containing
concepts which represent the set of valid values for the
node.
Overview
• Foundations
1.
2.
3.
4.
CIMI Reference Model
Archetype Object Model
CIMI Modelling Patterns
CIMI Style Guide
• Modelling Approach
1.
2.
3.
4.
5.
6.
Analyse clinical models submitted (with value sets)
Identify maximal set of data elements
Remove ‘out of scope’ data elements (Style Guide)
Select appropriate CIMI Modelling Patterns(Style Guide)
Define CIMI model structure (Mindmap, ADL, UML)
Add Terminology bindings
o
o
7.
8.
Meaning (nodes, node relationships)
Value sets (maximal set from submitted models)
Add Example Model Data Instances
Technical Validation
o
ADL, UML
9. Clinical Validation / Review
10. Confirm mappings from submitted models
M1. Analyse clinical models
submitted (with value sets)
• Heart Rate
o Linda and Marcello
• Body Mass Index
o Gerard and Rahil
• Apgar Score
o William and Michael
• Problem list
o Mike and Galen
• Adverse Reaction
o Stan and Stephen
•
•
•
•
Glucose Tolerance Test Result
Medication order
Care Giver Reported Nausea
Wound Culture Result
M1. Analyse clinical models
submitted (Heart Rate)
• openEHR
– openEHR-EHR.OBSERVATION.heart_rate.v1 – Rev 5
• MOHHoldings
– Observation
• IMH
– HeartRateMeas
• Results4Care
– HeartRate
• EN13606 Association
– Heart Rate ACTION
– Heart Rate OBSERVATION
• NEHTA
– openEHR.EHR.OBSERVATION.heart_rate.v1 – Rev 5
• TOLVEN
– Pulse Rate
M1. Analyse clinical models submitted
(Heart Rate – openEHR/NEHTA)
M1. Analyse clinical models submitted
(Heart Rate – openEHR/NEHTA)
M1. Analyse clinical models submitted
(Heart Rate – openEHR/NEHTA)
M1. Analyse clinical models
submitted (Heart Rate - MOHH)
LID
E12
Name
OBSERVATION
Observing Clinician
E12.19.3
Cardinality Definition
An individual observation that was performed.
0..1
The Healthcare Professional who performed the observation.
Other participants involved in the patient's healthcare, who are relevant to this
Other Participation
0..Many
entry.
Observation Item
The name and/or description of the observation that is associated with this
1
(Design Pattern)
Observation ENTRY.
Observation Name
1
The name of the observation.
A descriptor used in combination with the Observation Name to fully define the
Observation Timing Description 0..1
description of the observation.
Context Group
0..1
Qualifying attributes that define the context of the observation.
E12.19.4
Associated Finding
0..1
E12.19.5
Episodicity
0..1
E12.19.6
E12.19.7
Clinical Course
Site Laterality
Site
0..1
0..Many
0..1
This attribute is used to represent both the course and onset of a disease.
Attributes used to describe the finding site.
The site of the observation measurement
Laterality
0..1
The laterality of the observation measurement
E12.19.8
Severity
0..1
The seriousness of the impact of the adverese reaction on the person.
E12.19.9
Care Setting
0..1
The care setting where the observation took place.
E12.19.10
Category
0..1
The category of the observation - in particular, whether the observation is a based on a
finding (ie. a descriptive term or code) or a property (ie. with an attribute- value pair).
E12.19.11
E12.19.12
E12.19.13
Type
Subtype
Clinical Notes
Observation Status Details
Observation Status
Observation Dates
0..1
0..1
0..1
0..1
0..1
0..1
E12.21.1
Observation DateTime
0..1
E12.22.1
E12.22.2
E12.22.3
E12.22.4
Observation Result
Observation Result Value
Observation Result Value Type
Interpretation
Reference Range
0..1
0..1
0..1
0..1
0..1
E12.17
E12.18
E12.19
E12.19.1
E12.19.2
E12.20
E12.20.1
E12.21
E12.22
This attribute links concepts in the Situation with explicit context hierarchy to their related
Clinical finding. It specifies the Clinical finding concept whose context is being modified.
EPISODICITY is used to represent episodes of care provided by a physician or other care
provider, typically a general practitioner, not episodes of disease experienced by the patient.
The type of the observation.
The subtype of the observation, if required.
The remarks associated with the observation result.
Information related to the status of the observation.
The status of the observation measurement, in terms of its clinical workflow.
Dates associated with the observation.
The point of time, or time interval at/during which the observation took place, such
as an average observation over a time interval.
Information related to the result of the observation.
The result value of the observation.
The data type used to record the observation result value.
An indicator as to whether or not the clinical results are normal or abnormal.
The reference range of the observation.
M1. Analyse clinical models
submitted (Heart Rate - IMH)
M1. Analyse clinical models submitted
(Heart Rate – Results4Care)
class Information Model
Name:
Author:
Version:
Created:
Updated:
PQ
Information Model
Ybranda Koster, Michael van der Zel
0.71
5/11/2009 3:40:04 PM
20/07/2012 12:05:07 AM
«data»
Frequency
«rootconcept»
HeartRate
unit = /min
CD
constraints
{Between 0 and 1000}
CD
«qualifier,enumeration»
Method
«enum»
+ Large
+ Normal
+ Weak
«enum»
+ Auscultation
+ BedsideMonitor
+ ECG
+ Palpation/ manual
+ Ultrasound
CD
«data,enumeration»
Regularity
0..1
CD
«qualifier,enumeration»
Location
«enum»
+ Arteria brachialis
+ Arteria carotis
+ Arteria carotis externa
+ Arteria dorsalis pedis
+ Arteria femoralis
+ Arteria poplitea
+ Arteria radialis
+ Arteria subclavia
+ Arteria temporalis
+ Arteria tibialis
+ Arteria tibialis posterior
+ Fontanel (baby)
Legend
rootconcept
data
qualifier
state
«data,enumeration»
Volume
?
«enum»
+ Irregular
+ Regular
CD
«qualifier,enumeratio...
PointInTime
CD
«enum»
+ 1H min
+ 1H max
+ 1H mean
CD
«state,enumeration»
Exertion
«data,enumeration»
Strength
«enum»
+ In rest
+ Post exercise
+ During exercise
«enum»
+ Normal
+ Strong
+ Weak
CD
«state,enumeration»
BodyPosition
«enum»
+ Lying
+ Sitting
+ Standing
+ Reclining
CD
CD
«data,enumeration»
FrequencyQualification
«enum»
+ Alternating bradycardia and tachycardia
+ Bradycardia
+ Normal
+ Tachycardia
«data,enumeration»
Rhythm
«enum»
+ Bigeminal pulse
+ Bisferiens
+ Extra-systole
+ Irregulair
+ Palpitation
+ Pulsus alternans
+ Pulsus irregularis perpetuus
+ Regular
+ Trigeminal pulse
M1. Analyse clinical models submitted
(Heart Rate – en13606 Assoc)
M1. Analyse clinical models
submitted (Heart Rate - Tolven)
M2. Identify maximal set of data elements
Heart Rate - Data Elements
CIMI
Data Requirement
Data Type
Who
Subject (II)
Participation
Information Provider (II)
Participation
Observer
Participation
Reason for
Exclusion
MOHH
IMH
Results4Care
(Observation)
(HeartRateMeas)
(HeartRate)
Subject (II)
Information Provider
Information Provider (II)
(II)
Observing Clinician (II)
included in
reference model
Participant
openEHR/NEHTA
(openEHREHR.OBSERVATION.
heart_rate.v1 - Rev. 5)
Subject (II)
Subject (Coded)
Participant (II)
Participant (Cluster)
(ParticipationType (Coded)
Role (Coded)
IndividualPerson.PersonIdent
ifier (II)
IndividualPerson.PersonNam
e (Name Cluster)
Participant (II)
record-keeping
use-case
record-keeping
use-case
record-keeping
use-case
ReportedReceived
Verified
Updated
EN13606 Association
(Heart Rate
ACTION)
(Heart Rate
OBSERVATION)
Subject
TOLVEN
(Pulse Rate)
Patient
Performer
ReportedReceived (Cluster)
dataEntered
Author
Verified (Attribution)
Updated (Attribution)
When
included in
reference model
implementation
specific?
Link from (instruction)
Workflow Id
Observation DateTime
DateTime
Observation DateTime
Range
Interval<DateTi
me>
Relative Time
Observation Duration
Observation Offset /
Observation Offset Origin
DateTime
Duration
Duration
Time of Day (Codeabe)
CodedText
Observation Status
Where
CodedText
Location of Subject
Participation
Location of Observer
Participation
Reason (Link to Reason (Link to
INSTRUCTION)
ACTION)
Workflow Identifier (id)
Start Date/Time
(DateTime)
encounter
transition
Observation DateTime
(IVL<DateTime>)
Point in Time
ObservedStartTime
(DateTime)/
ObservedEndTme (DateTime)
Event time (DateTime)
Duration (DateTime)
time of
observation
Range in Time
Relative Time
Events (Event)
Time of Day
(Codeable)
RelativeTemporalContext
(Coded)
Observation Status (Coded)
Observed.PatientLocation
(String)
Observed.ProviderLocation
(String)
statusCode
Location/Addre
ss
M2. Identify maximal set of data elements
Data Requirement
Who
Subject (II)
Information Provider (II)
Observer
Participant
ReportedReceived
Verified
Updated
When
Link from (instruction)
Workflow Id
Observation DateTime
Data Type
Participation
Participation
Participation
DateTime
Interval<DateTim
Observation DateTime Range
e>
Relative Time
Duration
Observation Duration
Duration
Observation Offset /
Observation Offset Origin
DateTime
Time of Day (Codeabe)
CodedText
Observation Status
CodedText
Where
Location of Subject
Participation
Location of Observer
Participation
What (measurement) / How / Why
Observation Name
Observation Reason
Body Position
Confounding Factors
Excertion
Care Setting
Body Location (Cluster):
Body Site
Aggregate Body Site
Body Laterality
BodySide
Body Location Qualifier
Observation Method
Device
Aggregate Function (Codeable)
What (Observation)
Heart Rate
Heart Rate Present?
Regularity
Rhythm
Strength
FrequencyQualification
Volume
Clinical Notes
Interpretation
DeltaFlag
Reference Range
CodedText
CodedText
CodedText
CodeableText
Slot
CodeableText
CodeableText
CodedText
CodedText
CodedText
CodedText
CodeableText
Slot
Quantity
Boolean
String
CodedText
CodedText
Slot
M3. Remove ‘out of scope’ data
elements (Style Guide – 6.2)
The following information will be excluded from CIMI clinical models:
• Information that is specific to an implementation use-case - for example,
recordkeeping metadata (unless the model is specifically designed for
this purpose).
• Information that is specific to a care-setting - for example, hospital ward
details (unless the model is specifically designed for this purpose).
• Information that is specific to a clinical specialty – for example, neonatal
care information (unless the model is specifically designed for this
purpose).
• Information that is used for administrative purposes only – e.g. financial
details (unless the model is specifically designed to include this)
• Information that is specific to a local environment (e.g. to satisfy local
legislation requirements).
• Information that is included in the pattern on which the model is based
• Information that is considered not to be directly related to the clinical
concept being modelled.
M3. Remove ‘out of scope’ data
elements (Style Guide)
Data Requirement
Who
Subject (II)
Information Provider (II)
Observer
Participant
ReportedReceived
Verified
Updated
When
Link from (instruction)
Workflow Id
Observation DateTime
Observation DateTime Range
Relative Time
Observation Duration
Observation Offset / Observation Offset
Origin DateTime
Time of Day (Codeabe)
Observation Status
Where
Location of Subject
Location of Observer
Data Type
Reason for Exclusion
Participation
Participation
Participation
in Clinical Entry Pattern
in Clinical Entry Pattern
in Observation Pattern
in reference model
record-keeping use-case
record-keeping use-case
record-keeping use-case
DateTime
Interval<DateTime>
Duration
Duration
in reference model
implementation specific?
in Observation Pattern
in Observation Pattern
in Observation Pattern
in Observation Pattern
in Observation Pattern
CodedText
CodedText
in Observation Pattern
Participation
Participation
in Observation Pattern
in Observation Pattern
M3. Remove ‘out of scope’ data
elements (Style Guide)
What (measurement) / How / Why
Observation Name
Observation Reason
Body Position
Confounding Factors
Excertion
Care Setting
Body Location (Cluster):
Body Site
Aggregate Body Site
Body Laterality
BodySide
Body Location Qualifier
Observation Method
Device
Aggregate Function (Codeable)
What (Observation)
Heart Rate
Heart Rate Present?
Regularity
CodedText
CodedText
CodedText
CodeableText
Slot
CodeableText
in Observation Pattern
CodeableText
CodedText
CodedText
CodedText
CodedText
CodeableText
Slot
Quantity
Boolean
Out of scope->Specialisation?
Rhythm
Out of scope->Specialisation?
Strength
Out of scope->Specialisation?
FrequencyQualification
Out of scope->Specialisation?
Volume
Clinical Notes
Interpretation
DeltaFlag
Reference Range
Out of scope->Specialisation?
String
CodedText
CodedText
Slot
in Observation Pattern
M4. Select appropriate CIMI
Modelling Pattern (Style Guide)
When
Who
What/Why/How
Where
What
M5. Define CIMI model
(Mindmap, ADL, UML)
When
Who
What/Why/How
Where
What
M6. Add Terminology bindings
openEHR/NEHTA
CIMI node
Source node
SCT term binding
heart rate value
body position
method
at0004
at00013
at1019
Observable entity
Observable entity
Procedure
364075005|Heart rate|
422431001|Body position for procedure|
386053000|Evaluation procedure|
CIMI data type
SCT value set binding
QUANTITY
CODED_TEXT
Clinical finding
CIMI data type
SCT value set binding
QUANTITY
CODED_TEXT
CODED_TEXT
CODED_TEXT
Body structure
Clinical finding
Procedure
Results4Care
CIMI node
Source node
SCT term binding
root
heart rate value
body location
body position
method
at0000
at0001
at0016
at0045
at0054
Observable entity
Observable entity
Attribute
Clinical finding
Qualifier value
364075005|Heart rate|
364075005|Heart rate|
363704007|Procedure site|[2]
9851009|Body position finding|
84203001|Has method|
Proposed Bindings
Attribute
observable
name
reason
body position
confounding factors
time of day
SCT constraint
364075005|Heart rate (Observable entity)|
=<364075005|Heart rate (Observable entity)|
404684003|Clinical finding|
9851009|Body position finding|
404684003|Clinical finding|
272106006|Temporal periods of day|
M6. Add Terminology bindings
M6. Add Terminology bindings
High Level Classes for Observation Model Bindings
• Record artifact
• Observable entity (or LOINC code)
• Clinical findings
• Situation with explicit context
Outstanding Questions
• Which parts of the model should include semantic node bindings?
• Which parts of the model should include semantic relationship
bindings?
• Is it appropriate to extend the SNOMED CT concept model to
support isosemantic requirements?
• Can terminology binding rules, patterns or principles be identified?
• What value set should we use for links between model
components?
• How should we clearly identify the intensional/DL parts of the
model?
M6. Add Terminology bindings
M7. Add Example Instance Data
• Important for both technical and clinical
validation.
• Format for instance data will be discussed
tomorrow.
M8. Technical validation
• Technical validation of:
– Reference Model (e.g. BMM file in ADL workbench)
– Clinical Modelling Patterns (e.g. ADL, UML tools)
– Clinical Models (e.g. ADL, UML tools)
• Requires tooling support – e.g.
– ADL Workbench
– AML (UML Profile) Tooling
– Others
M9. Clinical Validation / Review
• Clinical validation using different representations, such as:
– Mindmaps
– Hierarchy
– UML
– Data entry forms
– Etc
TO DO
• A methodology for providing multiple visualisations of clinical models
for different audiences (both clinical and technical)
M10. Confirm transformations
back to submitted models
• openEHR
– openEHR-EHR.OBSERVATION.heart_rate.v1 – Rev 5
• MOHH
– Observation
• IMH
– HeartRateMeas
• Results4Care
– HeartRate
• EN13606 Association
– Heart Rate ACTION
– Heart Rate OBSERVATION
• NEHTA
– openEHR.EHR.OBSERVATION.heart_rate.v1 – Rev 5
• TOLVEN
– Pulse Rate
Overview
• Foundations
1.
2.
3.
4.
CIMI Reference Model
Archetype Object Model
CIMI Modelling Patterns
CIMI Style Guide
• Modelling Approach
1.
2.
3.
4.
5.
6.
Analyse clinical models submitted (with value sets)
Identify maximal set of data elements
Remove ‘out of scope’ data elements (Style Guide)
Select appropriate CIMI Modelling Patterns(Style Guide)
Define CIMI model (Mindmap, ADL, UML)
Add Terminology bindings
o
o
7.
8.
Meaning (nodes, node relationships)
Value sets (maximal set from submitted models)
Add Example Model Data Instances
Technical Validation
o
ADL, UML
9. Clinical Validation / Review
10. Confirm mappings from submitted models