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. There is an incentive to record (justifiable) negations, but no clinical requirement.
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 implementation syntax.
4. Avoid double negatives.
   1. Where double negation is unavoidable, its interpretation should be specified explicitly.
   2. 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.
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.