1. 1 Negation & Null Values Rough “chalk talk” notes Alan Rector 2005-05-28 (revised 2005-06-12)

2. 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. 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. 4 Simple Negation NOT Informative Negates 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. 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. 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. 7 Pedal Pulses J ust 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. 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. 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. 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. 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, )  “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. 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. 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. 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. 15 More on negation What 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. 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. 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. 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. 19 Demo From 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. 20 Then a flat list of such stated definitions for:

21. 21 Will be rearranged by the OWL classifier to give the correct classification as described in handout automatically