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 meaning should be specified clearly and 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.
   2. The use of Boolean data types in information modeling is almost always excessively abstract and should be avoided.
      1. When it is not avoidable (e.g., in V3 patterns), its meaning should be specified clearly and explicitly.
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.
   2. The difficulty is in defining when things are similar. The catalog approach of this project is designed to address that concern.
8. Support automated use of semantics to extent possible.
   1. Viz., use semantic codes rather than text where feasible.
9. Precoordination is generally to be avoided, except where properties are not generally needed for query or computation.
   1. Most systems do not support parsing of DL expressions: whenever a property may be used to distinguish data (a query, a rule), it should be accessible to those systems.
   2. Where this information is not commonly used (though it might be useful in some circumstances), it may be precoordinated -- e.g., LOINC codes.
   3. This principle is intended to align with the CIMI principles.