Semantic Roundup January 2017
This document discusses aligning CIMI with SNOMED CT concept model, usage of LOINC codes, and documented principles for parent-child bindings. Assumptions are made to generate logical expressions programmatically for semantic processing and classification. An example showcases a patient scenario in the context of SNOMED CT.
Download Presentation

Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
CIMI SEMANTICS ROUNDUP January 2017
THIS IS COMPLEX You will find at least one slide that you disagree with.
DOCUMENTED PRINCIPLES SNOMED CT relationship concepts will be used for the parent child binding relationships. Also stated as CIMI model bindings will be informed by the SNOMED CT concept model where appropriate. LOINC codes will be used for observation identifiers. We assume there is a tractable path for using either SNOMED CT observables or LOINC codes as appropriate. SNOMED CT codes will be used for non-medication related clinical concepts in value sets. These have been agreed and documented for some time.
ASSUMPTION #1 We want to align CIMI with the SNOMED CT concept model where feasible.
ASSUMPTION #2 We want to align CIMI with the SNOMED CT concept model where feasible because we want to be able to generate logical expressions that respect common semantic assumptions and that can therefore be compared and classified programmatically.
ASSUMPTION #3 We want to align CIMI with the SNOMED CT concept model where feasible because we want to be able to generate logical expressions that respect common semantic assumptions and that can therefore be compared and classified programmatically. The primary goal is to classify instances to support semantically informed processing (storage, decision support, display). A second goal is to classify models to determine whether models are isosemantic or have some other relationship.
ASSUMPTION #3 We want to align CIMI with the SNOMED CT concept model where feasible because we want to be able to generate logical expressions that respect common semantic assumptions and that can therefore be compared and classified programmatically. What, apart from the SNOMED CT concept model attribute bindings, might this mean? The primary goal is to classify instances to support semantically informed processing (storage, decision support, display). A second goal is to classify models to determine whether models are isosemantic or have some other relationship.
EXAMPLE Patient has hypertension. I.e., 38341003 |Hypertensive disorder, systemic arterial (disorder) Because it s in the SNOMED CT finding axis, this concept has a default interpretation of the patient has this. But we don t do it that way.
GENERAL SOLUTION Because we want presence & absence (& other modifying bits) to always be explicit, CIMI uses the Situation with Explicit Context axis: 413350009 |Finding with explicit context (situation)| 408729009 |Finding context (attribute)| 52101004 |Present (qualifier value)| 408732007 |Subject relationship context (attribute)| 116154003 |Patient (person)| 408731000 |Temporal context (attribute)| 410512000 | Current or specified time (qualifier value) | 246090004 |Associated finding (attribute)| 38341003 |Hypertensive disorder, systemic arterial (disorder)
GENERAL SOLUTION: HOW CIMI supports this solution by providing data for the respective model attributes: 413350009 |Finding with explicit context (situation)| 408729009 |Finding context (attribute)| 52101004 |Present (qualifier value)| 408732007 |Subject relationship context (attribute)| from StatementContext.relationshipToSubject 116154003 |Patient (person)| 408731000 |Temporal context (attribute)| 410512000 | Current or specified time (qualifier value) | 246090004 |Associated finding (attribute)| 38341003 |Hypertensive disorder, systemic arterial (disorder) from StatementContext.context from StatementContext.temporalContext from ClinicalStatement.StatementTopic
GENERAL SOLUTION: HOW Both model binding and value binding are required 413350009 |Finding with explicit context (situation)| 408729009 |Finding context (attribute)| 52101004 |Present (qualifier value)| 408732007 |Subject relationship context (attribute)| from StatementContext.relationshipToSubject 116154003 |Patient (person)| 408731000 |Temporal context (attribute)| 410512000 | Current or specified time (qualifier value) | 246090004 |Associated finding (attribute)| 38341003 |Hypertensive disorder, systemic arterial (disorder) from StatementContext.context Model Binding: specified in the model; possibly in instance Value from the instance from StatementContext.temporalContext from ClinicalStatement.StatementTopic
SO FAR We have some deep problems to address, but does that make sense so far?
THINGS TO WORRY ABOUT Issue 1: Does the situation model work? Issue 2: How does observation discussion affect our expression Issue 3: How do we represent a value binding in an expression? Issue 4: Can we chain properties? Issue 5: Ontology of model & instance Issue 6: Where do we put values? Issue 7: Semantic framework sources & boundaries
1 DOES THE SITUATION MODEL WORK? We need to define some test cases to draft & put into Prot g Does acute chest pain classify as chest pain ? Including modifiers Does head wound without loss of consciousness classify as head wound ? Does no cerebral hemorrhage classify as no subdural hemhorrhage ? Does family history of hypertension fail to classify as hypertension for the patient? Does history of mumps fail to classify as finding of mumps ? Note: we know that SNOMED CT negation does not classify correctly at this time.
2 HOW DOES OBSERVATION DISCUSSION AFFECT OUR EXPRESSION? Can we assert a uniform association (to Finding or Observation)? 413350009 |Finding with explicit context (situation)| 246090004 |Associated finding (attribute)| 271649006 |Systolic blood pressure (observable entity)| 413350009 |Finding with explicit context (situation)| 246090004 |Associated finding (attribute)| 38341003 |Hypertensive disorder, systemic arterial (disorder) And do we need to rename or split the Associated Finding attribute?
2 FINDING, OBSERVABLE, ASSERTION, EVALUATION Criterion for using Assertion vs Evaluation If Evaluation works easily (concept includes both observable topic and value), use it. If best use of Observable Evaluation pattern uses present, then use Assertion Easy cases Evaluation: Systolic Blood Pressure + 120 mmHg Assertion: Diabetes Harder cases Breath sounds = Quality of breath sounds + [Rales/Stridor/ etc.] Cyanosis: assertion Skin color = Cyanotic: Evaluation To do: Create a table of examples to clarify the border
3 VALUE BINDINGS FOR MODELS CIMI models assert value bindings to value sets. We can represent this in an ECL or template as a refset (memberOf). But you can t classify templates. (Confirm?) We need an expression. An OWL expression can use semantics outside of SCT. This will require a clear establishment of which semantics we use from RDF, OWL, & SCT.
Issues from Daniel Cardinality constraints. Multiple sites = multiple lesions or a conjunction of sites
3 VALUE BINDINGS FOR MODELS Option: create an expression with a blank or temporary node that subsumes all values in the value set. <Sitting> subClassOf <temporary_concept_to_represent_position_value_set> <Lying> subClassOf < temporary_concept_to_represent_position_value_set > <Standing> subClassOf < temporary_concept_to_represent_position_value_set > Note: bits in <brackets> are URIs.
4 PROPERTY CHAINING If an observable can have a property 271649006 |Systolic blood pressure (observable entity)| 704326004 |Precondition (attribute)| 34106002 |Trendelenburg position (finding)|
4 PROPERTY CHAINING Can it have a property when it s filling another property? 413350009 |Finding with explicit context (situation)| 408729009 |Finding context (attribute)| 52101004 |Present (qualifier value)| 408732007 |Subject relationship context (attribute)| 116154003 |Patient (person)| 408731000 |Temporal context (attribute)| 410512000 | Current or specified time (qualifier value) | 246090004 |Associated finding (attribute)| 271649006 |Systolic blood pressure (observable entity)| 704326004 |Precondition (attribute)| 34106002 |Trendelenburg position (finding)|
4 PROPERTY CHAINING Approach: break up the expression using temporary (or not temporary) codes. This makes it easier to isolate change. 72313002_A |TEMP CIMI TSBP Clinical finding (finding)| 116680003 |Is a (attribute)| 72313002 |Systolic arterial pressure (observable entity)| 363714003 |Interprets (attribute) 271649006_B | TEMP CIMI T-Systolic blood pressure (observable entity)| 271649006_B | TEMP CIMI T-Systolic blood pressure (observable entity)|: subset of 116680003 |Is a (attribute)| 271649006 |Systolic blood pressure (observable entity)| 704326004 |Precondition (attribute)| 34106002 |Trendelenburg position (finding)|
5 MODEL & INSTANCE ONTOLOGY The model expression uses Situation with Explicit Context as its unqualified representation: what the model represents is-a situation concept (OWL SubclassOf ). Instances are not classes. There is no SNOMED CT term for this A-box relationship. The OWL relationship is ClassAssertion. The RDF relationship is rdf:type. ClassAssertion( a:CIMI_TSBP_Model_123 a:John_Doe_20171231_instance ) John_Doe_20171231_instance rdf:typeCIMI_TSBP_Model_123
6 VALUES For unary Finding values, a.k.a. Assertions, the concept model has a clear home for concepts. 413350009 |Finding with explicit context (situation)| 408729009 |Finding context (attribute)| 52101004 |Present (qualifier value)| 408732007 |Subject relationship context (attribute)| 116154003 |Patient (person)| 408731000 |Temporal context (attribute)| 410512000 | Current or specified time (qualifier value) | 246090004 |Associated finding (attribute)| 38341003 |Hypertensive disorder, systemic arterial (disorder) Here
6 VALUES Coded Evaluation values also have a home in the concept model. 413350009 |Finding with explicit context (situation)| . . . 246090004 |Associated finding (attribute)| 38341003 |Hypertensive disorder, systemic arterial (disorder) 363714003 |Interprets (attribute) 271649006 |Systolic blood pressure (observable entity)| OR 246090004 |Associated finding (attribute)| 271649006 |Systolic blood pressure (observable entity)| (but where did the resulting finding go?) Here Assuming this concept has a range that can include concepts as well as quantities
6 VALUES Non-coded Evaluation values don t seem to have a home in the concept model. 413350009 |Finding with explicit context (situation)| 408729009 |Finding context (attribute)| 52101004 |Present (qualifier value)| 408732007 |Subject relationship context (attribute)| 116154003 |Patient (person)| 408731000 |Temporal context (attribute)| 410512000 | Current or specified time (qualifier value) | 246090004 |Associated finding (attribute)| 271649006 |Systolic blood pressure (observable entity)| ??? 120 mmHg ???
6 VALUES Coded Evaluation values also have an issue: should the finding be sufficient? Could a less rich finding + observable equate to the unary finding? 246090004 |Associated finding (attribute)| 304229000 |Blue skin (finding)| 119419001 |Cyanosis of skin (finding)| 363714003 |Interprets (attribute) or 364533002 |Color of skin (observable entity)| Or is this a place where we simply need do define a CIMI relationship for observed values. In SNOMED CT, or in a CIMI RDF extension? or 405738005 |Blue color (qualifier value)|
7 SEMANTIC FRAMEWORK How do these fit together? OWL SNOMED CT RDFS RDF
NOTES CIMI is about building models with unambiguous meaning. Deriving computable expressions is a good thing, but it should not impede the primary work. Where is the binding reference that a recipient needs to assign an attribute to a property? In a CIMI archetype library? In a Template library? We can create model bindings in archetypes, but SCT Templates would support inter-element constraints; e.g., if finding pre- coordinates finding site, finding site cannot conflict. Do we want to specify the binding in two places, or specify once and let the other inherit? Don t do negation in terminology; i.e., not precoordinated. SNOMED negation classification doesn t work the way clinicians are going to want it to work. Finding/Observation issue: distinguish Assertion and Evaluation in examples. Yes, something that could be either needs an isosemantic transform. Stan will collect examples of Assertions & Evaluations. We need examples of Negation. Some are considering an observation result pattern where observable has value (some concept or concrete value)