1 / 33

CIMI Terminology Binding

CIMI Terminology Binding. Dr Linda Bird 13 th April 2013. Agenda. Use Cases and Requirements Proposed Approach Example Lab Results Bindings Terminology Reference Sets Archetype Object Model Support Future Work. USE CASES AND REQUIREMENTS. Use Cases for Terminology in Models.

mandek
Download Presentation

CIMI Terminology Binding

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 Terminology Binding Dr Linda Bird 13th April 2013

  2. Agenda • Use Cases and Requirements • Proposed Approach • Example Lab Results Bindings • Terminology Reference Sets • Archetype Object Model Support • Future Work

  3. USE CASES AND REQUIREMENTS

  4. Use Cases for Terminology in Models • Management and quality control of model libraries • Searching model libraries (e.g. Find all archetypes with a meaning << Observable Entity) • Identifying semantic overlap between models (e.g. 2 models that contain a cluster whose elements have the same or similar meanings) • Inconsistency of model interdependencies (e.g. the meaning of a constrained archetype is not subsumed by the meaning of the base archetype) • Transforming between isosemantic representations of the model: both • Different levels of precoordination(e.g. ‘Left leg’ versus ‘Leg’ + Laterality= “Left’) • Different representation models (e.g. All ENTRYs with meaning << |Observable entity| to be mapped to a HL7 v3 Observation) • Querying data instances of models (including clinical decision support) which use different representations – for example: • Different level of precoordiation versus structure(e.g. ‘Left leg’ versus ‘Leg’ + Laterality= “Left’) • Different modeling design choices(e.g. Representing a medication’s Indication as a data element, versus an ‘indication’ link to a Diagnosis archetype) • Subsumption testing of values • Supporting data validation and semantic interoperability (e.g. Exchanging data between systems which use different native information structures)

  5. Requirements for using Terminology in Models • Standard (reproducible) way of doing terminology bindings • The ability to represent the valid set of values for a given coded element. • The ability to state the association between the intended interpretation of nodes in the model and concepts in the terminology • Terminology bindings that are agnostic as to whether nodes are connected using a hierarchy or using links. • Terminology bindings that allow the values to be represented in a way that is agnostic to the degree of precoordination versus structure. • Terminology bindings that enable the transformation between isosemantic representations of the same model • Terminology bindings that allow consistency to be checked within models, and between models related by specialisation or used to fill slots (using an underlying ontology).

  6. Management and Quality Control of Model Libraries Example Scenarios • Search for: • An archetype whose meaning ( ̶ context) is subsumed by ‘Cardiovascular Observable’. • Validate archetype specialisations: • To ensure that there is a valid relationship between the meanings of the base and the constrained archetypes – for example: • Not valid: ‘Pulse rate’ (meaning = |pulse finding|) based on ‘Heart rate’ (meaning = |heart rate|) Meaning from different hierarchies • Valid: ‘Pulse rate’ (meaning = |pulse|) based on ‘Heart rate’ (meaning = |heart rate|) Meaning of constrained archetype subsumed by meaning of base archetype • Valid: ‘Family history of diagnosis’ based on ‘Diagnosis’ archetype • Validate archetype slot fillers: • To ensure that the meaning of the slot and the meaning of the archetype that fills it are consistent– for example: • Valid: Using a ‘Problem diagnosis’ archetype (meaning = |clinical finding|) to fill a ‘Cardiovascular problem/diagnosis’ slot (meaning = |cardiovascular finding|). • Using a ‘Problem diagnosis’ archetype to fill the following slots in a discharge summary: • ‘Family history’, ‘Past history’, ‘Current problem/diagnosis’, or ‘Problems’ • Using a ‘Medication’ archetype to fill the following slots in a discharge summary : • ‘Ceased medication’, ‘Current medication’, or ‘Past Medication’

  7. PROPOSED APPROACH

  8. Terminology Binding Approach • The meaning of each node is separated into 3 parts: • Relationship: The relationship from the parent node to this node • Object: The ‘class’ of things defined by this node’s values • Modifier: The context of the node’s meaning – including Subject-relationship, temporal, procedure/finding context, negation, state, certainty • Note: ‘Subject’ of ‘Subject-Relationship-Object’ triple is the parent node

  9. CIMI Terminology Binding Approach BINDING TERMINOLOGY STRUCTURE Medication Cluster: Medication Name Element: Active ingredient Element: Basis of Strength Element: Strength Element: Dose form Element: Indication Element:

  10. Specialising Archetype Meaning (Object) BINDING TERMINOLOGY STRUCTURE Oral Medication Cluster: Medication Name Element: Active ingredient Element: Basis of Strength Element: Strength Element: Dose form Element: Indication Element:

  11. SpecialisingArchetype Meaning (Relationship) BINDING TERMINOLOGY STRUCTURE Medication with Primary Indication Cluster: Medication Name Element: Active ingredient Element: Basis of Strength Element: Strength Element: Dose form Element: Indication Element:

  12. SpecialisingArchetype Meaning (Modifier) BINDING TERMINOLOGY STRUCTURE Current Medication Cluster: Medication Name Element: Active ingredient Element: Basis of Strength Element: Strength Element: Dose form Element: Indication Element:

  13. Filling Archetype Slots STRUCTURE BINDING TERMINOLOGY Discharge Summary Composition Medical record number Element: Primary diagnosis Cluster: Diagnosis Cluster: Diagnosis name Element: Onset datetime Element: Diagnosis datetime Element: Clinical status Element: Comments Element:

  14. Filling Archetype Slots STRUCTURE BINDING TERMINOLOGY Discharge Summary Composition Medical record number Element: Family history Cluster: Diagnosis Cluster: Diagnosis name Element: Onset datetime Element: Diagnosis datetime Element: Clinical status Element: Comments Element:

  15. Example laboratory results model bindings

  16. Laboratory Test Request Summary ENTRY constrains Clinical Entry constrains Clinical Activity constrains Request constrains Observation Request constrains Laboratory Test Request Summary

  17. Clinical Entry

  18. Clinical Entry & Clinical Activity constrains

  19. Clinical Activity & Request constrains

  20. Request & Observation Request constrains

  21. Observation Request & Laboratory Test Request Summary constrains

  22. TERMINOLOGY REFERENCE SETS

  23. Categories of value sets • Clinical value sets • For these we will try to always use SNOMED CT, with the addition of CIMI extension concepts where required. • Non-clinical value sets, with a single authoritative ‘source of truth’  (e.g. IANA media types, country codes) • For these we will take a copy of the value set into our terminology server, so that the values are available during the authoring process and instance generation. • Non-clinical value sets, with no single authoritative ‘source of truth’ (e.g. participation mode) • For these we will provide a maximal set of terms that provides coverage of all member’s value sets, and include a hierarchy that indicates the relationship between a value and its specialisations.

  24. General Principle Value sets which may either be represented in the structure or precoordinated in the definition of another clinical concept (e.g. ‘units of measure’ may be used to define the strength of a medication) would be represented using SNOMED CT, to ensure that the concept definitions can be incorporated into SNOMED CT for isosemanticity .

  25. CIMI Reference Sets

  26. CIMI_link_meaning_refset

  27. Archetype object model support

  28. AOM 1.5 Ontology

  29. Option 1 – Make binding triple explicit To define the ‘relationship-object-modifier’ triplet as an allowable binding statement. ontologyterm_bindings = <        ["/data[cimi-CLUSTER.observe_action] "] = <            relationship = <[SNOMED_CT::5635636|Has related action|]>            object = <[SNOMED_CT::123456|Observation procedure|]>             modifier = <[SNOMED_CT::288529006 |Context values|]>        >        ["/data[cimi-CLUSTER.report_action] "] = <            relationship = <[SNOMED_CT::5635636|Has related action|]>            object = <[SNOMED_CT::243256|Report procedure|]>             modifier = <[SNOMED_CT::288529006 |Context values|]>        >    >

  30. Option 2 – Use SNOMED CT CG Use SNOMED CT Compositional Grammar inline. ontologyterm_bindings = <        ["/data[cimi-CLUSTER.observe_action]"] = <[SNOMEDCT::{5635636|Has related action|=123456|Observation procedure|:288529006|Context values|]>

  31. FUTURE WORK

  32. Future Work • Value bindings: • List the full set of reference sets required • Populate these reference sets • Semantic bindings: • Complete semantic bindings for Model Patterns • Complete semantic bindings for Lab Results Models • Explore the relationship between the ‘Modifier’ binding and data elements, such as ‘Status’, ‘Certainty’, and ‘Negation flag’. • Define other rules and principles • Complete Terminology Binding Style Guide

  33. questions

More Related