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: Clinical: 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 Clinical Model Editor (AOM/AML) Clinical Visualisation M2 Instance of Constrains Generate Generate Implementation Models CIMI Repository Conforms to M0 CIMI Model Examples International Clinical Model Realm-Specific Clinical Model Generate HL7 v2 HL7 v3 HL7 CDA HL7 FHIR SOA OWL openEHR ISO/CEN XML Schema Specialise & Extend Value Value set Meaning Value set Meaning Value set Meaning CIMI Terminology Server International Reference Terminology Map National Reference Terminology Map Implementation-Specific Terminology Terminology Authoring Tool

CIMI Architectural Overview CIMI Reference Model Archetype Object Model instance of constrains instance of CIMI Model Repository M0 conforms to CIMI Model Examples International Clinical Models coded values value set meaning CIMI Terminology Server 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 CIMI Reference Model Archetype Object Model / Archetype Modelling Language CIMI Modelling Patterns CIMI Style Guide Modelling Approach 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 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 ITEM GROUP ITEM GROUP ELEMENT Clinical Document Clinical Statement Cluster Compound Clinical Statement Indivisible Clinical Statement

Clinical Patterns ITEM GROUP ITEM GROUP ELEMENT Clinical Document Clinical Statement Cluster Action Compound Clinical Statement Indivisible Clinical Statement Observation Set Observation Clinical Activity

Laboratory Models ITEM GROUP ITEM GROUP ELEMENT Clinical Document Clinical Statement Cluster Action Compound Clinical Statement Indivisible Clinical Statement Observation Set Observation Clinical Activity Laboratory Panel Laboratory Test

Laboratory Model Specialisations Laboratory Panel Laboratory Test 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 Ordinal Laboratory Test Quantitative 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 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 We need ADL syntax (grammatical cue) to say that we are binding to a single exact code, as opposed to a value set. (done) Options: a. Propose that we use the SNOMED expression grammar – use “^” to mean “member of set” as opposed to no ^ means “equals” exact code. (Don’t do this.) b. Thomas – we can directly specialize an “ac” code in a parent to an “at” code in the child.

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? Terminology_version: http://snomed.info/sct/900000000000207008 /version/20140731 Term: “The preferred designation”

Model Meaning Binding Domain and attribute approach – for example: id1.1.1 id1.2.1 id1.2.2 id1.2.3

Model Meaning Binding Domain and attribute approach – for example: id1.1.1 id1.2.1 id1.2.2 id1.2.3 id1.2.4

Model Meaning Binding Expression template – for example: id1.1.1 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: id1.2.1 [[ $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)