Position Paper on the use of Negation
Prepared for EHR4CR WPG2 by Prof Dipak Kalra and Julie James, UCL
April 2012
Requirement
The core requirement is to have a mechanism to provide safe, unambiguous machine readable
“negative” statements that would be made in an EHR and that would be uploaded into a clinical data
warehouse, and indeed that would be useful to query against. The following are examples of such
negative statements:





Patient does not have allergy to penicillin
Patient has not taken paracetamol
Patient does not have diabetes mellitus
Finding of spleen palpable not present
Diagnosis of MI not confirmed by cardiac enzymes
It is well known that expressing negation clearly can be challenging; in human language – whether
spoken or written – there are complexities, such as the "double negatives" which can slip in and
cause potential for misunderstanding (for example: “I’m not going to cancel the appointment” – the
appointment still stands, despite the negation (“not” and the negative verb “cancel”) and then a
clinical example - “the patient did not have 'no protein in urine'”). In expressing information for
machine processing, the challenge is even greater, since decisions may be made based on the results
of that processing; denying a patient with suspected meningitis an immediate dose of
benzylpenicillin because of incorrectly processed "does not have allergy to penicillin" information
could have very serious consequences.
The challenge too, is not just to construct a framework that is manageable for a gifted informatician,
be that an information modeller or a terminologist, but to construct something that every clinical
system can implement safely, and that every user can interpret clearly.
In EHR4CR it is important, both for current work and even more crucially as the project moves
towards the more clinically challenging developments in clinical trial data collection and
pharmacovigilance, to describe the principles that will enable clear, unambiguous machine readable
negative statements to be made, processed and queried.
Using the Information Model?
A negation attribute on a class can be used to express negative semantics for the whole class or for
attributes of the class, but it is classically difficult to disambiguate which of these options applies.
The following are examples of such ambiguous negation:
 A "negated observation of (palpitation of) heart apex beat" could mean that the beat was
not palpable, or it could possibly mean that there was no abnormality found (i.e. it was
normal) or it might mean that the examination itself was not performed – although this




latter case could be indicated using a flavour of null – possibly NASK (“not asked” – the
information has not been sought)
"Type II diabetes mellitus was not observed in Patient X on 10th June 2009" expressed as the
negated observation of type II diabetes mellitus with the given date, could mean that Patient
X did not have diabetes mellitus on that date, or it could mean that the person who made
this observation had no evidence that Patient X had diabetes mellitus, when they examined
them on that date
"Appendectomy not performed as planned surgery" described as a procedure, with type
"planned" and a code of "appendectomy" and with a negation indicator – does this mean
that an appendectomy was not performed, or that it was performed but as an emergency
rather than as planned surgery?
A negated administration of morphine with the intravenous route – does this mean no
morphine given at all, or no intravenous morphine given (oral, intramuscular or
subcutaneous morphine may have been administered)?
Coded information of "duodenal ulcer" but, associated with this, some text stating "not
visible on endoscopy", leaving unclear if a duodenal ulcer was looked for but not found and
so has been excluded as a diagnosis, or is known to be a problem but not was visible on this
occasion.
The following two examples show how if both the information model (record structure) and
terminology both indicate negation, it is particularly difficult to know what was truly meant and
therefore what the action for that should be – should the double negation be taken to be emphasis,
or should it be taken to mean the positive assertion? Or is it expected that the negative statement
has been made using both alternatives (information attribute and terminology) and either one
should be used but not both to give the negative information? Due to this ambiguity, some
systems might decide to disregard this sort of data altogether, which in itself can be a problem.
 A negated observation of "ankle reflexes absent" – does this mean that the reflexes were
present (with a sense that it was expected that they would be absent) or does it mean "this
is a negative finding, which is confirmed by the text that the reflexes were absent"?
 A negated observation of "meningism absent" could possibly be understood to be
emphasising negation – "there really is no evidence of meningism" – because to use a
double negative for a positive assertion in this case would be extremely unlikely
Negated Relationships
Another method of describing negation in an information model concerns the relationships between
classes - having a negation attribute on a relationship to express negative semantics between those
classes. But this suffers from similar ambiguities, in particular the double negation problem, and
also the risk of negating a null flavour value. Applying negation to a container relationship is even
more ambiguous, leaving open to interpretation whether it applies to that node only or also to all of
its children.
The following are some examples of ambiguity caused by negating a relationship:
 A diagnosis of myocardial infarction is related to a finding of cardiac enzymes, with a
