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)