Semantic Roundup January 2017

undefined
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.
 
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?
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)|
  
from StatementContext.context
 
  
52101004 |Present (qualifier value)|
 
 
408732007 |Subject relationship context (attribute)|
 from StatementContext.relationshipToSubject
 
  
116154003 |Patient (person)|
 
 
408731000 |Temporal context (attribute)|
  
 from StatementContext.temporalContext
 
  
410512000 | Current or specified time (qualifier value) |
 
 
246090004 |Associated finding (attribute)|
  
 from ClinicalStatement.StatementTopic
 
  
38341003 |Hypertensive disorder, systemic arterial (disorder)
GENERAL SOLUTION: HOW
 
Both model binding and value binding are required
 
413350009 |Finding with explicit context (situation)|
 
 
408729009 |Finding context (attribute)|
  
from StatementContext.context
 
  
52101004 |Present (qualifier value)|
 
 
408732007 |Subject relationship context (attribute)|
 
from StatementContext.relationshipToSubject
 
  
116154003 |Patient (person)|
 
 
408731000 |Temporal context (attribute)|
  
 
from StatementContext.temporalContext
 
  
410512000 | Current or specified time (qualifier value) |
 
 
246090004 |Associated finding (attribute)|
  
 
from ClinicalStatement.StatementTopic
 
  
38341003 |Hypertensive disorder, systemic arterial (disorder)
Model Binding:
specified in the model;
possibly in instance
Value
from the instance
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:type
 
CIMI_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)
 
 
 Here 
 
   
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?)
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)|
 
or 
  
119419001 |Cyanosis of skin (finding)|
 
   
363714003 |Interprets (attribute)
 
    
364533002 |Color of skin (observable entity)|
 
or 
  
405738005 |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?
7 SEMANTIC FRAMEWORK
 
How do these fit together?
OWL
RDFS
RDF
SNOMED
CT
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)
Slide Note
Embed
Share

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.

  • Semantic
  • Roundup
  • SNOMED CT
  • LOINC
  • Logical Expressions

Uploaded on Feb 27, 2025 | 0 Views


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


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

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

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

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

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

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

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

  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 271649006 |Systolic blood pressure (observable entity)| 704326004 |Precondition (attribute)| 34106002 |Trendelenburg position (finding)|

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

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

  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_20171231_instance ) John_Doe_20171231_instance rdf:typeCIMI_TSBP_Model_123

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

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

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

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

  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)

More Related Content

giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#giItT1WQy@!-/#