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

Difference between revisions of "Negation Requirements Statement"

From HL7Wiki
Jump to navigation Jump to search
 
(One intermediate revision by the same user not shown)
Line 8: Line 8:
 
* We're discussing negating assertions, not knowledge base axioms. They are all contingent, or "defeasible."
 
* We're discussing negating assertions, not knowledge base axioms. They are all contingent, or "defeasible."
 
* A negation has the temporal scope of what it negates; e.g., "no wheezing on examination"; "no history of tobacco use"
 
* A negation has the temporal scope of what it negates; e.g., "no wheezing on examination"; "no history of tobacco use"
 +
* We want to address use cases contributors call "negation," whether we find explicit articulation of negation is helpful or not. E.g., "asplenia" is a condition, and we have identified no requirements to represent it as "spleen absent," but that's a judgement we need to communicate. "Appendectomy," however, has not been suggested as a case for which negative semantics are problematic. As a result, the class model may contain assertions of presence in order to illustrate the asplenia example, but we have no need to represent procedure performed.
  
 
==Semantics==
 
==Semantics==
Line 58: Line 59:
  
 
===Design questions===
 
===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.
+
* Our requirements will strive to 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
 
* But, recognizing the need for designers to design, we also wish to support those efforts by
 
** providing principles and guidelines, and
 
** providing principles and guidelines, and
 
** suggesting that design patterns address the use case classes we identify
 
** suggesting that design patterns address the use case classes we identify

Latest revision as of 14:59, 6 July 2017

Back to Negation Requirements

Scope

  • Things typically referred to as "negated," typically including
    • finding of negative (strep negative); findings absent (no rash); finding of observable absent (no spleen)
    • procedures not done
    • other statements that are or may be phrased with a "not" (goal not held)
  • We're discussing negating assertions, not knowledge base axioms. They are all contingent, or "defeasible."
  • A negation has the temporal scope of what it negates; e.g., "no wheezing on examination"; "no history of tobacco use"
  • We want to address use cases contributors call "negation," whether we find explicit articulation of negation is helpful or not. E.g., "asplenia" is a condition, and we have identified no requirements to represent it as "spleen absent," but that's a judgement we need to communicate. "Appendectomy," however, has not been suggested as a case for which negative semantics are problematic. As a result, the class model may contain assertions of presence in order to illustrate the asplenia example, but we have no need to represent procedure performed.

Semantics

  • Davide's logical model of finding:
    • 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 is not just a null query.
    • The question was asked, so there is some confidence that there are no allergies to substances to which the patient has been exposed.
    • However, there is no information about other substances.
  • "Negation" is too abstract a term for domain information modeling. We'll use more specific terms for respective cases -- "absent," "not done."
    • Negation is the appropriate concept when statements of absence are made in description logics.

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 the kind of ambiguity that results from a committed emphasis on abstraction & terminology neutrality.
  • 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').
    • There are cases that don't fit, e.g., the condition of asplenia. This could be represented as "spleen: absent," but that would be unorthodox.
  • 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 known drug allergies": this is incorrect, as the latter is really null with respect to specific drugs.

Epistemology, Certainty

  • "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 strive to 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