Presentation is loading. Please wait.

Presentation is loading. Please wait.

CIMI Semantics Roundup

Similar presentations


Presentation on theme: "CIMI Semantics Roundup"— Presentation transcript:

1 CIMI Semantics Roundup
January 2017

2 This is complex You will find at least one slide that you disagree with.

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

4 Assumption #1 We want to align CIMI with the SNOMED CT concept model where feasible.

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

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

7 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. What, apart from the SNOMED CT concept model attribute bindings, might this mean?

8 Example Patient has hypertension. I.e.,
|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.

9 General solution Because we want presence & absence (& other modifying bits) to always be explicit, CIMI uses the Situation with Explicit Context axis: |Finding with explicit context (situation)| |Finding context (attribute)| |Present (qualifier value)| |Subject relationship context (attribute)| |Patient (person)| |Temporal context (attribute)| | Current or specified time (qualifier value) | |Associated finding (attribute)| |Hypertensive disorder, systemic arterial (disorder)

10 General solution: How CIMI supports this solution by providing data for the respective model attributes: |Finding with explicit context (situation)| |Finding context (attribute)| from StatementContext.context |Present (qualifier value)| |Subject relationship context (attribute)| from StatementContext.relationshipToSubject |Patient (person)| |Temporal context (attribute)| from StatementContext.temporalContext | Current or specified time (qualifier value) | |Associated finding (attribute)| from ClinicalStatement.StatementTopic |Hypertensive disorder, systemic arterial (disorder)

11 Model Binding: specified in the model; possibly in instance
General solution: How Both model binding and value binding are required |Finding with explicit context (situation)| |Finding context (attribute)| from StatementContext.context |Present (qualifier value)| |Subject relationship context (attribute)| from StatementContext.relationshipToSubject |Patient (person)| |Temporal context (attribute)| from StatementContext.temporalContext | Current or specified time (qualifier value) | |Associated finding (attribute)| from ClinicalStatement.StatementTopic |Hypertensive disorder, systemic arterial (disorder) Value from the instance Model Binding: specified in the model; possibly in instance

12 So far We have some deep problems to address, but does that make sense so far?

13 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

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

15 2 How Does Observation Discussion Affect Our Expression?
Can we assert a uniform association (to Finding or Observation)? |Finding with explicit context (situation)| |Associated finding (attribute)| |Systolic blood pressure (observable entity)| |Hypertensive disorder, systemic arterial (disorder) And do we need to rename or split the “Associated Finding” attribute?

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

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

18 Issues from Daniel Cardinality constraints. Multiple sites = multiple lesions or a conjunction of sites

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

20 4 Property Chaining If an observable can have a property
|Systolic blood pressure (observable entity)| |Precondition (attribute)| |Trendelenburg position (finding)|

21 4 Property Chaining Can it have a property when it’s filling another property? |Finding with explicit context (situation)| |Finding context (attribute)| |Present (qualifier value)| |Subject relationship context (attribute)| |Patient (person)| |Temporal context (attribute)| | Current or specified time (qualifier value) | |Associated finding (attribute)| |Systolic blood pressure (observable entity)| |Precondition (attribute)| |Trendelenburg position (finding)|

22 4 Property Chaining Approach: break up the expression using temporary (or not temporary) codes. This makes it easier to isolate change. _A |TEMP CIMI TSBP Clinical finding (finding)| |Is a (attribute)| |Systolic arterial pressure (observable entity)| |Interprets (attribute) _B | TEMP CIMI T-Systolic blood pressure (observable entity)| _B | TEMP CIMI T-Systolic blood pressure (observable entity)|: subset of |Systolic blood pressure (observable entity)| |Precondition (attribute)| |Trendelenburg position (finding)|

23 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_ _instance ) John_Doe_ _instance rdf:type CIMI_TSBP_Model_123

24 6 Values For unary Finding values, a.k.a. Assertions, the concept model has a clear home for concepts. |Finding with explicit context (situation)| |Finding context (attribute)| |Present (qualifier value)| |Subject relationship context (attribute)| |Patient (person)| |Temporal context (attribute)| | Current or specified time (qualifier value) | |Associated finding (attribute)| |Hypertensive disorder, systemic arterial (disorder)  Here

25 6 Values Coded Evaluation values also have a home in the concept model. |Finding with explicit context (situation)| . . . |Associated finding (attribute)| |Hypertensive disorder, systemic arterial (disorder)  Here |Interprets (attribute) |Systolic blood pressure (observable entity)| OR (but where did the resulting finding go?) Assuming this concept has a range that can include concepts as well as quantities

26 6 Values Non-coded Evaluation values don’t seem to have a home in the concept model. |Finding with explicit context (situation)| |Finding context (attribute)| |Present (qualifier value)| |Subject relationship context (attribute)| |Patient (person)| |Temporal context (attribute)| | Current or specified time (qualifier value) | |Associated finding (attribute)| |Systolic blood pressure (observable entity)| ??? – 120 mmHg – ???

27 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? |Associated finding (attribute)| |Blue skin (finding)| or |Cyanosis of skin (finding)| |Interprets (attribute) |Color of skin (observable entity)| or |Blue color (qualifier value)| 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?

28 7 Semantic Framework How do these fit together? OWL SNOMED CT RDFS RDF

29 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)


Download ppt "CIMI Semantics Roundup"

Similar presentations


Ads by Google