CIMI Modelling Taskforce
Progress Report
Dr Linda Bird, IHTSDO
Implementation Specialist
Background
Modelling Taskforce was established to:
▪ Develop CIMI's modelling methodology
▪ Create an initial set of CIMI clinical models
▪ Further test and develop CIMI technical models,
including:
▪ CIMI reference model
▪ Archetype Object Model 1.5, and
▪ CIMI terminology.
Taskforce Outputs
▪ Technical:
▪ CIMI Reference Model
▪ Reference Model Patterns
▪ Archetype Object Model updates
▪ Terminology binding approach
▪ Modelling methodology and style
▪ Clinical:
▪ Clinical patterns (observation & Activity )
▪ Heart Rate model
▪ Laboratory Results models
▪ Laboratory Specialisation models
▪ Demographics models
CIMI Architectural Overview
Existing Clinical Models
Requirements
DCM CEM CDA
openEHR ISO / CEN
LRA CMET RMIM
Clinical
Verification
Transform
CIMI
Reference
Model
Instance
of
Clinical
Model Editor
(AOM/AML)
M Clinical
2Visualisation
Constrains
Generate
Generate
M
0CIMI
Model
Examples
Conforms
to
Implementation Models
International
Clinical Model
Generate
& Extend
CIMI Repository
Value
RealmSpecific
Specialise Clinical Model
Value set
CIMI Terminology Server
Meaning
International
Reference
Terminology
Terminology
Authoring Tool
Value set
Map
Value set
Meaning
National
Reference
Terminology
HL7 v2 HL7 v3 HL7 CDA
HL7 FHIR SOA OWL
openEHR ISO/CEN
XML Schema
Map
Meaning
ImplementationSpecific
Terminology
CIMI Architectural Overview
CIMI
Reference
Model
constrains
instance of
M
0
CIMI
CIMI
Model
Model
Examples
Repository
coded
values
CIMI
Terminology
Server
Archetype
Object Model
conforms
to
instance of
International
Clinical Models
value set
meaning
CIMI International
Reference Terminology
(SNOMED CT + CIMI Extension + LOINC +
other code systems)
Modelling Approach
▪ Modular for reusability of models
▪ Composable to meet specific use-cases
▪ Pattern-based for consistency between models
▪ Constraint-based to allow specialisation
▪ Logical for implementation in multiple formats
▪ Maximal for completeness
▪ Extensible to support local requirements
▪ Bound to terminology for isosemanticity
& interoperability
Modelling Methodology
▪ Foundations
1.
2.
3.
4.
CIMI Reference Model
Archetype Object Model / Archetype Modelling Language
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
Select appropriate CIMI Modelling Patterns
Define CIMI models (Mindmap, ADL, UML)
Add Terminology bindings
o
o
7.
8.
9.
10.
Value set bindings (maximal set from submitted models)
Model meaning bindings (Domain and attribute)
Add Example Model Data Instances
Technical Validation
Clinical Verification / Review
Confirm mappings from submitted models
CIMI Reference Model v1.0.0
CIMI Reference Model v2.0.2
CIMI Reference Model v2.0.2
CIMI Reference Model v2.0.2
Reference Model Patterns
Clinical Document
ITEM GROUP
ELEMENT
Clinical Statement
Cluster
Compound
Clinical Statement
Indivisible
Clinical Statement
Clinical Patterns
Clinical Document
ITEM GROUP
ELEMENT
Clinical Statement
Cluster
Action
Compound
Clinical Statement
Observation Set
Indivisible
Clinical Statement
Observation
Clinical Activity
Laboratory Models
Clinical Document
ITEM GROUP
ELEMENT
Clinical Statement
Cluster
Action
Compound
Clinical Statement
Indivisible
Clinical Statement
Observation Set
Observation
Laboratory Panel
Laboratory Test
Clinical Activity
Laboratory Model Specialisations
Laboratory Panel
Automated differential panel
Blood by automated count panel
Complete blood count panel
- Complete blood count with
automated differential panel
- Complete blood count with
manual differential panel
- Complete blood count
without differential panel
Erythrocyte morphology panel
Gas and carbon monoxide panel
Leukocyte morphology panel
Manual differential panel
Platelet morphology panel
Smear morphology panel
Laboratory Test
Laboratory Test
Ordinal
Acanthocytes presence
in blood by light
microscopy
Anisocytosis presence in
blood by light
microscopy
Auer rods presence in
blood by light
microscopy
Background stain
presence in blood by
light microscopy
Laboratory Test
Quantitative
Base deficit in blood
Base excess in blood by
calculation
Basophils count per
volume in blood
Basophils per 100
leukocytes in blood
Erythrocytes in blood
automated
Lymphocytes count per
volume in blood
CIMI Terminology Binding
▪ SNOMED CT is the primary reference terminology
▪ LOINC is also used as a reference terminology
▪ CIMI will create SNOMED CT extension concepts when
required using the CIMI namespace (1000160)
▪ Models will contain only references to value sets
▪ CIMI supports isosemantic models
▪ One model in an isosemantic family will be selected as the
preferred model for interoperability
▪ A preference will be given to structure over precoordination
(unless precoordinated form is more clinically recognised)
Isosemantic Models
Precoordinated Model (CIMI approved Model)
PrecoordProblemModel
finding Suspected breast cancer [134405005]
Post coordinated Model (CIMI preferred Model)
PostcoordProblemModel
Assoc morphology [116676008] Malignant Neoplasm [367651003]
Finding site [363698007]
Breast structure [76752008]
Finding context [408729009]
Suspected [415684004]
Subject rel context [408732007] Subject of record [410604004]
CIMI use of SNOMED CT
▪
▪
▪
▪
▪
Fixed coded values referenced in models
Value sets referenced in models
Model meaning of models
Pattern for model structure
Translation of precoordinated model content to
postcoordinated model content
Types of Terminology Binding
▪ Value set binding
To record the set of possible values which can populate a given
coded data element or attribute in the information model
▪ Fixed values: A coded data element bound to a single code
▪ Simple: A data element has a single value set
▪ Compositional: The value of a data element is composed from
other values
▪ Model meaning binding
To define the meaning of an information model artefact using a
concept or expression from the terminology
▪ Domain and Attribute: Concept domain with qualifying attributes
▪ Expression Template: The composed meaning of a data group
Terminology Binding Approach
Value Set Binding
▪ Fixed value – for example:
▪ |Panel code|.value: at0.0.0.0.0.1 = http://loinc.org/id/57023-4
▪ |Result value|.value.units: at0.0.0.0.0.1 = http://snomed.info/id/259035002
▪ Simple value set – for example:
▪ |Method|.value: ac0.0.0.0.0.1 = http://snomed.info/id/467614008
or
▪ |Method|.value: ac0.0.0.0.0.1 = ^ http://snomed.info/id/467614008
Model Meaning Binding
▪ Simple model binding – for example:
▪ |Automated differential panel|: id1.1.1.1.1 = http://loinc.org/id/57023-4
Terminology Binding Approach
▪ How (ADL)
▪ Codes assigned in Definition section
▪ URI attached to code in Terminology section
▪ If concept does not exist create in CIMI SNOMED CT extension
definition
ITEM_GROUP[id1.1.1.1] matches {
-- Laboratory panel
Item matches {
ELEMENT[id5.0.2.1]
-- Panel code
ELEMENT[id5.0.0.1] matches {
-- Diagnostic service
value matches {TEXT[ac1.0.2}}
terminology
term_bindings = <
[“snomedct”] = <
[“at2"] = <http://snomed.info/id/78564009>
[“ac1.0.2"] = <http://snomed.info/id/12394009>>
["id5.0.2.1"] = <http://snomed.info/id/363702006>>
Coded Text
▪ We need to state (in the ADL?) how a URI constrains the
parts of a coded text - for example:
▪ http://snomed.info/id/111115 means:
Uri: http://snomed.info/id/111115
Terminology_id: http://snomed.info/sct
Code: 111115
Terminology_version: Term: -
▪ What then does a valid instance look like?
Uri: http://snomed.info/id/111115
Terminology_id: http://snomed.info/sct
Code: 111115
Terminology_version: http://snomed.info/sct/900000000000207008
/version/20140731
Term: “The preferred designation”
Model Meaning Binding
▪ Domain and attribute approach – for example:
Fracture
id1.1.1
Type
(coded text)
id1.2.1
Location
(coded text)
id1.2.2
Laterality
(coded text)
id1.2.3
125605004
fracture of bone
116676008
associated morphology
363698007
finding site
272741003
laterality
Model Meaning Binding
▪ Domain and attribute approach – for example:
Fracture
id1.1.1
125605004
fracture of bone
Code
(coded text)
id1.2.1
125605004
fracture of bone
Type
(coded text)
id1.2.2
116676008
associated morphology
Location
(coded text)
id1.2.3
363698007
finding site
Laterality
(coded text)
id1.2.4
272741003
laterality
Model Meaning Binding
▪ Expression template – for example:
id1.1.1
Fracture
Type
(coded text)
Location
(coded text)
Laterality
(coded text)
125605004
fracture of bone
116676008
associated morphology
363698007
finding site
$Type
$Location
272741003
laterality
$Laterality
125605004 |fracture of bone|:
116676008 |associated morphology| = [[ $Type ]],
36398007 |finding site| = ([[ $Location ]]:
272741003 |laterality| = [[ $Laterality ]])
Compositional Value Set Binding
▪ Domain and attribute approach – for example:
Fracture
Code
(coded text)
Type
(coded text)
Location
(coded text)
Laterality
(coded text)
id1.2.1
$Code
116676008
associated morphology
363698007
finding site
$Type
$Location
272741003
laterality
$Laterality
[[ $Code ]]:
116676008 |associated morphology| = [[ $Type ]],
36398007 |finding site| = ([[ $Location ]]:
272741003 |laterality| = [[ $Laterality ]])
Other Discussions
We will do terminology binding for coded items in the RM
in the first level reference archetypes rather than add
terminology binding syntax in the RM. (Needs further
thought)