This wiki has undergone a migration to Confluence found Here
Difference between revisions of "Negation Requirements Statement"
Jump to navigation
Jump to search
Line 20: | Line 20: | ||
* Or as an 'exclusionary statement' (~openEHR) | * Or as an 'exclusionary statement' (~openEHR) | ||
* V3 Act.negationInd an illustration of what happens when you try to be too abstract/terminology neutral | * 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. | + | * 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'). |
==Boundary issues== | ==Boundary issues== |
Revision as of 16:50, 3 March 2016
Back to Negation Requirements
Contents
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.
- "Negation" may be too abstract a term. Consider openEHR 'exclusion' or SCT 'absence.'
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').
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
- 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.
- Null values. We need to talk about nulls long enough to draw a clear boundary, and then stay away.
- Context. We need to talk about context (e.g., family history) long enough to draw a clear boundary, and then stay away.
- 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.
- Provenance.