negation on the relationship; does this mean that the diagnosis stands, but that the cardiac
enzyme test does not provide evidence, or does it mean that the cardiac enzyme finding
negates the diagnosis of myocardial infarction?
 A condition of anaphylaxis is noted, and has a causal relationship to an administration of an
X-ray contrast medium, but that relationship is negated; this could be interpreted as the
anaphylaxis was not caused by the X-ray contrast medium, but it could also be interpreted as
the patient has had an administration of an X-ray contrast medium and it did not cause an
anaphylaxis event
 A substance administration of methotrexate is documented, and is related to a diagnosis of
rheumatoid arthritis by an indication/reason for relationship which is negated. Should this
mean that methotrexate is not being administered for rheumatoid arthritis (but for some
other condition) or is it meaning that methotrexate is contraindicated for treatment of
rheumatoid arthritis in this patient?
Querying
Querying for negation expressed through an information model would require explicit processes,
identifying negation as an attribute on a class and on a relationship, and agreeing and documenting
clearly what this would mean in each combination of circumstances. Every import of EHR data into a
clinical data warehouse would need to reliably interpret and map the imported data into these
agreed use patterns. This would be a significant amount of work and experience shows it is likely still
to be fraught with the possibility for misunderstanding. There would also need to be explicit
business rules to manage situations such as double negation. This is a degree of complexity best
avoided.
Summary
Using negation in information modelling is challenging, either within a class and its attributes or in
relationships between classes; it has the potential to allow different interpretations that themselves
are difficult to differentiate. This is less than ideal, and indeed the opposite objective of the basis of
information modelling itself, which is to provide clarity for the domain of study.
We suggest that EHR4CR does not attempt to use the information model to express negative
semantics.
Using Terminology (Coded Data)?
Terminology expresses complete “units of thought”. For negative semantics, therefore, the unit of
thought that is expressed by the terminology concept is the complete negated unit – “HIV negative”
for example. This is clear and unambiguous in its meaning, as a “unit of thought” should be. And
due to the nature of such expressions, a single vocabulary concept can provide quite rich expression,
beyond the simple “not” or “negative” through to “absent” and “missing”.
Rich terminologies in the domain, such as Snomed CT, provide support for such negative concepts.
However, it is still possibly to use terminological means to express negation with those terminologies
that do not support pre-co-ordinated negative concepts (e.g. ICD or MedDRA), but using an
appropriate post-co-ordination syntax. This allows for the concept to be correctly described using
the CD datatype. It is desirable that this be developed in conjunction with the terminology provider
on a case by case basis, such that the negation concepts and post-co-ordinated expression can
accurately be identified by the correct OID mechanisms, but if this is not possible, it is still to
implement this process.
Relationships should always have a description of their purpose, which, if they are to be machinereadable, will involve the use of terminology. Therefore, when the requirement is to express a
relationship that has a negative sense (for example a “contra-indication”), it is deemed to be more
acceptable to have a rich set of relationship expressions such as “is evidence for” and “is not
evidence for” rather than to use a negation property (“is evidence for + negation indicator) – which
is therefore a terminological approach.
Querying
Querying for particular pre-co-ordinated concepts from a terminology would have no effect on an
existing query model which can query for one or an expanded set of concepts. Querying for post-coordinated expressions is slightly more complex, but these situations could be identified by
recognising the OID for the post-co-ordinated expression and then applying the appropriate logic.
Negation of Non-Coded Data?
Are there any types of negation that cannot be handled by terminology (i.e. that would use nonconcept derived datatypes)? Should negation be applied to a value, a date, for example, or a MIME
file or an address? Statements such as:
the systolic blood pressure was not 135mmHg
the date of the prescription was not 10th April 2012
the patient's address is not 10 Acacia Walk, Eastbourne
are highly unlikely to be encountered in an EHR, and particularly in the sort of data that would be
handled by a Clinical Data Warehouse. Therefore it would seem that all the requirement to manage
expression of negation can met by the use of terminology.
Conclusion
It is generally accepted that where a negative sense can be appropriately communicated using a
terminological expression, this is the preferred way to do it, and to date, examples of negation that
cannot be managed by terminology have been not been found (note the double negative here!).
Additionally, it is felt that querying for negation as expressed using coded concepts could use
existing mechanisms.
We therefore suggest that EHR4CR embraces a terminological approach to express negative
semantics.
Use of Null Flavours
The “Null Flavour” is a property of the attribute that would contain a data value representation,
used when a data value cannot be provided, which asserts a reason as to why a value is not
provided.
It is suggested that EHR4CR supports a limited set of null flavours taken from ISO 21090, as required
by the business use cases, and that business rules as to how to handle these null flavours when
encountered by the query process be developed. These rules are likely to vary depending on which
of the key areas of the EHR4CR project is being (protocol feasibility, patient recruitment, clinical trial
execution, adverse event reporting).
Appendix 1 - Negation in HL7 V3
HL7 Core Principles has a special section on negation, since it can have such profound impact on the
meaning of information conveyed.
Core Principles states that the Act.negationIndicator has been deprecated and retired since it
conflated the meaning of Act.actionNegationInd and Observation.valueNegationInd. Unfortunately
CDA R2 retains this deprecated attribute, but it is clear that its use is problematic.
There is Act.actionNegationInd; this may be used on any act and signifies that the negation applies
to the level of detail conveyed by the attributes (and possibly associations) of the act. The
interpretation of Act.actionNegationInd varies by mood; in EVN (event) mood, it indicates the event
did not occur; in RQO (request) mood, it orders the action not to take place; in permission mood, it
indicates that the permission is not granted. It can be used in DEF (definition) mood, to indicate that
the act cannot be performed.
So an actionNegationInd of "true" on a SubstanceAdministration Event with a subject and medicine
X specified in the consumable participation would indicate "this subject has never been
administered medicine X". If there is more detail specified, such as a SubstanceAdministration Event
that had an effectiveTime of 12:05 on January 6th, 2010 and a performer of John Smith, then it
would say "this subject was not administered a substance on January 6th, 2010 at 12:05 by John
Smith". It does not preclude the possibility of a substance having been administered by John Smith
at 12:04 or 12:06, nor at 12:05 by Jane Smith.
There is also Observation.valueNegationInd, which simply indicates that the specified value was in
fact not observed. This allows the explicit statement of a negative finding, such as absence of a
tumour, rash, illness or other condition. The semantics are not influenced by any other attributes on
the Observation. However, it is influenced by the level of detail specified in value. If the
Observation.value is "severe, sudden onset rash", a negated observation only indicates that specific
type of rash was not found. It says nothing about a moderate or slow onset rash. However, the RIM
usage notes are clear that Observation.valueNegationind should only be used when the negated
observation cannot already be conveyed by the code system used to communicate the observation
value itself (i.e. by using a pre-co-ordinated or post-co-ordinated negative assertion concept).
There are also negation indicators for use on relationships – specifically ActRelationship,
Participation and Role. These indicate that the relationship between the two classes described by
the attributes on the relationship class does not exist. It makes no assertion about the existence of
the source and target classes, nor of the characteristics of those classes, merely establishing the
presence or absence of the relationship with its specified properties.
As a rule, Role.negationInd being true only makes sense when traversing from playing entity to
scoping entity or vice versa. It is not appropriate for roles traversed to or from via participations.
So, for example, a negation indicator set to “true” on a RSON (reason) relationship between a
Substance Administration and a diagnosis observation would indicate that the Substance
Administration was not indicated for the diagnosis, but it would make no other assertion about that
Substance Administration.
Note that in HL7 messages, in all cases, the negation indicator attributes default to false. This default
holds even if negation indicators are omitted from a model. Negation indicators cannot be added
into a new version of a model where they were not previously present, nor can they be added as
local extensions because of their impact on the meaning of all other information in the model.
It is therefore possible to use the HL7 negation indicators in an information model to convey
negative semantics, but it is not a simple process and it is not to be undertaken lightly. It also makes
querying for negative statements somewhat complex, requiring explicit query processes for negated
statements.
Appendix 2 - Negation in ISO EN 13606
Discussions of a similar nature to those outlined in this position paper took place during the
development of 13606, noting the early work being undertaken in HL7 Terminfo at that time.
After considerable discussion and consultation, and as approved through ballot:


the 13660 Part 1 Reference Model for representing an EHR Extract has no information model
property for negation: terminology values are the only mechanism for negation supported by
the standard;
those semantic relationships (between parts of an EHR) that carry a negative sense (e.g.
disagrees with, declines, contraindication for) have explicit terms for those relationships defined
in Part 3, and no negation property is included in the Link class.