1 / 27

CIMI Modelling Taskforce Progress Report

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:

sean-francis
Download Presentation

CIMI Modelling Taskforce Progress Report

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CIMI Modelling TaskforceProgress Report Dr Linda Bird, IHTSDO Implementation Specialist

  2. 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.

  3. 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

  4. 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 Conforms to CIMI Repository M0 Realm-Specific Clinical Model Generate International Clinical Model CIMI Model Examples HL7 v2 HL7 v3 HL7 CDA HL7 FHIR SOA OWL openEHR ISO/CEN XML Schema Specialise & Extend Value set Meaning Value set Meaning Value set Meaning Value CIMI Terminology Server Implementation-Specific Terminology Map Map International Reference Terminology National Reference Terminology Terminology Authoring Tool

  5. CIMI Architectural Overview Archetype Object Model CIMI Reference Model constrains instance of instance of CIMI Model Repository conforms to M0 International Clinical Models CIMI Model Examples coded values value set meaning CIMI Terminology Server CIMI International Reference Terminology (SNOMED CT + CIMI Extension + LOINC + other code systems)

  6. Modelling Approach Modularfor 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 Extensibleto support local requirements Bound to terminology for isosemanticity & interoperability

  7. 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

  8. CIMI Reference Model v1.0.0

  9. CIMI Reference Model v2.0.2

  10. CIMI Reference Model v2.0.2

  11. CIMI Reference Model v2.0.2

  12. Reference Model Patterns ITEM GROUP ITEM GROUP ELEMENT Clinical Statement Clinical Document Cluster Compound Clinical Statement Indivisible Clinical Statement

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

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

  15. 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

  16. 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)

  17. Isosemantic Models Precoordinated Model (CIMI approved Model) PrecoordProblemModel Suspected breast cancer [134405005] finding Post coordinated Model (CIMI preferred Model) PostcoordProblemModel Malignant Neoplasm [367651003] Assoc morphology [116676008] Breast structure [76752008] Finding site [363698007] Suspected [415684004] Finding context [408729009] Subject of record [410604004] Subject rel context [408732007]

  18. 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

  19. 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

  20. 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

  21. 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>>

  22. 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”

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

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

  25. Model Meaning Binding id1.1.1 125605004 |fracture of bone|: 116676008 |associated morphology| = [[ $Type ]], 36398007 |finding site| = ([[ $Location ]]: 272741003 |laterality| = [[ $Laterality ]]) Expression template – for example:

  26. Compositional Value Set Binding id1.2.1 [[ $Code ]]: 116676008 |associated morphology| = [[ $Type ]], 36398007 |finding site| = ([[ $Location ]]: 272741003 |laterality| = [[ $Laterality ]]) Domain and attribute approach – for example:

  27. 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)

More Related