1 / 21

Negation & Null Values

Negation & Null Values. Rough “chalk talk” notes Alan Rector 2005-05-28 (revised 2005-06-12). 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”

lavi
Download Presentation

Negation & Null Values

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation 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: Skull_fracture_without_intracranial_haemorrhage_situation = And underlying definitions such as Intracranial_haemorrhage_finding =

  20. Then a flat list of such stated definitions for:

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

More Related