1 negation & null values rough “chalk talk” notes alan rector 2005-05-28 (revised...
TRANSCRIPT
1
Negation & Null Values
Rough “chalk talk” notes
Alan Rector2005-05-28
(revised 2005-06-12)
2
Simple Version
• Case 1: Diabetes– “Some people have diabetes & some people don’t”
xy. [Person(x) & Diabetes(y) & has(x,y)]x. [Person(x) & NOT y.[ Diabetes(y) & has(x,y)]]
– “john has diabetes”• Person(john) & y[Diabetes(y) & has(john, y)]
– “john does not have diabetes”• Person(john) & NOT y[Diabetes(y) & has(john,y)]
3
Simple Version 2:
• Temperature– “All people have a temperature that has a temperature value”
x. Person(x) yz. Temperature(y) & Temperature_value(z) & has_observable(x,y) & has_value(y,z)
– John has a temperature of 37• Person(john) & y. Temperature(y) &
Temperature_value(37_degrees) & has_observable(john, y) & has_value(y,37_degrees).
4
Simple Negation NOT InformativeNegates too much
• Temperature– John has a temperature that is an elevated temperature
• Person(john) & yz. Temperature(y) & Temperature_value(z) & has_observable(john, y) & has_value(y,z) & elevated_for(y,z).
– John does not have a temperature that is an elevated temperature
• Person(john) & NOT yz. Temperature(y) & Temperature_value(z) & has_observable(john, y) & has_value(y,z) & elevated_for(y,z).
5
Alternative value rather than negation
• “John has a Temperature that is not elevated”:• Person(john) & yz. Temperature(y) &
Temperature_value(z) & has_observable(john, y) & has_value(y,z) & NOT elevated_for(y,z).
6
Information loss with negation
y . Termperature(y) & Temperature_value(z) elevated_for(y,z) OR normal_for(y,z) OR depressed_for(y,z)
– Therefore, NOT elevated does not convey (usually) all the information available
• To specify all specify the information available, give the most specific value available:“John has a temperature that is depressed”
– Person(john) & NOT yz. Temperature(y) & Temperature_value(z) & has_observable(john, y) & has_value(y,z) & depressed_for(y,z).
7
Pedal PulsesJust a special case with two values: present/absent
• “All people can have observations of pedal pulses that can be present or absent”
x. Person(x) yz. Pedal_pulse(y) & Present_absent(z) & has_observable(x,y) & has_value(y,z)
– “John’s pedal pulse is present”• Person(john) & y. Pedal_pulse(y) &
Present_absent(present) & has_observable(john, y) & has_value(y, present).
– “John’s pedal pulse is absent”• Person(john) & y. Pedal_pulse(y) &
Present_absent(absent) & has_observable(john, y) & has_value(y, absent).
8
Flavours of Null– “Some people with non-null observational status have
diabetes) xy. Person(x) & Diabetes(y) & non_null(x,Diabetes) & has(x,y)
– “john can be determined to have and has diabetes”• Person(john) & non_null(john, Diabetes)
& y. Diabetes(y)& has(john, y)
– “john does not have diabetes”• Person(john) & non_null(john, Diabetes)
& NOT y. Diabetes(y) & has(john, y)
– “Whether or not john has diabetes cannot be determined”• Person john & NOT non_null(john, Diabetes)
9
Flavours of Null• Temperature
– “All people that have non-null temperature measurement have a temperature that has a temperature value” x. Person(x) & nonNull(x,Temperature)
yz. Temperature(y) & Temperature_value(z) & has_observable(x,y) & has_value(y,z)
– John has a temperature of 37• Person(john) & nonNull(x,Temperature)
y. Temperature(y) & Temperature_value(37_degrees) & has_observable(john, y) & has_value(y,37_degrees).
10
Flavours of Null: Pedal Pulses
• “All people who’s pedal pulses might be reasonably measure can have observations of pedal pulses that can be present or absent”
x. Person(x) & nonNull(x,Pedal_pulse) yz. Pedal_pulse(y) & Present_absent(z) & has_observable(x,y) & has_value(y,z)
11
Non-null – what does it really mean?
• Physical_possibility_status(Person, Entity) “applicability”
– Refers to the patient• E.g. Pedal pulses in a bilateral amputee
• Epistemic_status(Observer, <Person, Entity>) “validity”
– Refers to the observation, method, and sample• E.g. Could not get a clear answer; dropped specimen; haemolised; etc
• nullStatus = applicability x validity
12
Hypothesis
• “Applicability” belongs to the clinical realm and hence to S-CT– A statement about the patient that they atypically do not
have this observable• They are an atypical patient with respect to this observable
• “Validity” belongs to the knowing realm & hence to HL7 (or other info model)– About the observation or procedure rather than the patient
• The patient may or may not be typical (we don’t know, although they probably are) but our method of knowing went wrong.
13
IncludingValidity & applicability
• Add the notion that a statement “concerns” a finding / observable
• Add a wrapper here called “Clinical_situation” which ‘concerns’ findings/observations.
• Some basic rules– If a finding is present then the finding must be applicable to the
patient and the situation concerns the finding– A situation may concern a finding that is applicable to a patient
but absent– A finding may concern a patient but not be applicable
14
So what is our basic form in a message or EHR
• “There is a valid observation by an observer at a time & place with respect to someone/thing of…”
– “A clinical situation that• Includes this clinical finding ( is applicable to this patient concerns this finding
)• Does not include this clinical finding but this finding is applicable to this patient
( concerns this finding)• Concerns this clinical finding and that this finding is inapplicable to this patient
– “There is a clinical situation that• Includes a observable that is applicable to this patient &
has value V ( concerns this observable)• Concerns this observable and that this observable is not applicable to this patient
• “There is an invalid observation by an observer at a time & place with respect to someone/thing of – “A clinical situation that concerns this Observable/Clinical Finding”
• The contents are not relevant since the observation is invalid
15
More on negationWhat are we negating?
What does a code represent?
• From here on logic notation gets very unreadable– Switch to compact OWL syntax
• Roughly outline form with a few extra words– & “and” or “that”– SOME existential (the usual default link in S-CT)
• And with apologies for ignorance of some S-CT vocabulary
16
A Rigorous formal Approach to Negation in S-CT using OWL
• Hypothesis - a code represents a “Clinical situation” (or “syndrome”)– Already present in the way S-CT is structured
• S_CT_Thing & has_morphology SOME MorphologyClass & has_site SOME AnatomicalStructure …
– Where role groups are already added • S_CT_Thing &
has_rg SOME (RoleGroup & has_morphology SOME MorphologyClass & has_site SOME AnatomicalStructure) …
17
So if we identify tentatively for readability and intuitions
• Identify– S_CT_Thing Clinical_situation
– has_rg includes
– RoleGroup (in this context) Finding or Observable
• Then we have something like – Clinical_situation &
includes SOME (Finding has_morphology SOME MorphologyClass &
has_site SOME AnatomicalStructure)
18
So “Skull Fracture without Haemorrage” becomes when fully expanded…
– Clinical_situatsion & includes SOME (Finding & has_morphology SOME Fracture & has_site SOME Skull) & NOT includes SOME (Finding & has_morphology SOME Haemorrhage & has_site SOME Skull)
• And the rest comes for free– At least as a reference formalism
• And for local classification– Well within the capacity of today’s classifiers locally which is all SNOMED needs
19
DemoFrom Protege-OWl
Given a series of definitions of the form:
And underlying definitions such as
Skull_fracture_without_intracranial_haemorrhage_situation =
Intracranial_haemorrhage_finding =
20
Then a flat list of such stated definitions for:
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.
21
Will be rearranged by the OWL classifier to give the correct classification as described in handout automatically
QuickTime™ and aTIFF (LZW) decompressor
are needed to see this picture.