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)