CIMI Modelling Taskforce Progress Report Dr Linda Bird, IHTSDO Implementation Specialist.
Post on 17-Dec-2015
218 Views
Preview:
Transcript
CIMI Modelling TaskforceProgress Report
Dr Linda Bird, IHTSDOImplementation 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
CIMI Terminology Server
CIMI Repository
International Clinical Model
CIMI Reference
Model
Constrains
Specialise & Extend
International Reference
Terminology
National Reference
Terminology
MeaningValue Value set Meaning
Map
Conforms
to
Existing Clinical Models
Transform
Clinical Model Editor (AOM/AML)
GenerateM0
M2
Terminology Authoring Tool
Implementation-Specific
Terminology
Map
Value set
Realm-Specific
Clinical Model
Requirements
Clinical Visualisation
Clinical Verification
Generate
Value set
CIMI Model Examples
Implementation Models
GenerateInstance of
DCM CEM CDAopenEHR ISO / CENLRA CMET RMIM
HL7 v2 HL7 v3 HL7 CDAHL7 FHIR SOA OWLopenEHR ISO/CEN
XML Schema
Meaning
CIMI Architectural Overview
CIMI Terminology Server
CIMI ModelRepository
International Clinical Models
CIMI Reference
Model
constrains
CIMI International Reference Terminology
(SNOMED CT + CIMI Extension + LOINC + other code systems)
meaningcoded values
value set
conforms to
M0CIMI Model Examples
Archetype Object Model
instance ofinstance of
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
▪ Foundations1. CIMI Reference Model2. Archetype Object Model / Archetype Modelling Language3. CIMI Modelling Patterns4. CIMI Style Guide
▪ Modelling Approach1. Analyse clinical models submitted (with value sets)2. Identify maximal set of data elements3. Remove ‘out of scope’ data elements4. Select appropriate CIMI Modelling Patterns5. Define CIMI models (Mindmap, ADL, UML)
6. Add Terminology bindingso Value set bindings (maximal set from submitted models)o Model meaning bindings (Domain and attribute)
7. Add Example Model Data Instances8. Technical Validation9. Clinical Verification / Review10. 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
Clinical Statement
ITEM GROUP
Cluster
CompoundClinical Statement
IndivisibleClinical Statement
ELEMENT
Clinical Patterns
Clinical Document
ITEM GROUP
Clinical Statement
ITEM GROUP
Cluster
CompoundClinical Statement
IndivisibleClinical Statement
ELEMENT
Observation Set Observation Clinical Activity
Action
Laboratory Models
Clinical Document
ITEM GROUP
Clinical Statement
ITEM GROUP
Cluster
CompoundClinical Statement
IndivisibleClinical Statement
ELEMENT
Observation Set Observation Clinical Activity
Action
Laboratory Panel Laboratory Test
Laboratory Model Specialisations
Laboratory Panel Laboratory Test
Automated differential panelBlood 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 panelErythrocyte morphology panel
Gas and carbon monoxide panelLeukocyte morphology panel
Manual differential panelPlatelet morphology panelSmear morphology panel
Acanthocytes presence in blood by light
microscopyAnisocytosis presence in
blood by light microscopy
Auer rods presence in blood by light microscopy
Background stain presence in blood by
light microscopy
Laboratory Test Ordinal
Laboratory Test Quantitative
Base deficit in bloodBase excess in blood by
calculationBasophils count per
volume in bloodBasophils per 100
leukocytes in bloodErythrocytes in blood
automatedLymphocytes 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
finding Suspected breast cancer [134405005]
PrecoordProblemModel
Assoc morphology [116676008] Malignant Neoplasm [367651003]
PostcoordProblemModel
Precoordinated Model (CIMI approved Model)
Post coordinated Model (CIMI preferred Model)
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 bindingTo 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 bindingTo 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
definitionITEM_GROUP[id1.1.1.1] matches { -- Laboratory panel
Item matches {ELEMENT[id5.0.2.1] -- Panel codeELEMENT[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/111115Terminology_id: http://snomed.info/sctCode: 111115Terminology_version: -Term: -
▪ What then does a valid instance look like?Uri: http://snomed.info/id/111115Terminology_id: http://snomed.info/sctCode: 111115Terminology_version:
http://snomed.info/sct/900000000000207008 /version/20140731
Term: “The preferred designation”
Model Meaning Binding
▪ Domain and attribute approach – for example:
Fracture
Type(coded text)
Location(coded text)
Laterality(coded text)
125605004fracture of bone
116676008 associated morphology
363698007 finding site
272741003 laterality
id1.1.1
id1.2.1
id1.2.2
id1.2.3
Fracture
Code(coded text)
Type(coded text)
Location(coded text)
Laterality(coded text)
Model Meaning Binding
▪ Domain and attribute approach – for example:
125605004fracture of bone
116676008 associated morphology
363698007 finding site
272741003 laterality
125605004fracture of bone
id1.1.1
id1.2.1
id1.2.2
id1.2.3
id1.2.4
Model Meaning Binding
▪ Expression template – for example:
Fracture
Type(coded text)
Location(coded text)
Laterality(coded text)
125605004fracture of bone
272741003 laterality
116676008associated morphology
$Laterality
$Location
$Type
363698007 finding site
125605004 |fracture of bone|: 116676008 |associated morphology| = [[ $Type ]], 36398007 |finding site| = ([[ $Location ]]: 272741003 |laterality| = [[ $Laterality ]])
id1.1.1
Fracture
Code(coded text)
Type(coded text)
Location(coded text)
Laterality(coded text)
Compositional Value Set Binding
▪ Domain and attribute approach – for example:
272741003 laterality
116676008associated morphology
$Laterality
$Location
$Type
363698007 finding site
$Code
[[ $Code ]]: 116676008 |associated morphology| = [[ $Type ]], 36398007 |finding site| = ([[ $Location ]]: 272741003 |laterality| = [[ $Laterality ]])
id1.2.1
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)
top related