Positive Negation Statements with Adverse Reactions

I have been doing some work with an Adverse Reactions¹ service for some time. It’s one of those slow burn projects where decisions get made, time passes, thoughts change, and decisions get reappraised with the wisdom that inertia can sometimes bring².

What the world most needs today are negative virtues— not minding people, not being huffy, touchy, irritable or revengeful. Positive ideals are becoming a curse, for they can seldom be achieved without someone being killed, or maimed, or interned. E. M. Forster, 1939

It made sense very early on to adopt the OpenEHR Adverse Reaction Risk archetype which closely mirrors the FHIR AllergyIntolerance resource. If you look at the provenance of the archetype and resrouce, you will see common names appear with both communities contributing jointly to the creation of each model. Over the past couple of years there has been a slight divergence, but they are generally very close.

There is however, one aspect of model separation that I have found difficult to reconcile, which involved positive statements of negative presence (or the somewhat uroboric “positive negation”³ term from here on in). Clinical examples of these include “patient has no history of heart disease” or “examination not performed”.

As described by Penka (2015)⁴, “negation is a one-place operator that reverses the truth-value of a proposition”. A simple example cited is;

1. It is raining.
2. It is not raining.

The presence of the word ‘not’ makes a previously true statement false. Similarly;

1. The patient has an allergy.
2. The patient does not have an allergy.

This describes a clear notion of true and false according to perceived clinical state of the patient. A truer statement could be “the patient does not have an allergy as far as we know”. But putting that to one side, within the context of a clinical use case supported by an EHR, the fact that allergies exist lead us to ask a further question about what substances could cause an allergic reaction.

There are a few different use cases we could support at this point. We could simply review the list of causative agents or alternatively use that information to trigger some form of decision support. Whatever function we build, we need a more granular level of detail to take the next step (i.e. a list of one or more coded substances).

The same cannot be said of the statement “No known adverse reactions” or “No known allergies”. Both are positive statements of a negative presence of a substance or risk. They are a means to an end and represent the logic of the question at a higher level than the list of substances itself.

A third potential statement is that “Adverse reaction data is not here” i.e. it may be in the paper record or in another system. This in turn triggers the system or user to look elsewhere but this positive negation statement forces another action to take place.

There is a clear distinction however; the basic logic of whether a patient may or may not have an adverse reaction risk can be answered through three states; Yes, No or Unknown. At this point the detail of the record is not required.

Approach with caution

Within the ‘Misuse’ section of the Adverse Reaction Risk archetype, it is stated: Not to be used for the explicit recording of an absence (or negative presence) of a reaction to 'any substances' or to identified substances, for example ‘No known allergies or adverse reactions’ or ‘No known allergies to Penicillin’.

The model in this case clearly delineates between the logic of adverse reaction risks existing or not. It does not however have a place within the model that states “Patient has one or more allergies”. That would be duplication if a list of substances could be found.

FHIR offers a couple of different routes to recording this logic. The first is to make use of a coded entry such as the Snomed CT term for No known allergy. The FHIR definition of the AllergyIntolerance.code is Type of the substance/product, allergy or intolerance condition, or negation/exclusion codes for reporting no known allergies. The second is to use the FHIR List Resource although it is stated this is discouraged.

I can see that from an implementation perspective a single API call is desirable although I find this problematic. On the one level, ensuring that there is only one place to review this data simplifies the process. However, what if the code is not accurate? Additionally, what if the record is not kept effectively and this code is present with one or more active substances? What can a machine or indeed a clinical user do about that other than become confused where the negation statement is present with conflicting positive statements?

Put simply, a causative agent in ontological terms is a data point that reflects clinical state. The patient has allergies to latex and strawberries for example. Storing the negative statement carries a risk, however slight, of causing patient harm either through human ineptitude or be introducing inefficiency into the digital care pathway.

Additionally, we cannot make allowances for negative statements for all potential substances. It would be inappropriate to capture that the ‘Patient has no known allergy to latex” or “no known allergy to strawberries”. This is the classic blacklist versus whitelist debate where the voluminous masses that should not be allowed to be recorded dwarf the reality of a much smaller number that may. The patient may be allergic to any one of tens of thousands of substances. Millions even. This is simply recorded as; Allergy to x where x = any code in Snomed CT substance hierarchy or drug.

It is for these reasons that I think there are alarm bells in the suggested implementation of the FHIR resource.

Negation Flags

The complete suite of Snomed codes are simply not available to cover sensitivities and intolerances. Very few people would be able to identify a true immunological response to a causative agent without some form of testing; this is the only definitive way to prove a patient has an allergy. The reality is that there is an assumption that the patient may have an allergy when it may be a non-immunological response (i.e. sensitivity or intolerance). In order for the preferred FHIR approach to work, there would have to be four negation flags;

1. No known allergies.
2. No know sensitivities.
3. No know intolerances.
4. Adverse reaction data is not stored here.

Any system processing the adverse reaction list would be required to check for these codes before progressing. Would this then imply that all patients have 1, 2 and 3 these recorded by default if it was thought that there were no substances that could pose a risk? And then what would happen if the datastore was queried and this implementation guidance was not followed? I appreciate that the latter point would represent system development or use failure, but it is a risk all the same. The potential for every patient to have an average of 3 adverse reaction records when all are negation statements is a risk.

The alternative for FHIR is to use the List resource which contains an emptyReason element. If the negation statement were placed here, it represents a far more logical structure and aligns better to the OpenEHR archetype. This resource is not mature however and therefore carries a potential risk that it will change significant as it evolves. Implementing this now may cause problems in the future.

So What?

Why does this matter? Fundamentally, if implementation guidance is followed, could the suggested FHIR approach introduce a clinical risk? Or is it that a clear logical structure espoused by OpenEHR and the FHIR List resource present clarity and instruction on how to interact with an electronic health record?

Fig 1: Diagram describing the flow of data with positive statements of negative presence.

Whether including a negation statement within a list of substances represents a true clinical risk may be debated, but it just seems messy. Establishing a clear logic for this sort of clinical data just seems to make sense as asserting negation or exclusion, within a structure that's also used for asserting positive presence is counter intuitive. Specific provision would then be required to ensure that any recipient clients of this service are aware that negation statements may be present, and process this data accordingly: the logic must be separate.

To my mind, the rule/pattern should necessitate positive statements of "fact" based on some sort of evidence as described in the patient record. These statements should reside in an area of the clinical data repository that But the emphasis has also changed the traditional "allergy list" becoming the "substances that could cause adverse risk" list which is inherently more complicated. But I think that represents the principle schism between the FHIR resource (self-contained model) and OpenEHR (a fragment of the entire record).

It is fair the emphasis has changed the traditional "allergy list" to become the "substances that could cause adverse risk" list which is inherently more complicated. And I think that represents the principle schism between the FHIR resource which is a self-contained model, and the OpenEHR archetype which represents a fragment of the entire record (and more complex as result).