Negation Principles

Return to Negation_Requirements

1. Absence of evidence is not evidence of absence.
   1. Impact: no requirement is needed to deal with inferred negation because negation cannot be inferred.
   2. CQMs may present an exception, where further information cannot be determined and there is financial impact but no safety risk.
2. Use requirements from real use cases, not inferred cases designed to illustrate potential design issues.
3. Separate requirements & design models.
   1. When addressing design examples, be sure to address the clinical requirement independently of the specific syntax.
4. Avoid double negatives.
   1. Where double negation is unavoidable, the approach should be "idempotent": any number of negations is equivalent to one negation. A subsequent negative does not nullify a prior one.
   2. Where double negation is unavoidable, this rule should be specified explicitly.
5. Avoid excessive abstraction.
   1. Test solutions to ensure that abstraction does not result in ambiguity. Supporting explicit requirements is a good way to do this.
6. Support requirements with minimal transformation.
   1. Transformation introduces risk and cost, and should be avoided, all else being equal.
7. Negation should be handled as consistently as possible without violating semantics of the respective requirements.
   1. Following Einstein's rule: Make everything as simple as possible, and no simpler.
8. Support automated use of semantics to extent possible.
   1. Viz., use semantic codes rather than text where feasible.