This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

Negation Requirements Statement

From HL7Wiki
Revision as of 15:26, 7 June 2016 by Jlyle (talk | contribs)
Jump to navigation Jump to search

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.
  • NKA means someone asked & asserted absence, it's not just a null query.
  • "Negation" is too abstract a term. We'll use more specific terms for respective cases -- "absent," "not done."

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 SCT observable model, observable is the subject, and "present" or "absent" the predicate. This is easier with unary concepts than structured assertions (e.g., 'hypertension' vs. 'sbp > 140').
  • Consistency of representation is better; it reduces chances of error.

Boundary issues

These are topics that arise because they are related to negation, but they are not negation. We address them in order to clarify the boundaries, not to solve them.

Classification

  • How allergies (e.g.) are rolled up; how class model works & is or is not used
    • This is different. Regarding the possibility of inferring "no sulfa allergy" from "no know drug allergies": this is incorrect, as the latter is really null with respect to specific drugs.

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
  • All of these issues are really outside the question of negation.

Silence

  • Statements may be absent as well as their referents
  • Per principles, this is not a concern of this project, except for the CQM case.

Provenance

  • Who asserted a fact may affect how it is interpreted.
  • Some systems don't track Provenance & might need it represented
  • Provenance is a different question. One might doubt positive or negative assertions from certain sources, but that doesn't change their positivity or negativity.

Context

  • Contextual modifiers (family history, risk, etc.) are out of scope. We suspect that the principles may be similar, but we defer the discussion.

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

Design questions

  • Our requirements will be "ontologically pure." 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.
  • But, recognizing the need for designers to design, we also wish to support those efforts by
    • providing principles and guidelines, and
    • suggesting that design patterns address the use case classes we identify