Negation Requirements Statement

Back to Negation Requirements

Scope

• The ability to assert that a specific finding is not found. (Also, that an action was not taken.)
• We're discussing negating assertions, not knowlege base axioms. They are all contingient, or "defeasible."
• This is used for findings. You can't negate blood pressure, but you can negate "high blood pressure," or "blood pressure > 140."
• A negation has the temporal scope of the finding it negates; e.g., "no wheezing on examination"; "no history of tobacco use"

Semantics

• Davide's logical model:
  • Subject: need a subject property or at least consistent patterns for 'family history', 'fetus', 'donor'
  • Relationship: "finding"
  • Object: kind of finding. It would be nice to keep this affirmative (avoid "Found no 'absence of wheezing'")
  • Time: hould be implicit in finding (O/E; history). Time assertions may be inconsistent & require reconciliation.
• NKDA means someone asked & asserted absence, it's not just a null query.

Representing negation

• Can model as a separate question: presence of allergy (Y/N); if Y, kinds.
• Or as an 'exclusionary statement' (~openEHR)
• V3 Act.negationInd an illustration of what happens when you try to be too abstract/terminology neutral
• In the observable model, observable is the subject, and "present" or "absent" is the predicate.

Boundary issues

Classification

• How allergies (e.g.) are rolled up; how class model works & is or is not used

Null/epistemology

• "x is true" different from "I know x is true"
• It's not possible to characterize certainty clearly; need a practical & useful approach
• Knowledge at one point in time does not imply knowledge later

Silence

• Statements may be absent as well as their referents

Provenance

• Who asserted a fact may affect how it is interpreted.
• Some systems don't track Provenance & might need it represented

Things to avoid

1. Design questions. Our requirements will reflect ontological purity. Designers may de-normalize things for various practical reasons. As long as the design supports the requirements, the choice of whether to support them in the business layer or the information model is of no concern to us.
2. Null values. We need to talk about nulls long enough to draw a clear boundary, and then stay away.
3. Context. We need to talk about context (e.g., family history) long enough to draw a clear boundary, and then stay away.
4. Data quality. Whether an allergy record is an accurate reflection of real sensitivities, potential cross-reactivities, sensitivities of clinically relevant severities, etc. Interesting, important, out of scope.
5. Provenance.