Clinical Scenarios in FHIR: Adverse reaction

The final scenario that is a candidate for the clinical connectathon is one that deals with allergies and Intolerance. Here are the details, but at a high level:

• A patient is prescribed penicillin and 8 days into the course develops symptoms that are diagnosed as an allergy to penicillin, which is recorded in their allergy list, along with details of the nature of the allergy.
• In addition, the patient (through a patient portal) updates their allergy list – adding an entry that is subsequently updated (or reconciled) by the clinician.

Rather than stepping through the details of the scenario as we’ve done before, in this post let’s focus more on how the Allergies and Intolerances could be recorded in FHIR. I don’t want to dwell on the differences between the two (there has been active discussion on the Listservs in recent weeks) – rather the mechanics of recording them and some of the interesting issues that arise when doing so. So when we use the word ‘allergy’ in this post it could mean either an allergy or an intolerance…

The first topic is the question of the Allergy List. We’ve talked about the List resource before – it’s a generic way of recording lists of things and has references to the resources that actually comprise the contents of the list – in this case it would be to one or more  AllergyIntolerance resources. The List has a code element that indicates the type of list (in this case a list of allergies) as well as a subject that would be the patient, and a source that would be the person (which could either be a patient or a clinician) that last updated the list.

As with any FHIR resource, the List resource can be versioned, which gives us a nice way of tracking updates to the list – and who made the change.

The list has its items referenced from the entry element. In addition to the actual reference, the entry has a property that formally indicates that something has been deleted from the list – the deleted element. This might be handy if an entry is added, but subsequently found to be incorrect and removed. If we do this, we might want to add an extension to give the reason why it was removed (the person who did the removal will be the list source for that version).

And finally, the list has an emptyReason element that allows us to specifically state that the person has no known allergies.

Thinking about the person updating the list brings us to the question of provenance – where did the information come from? FHIR has a specific Provenance resource for this, which gives us the ability to add more details about the person (or more correctly the activity) that led to the creation or update of a resource. Given that we’re formally recording the list source for each version then we might not need it for the List – but we may wish to use it for the AllergyIntolerance resource, especially when it is updated because Provenance has an element (reason) that lets us record the reason for the change.

Now let’s look more closely at the AllergyIntolerance resource. Here’s a diagram showing the relationship between the resources involved (It’s one we’ve looked at before – I love re-use!):

Looking at the scenario, there are some specific properties of the allergy that we wish to record. These include:

• When the allergy was recorded (recordedDate)
• The person recording the allergy (recorder)
• The patient (subject)
• The criticality (criticality)
• The substance that caused the reaction (substance)
• And the nature of the reaction (reaction).

The substance.type element would indicate what the allergy was to (It’s a CodeableConcept so can reference a terminology – or just have text if that’s all we have).

The Substance and the Reaction (AdverseReaction) are modelled as resources in FHIR. Generally this means that we would create them as separate resources and reference them from the AllergyIntolerance, however as these resource are ‘tightly coupled’ to the AllergyIntolerance, they may be good candidates for using contained resources. Another way of looking at this is that the reaction (at least) is not going to be shared between instances of AllergyIntolerance – it is an integral part of it and cannot easily be separated. It’s an implementer decision though…

Whether a separate resource or contained, the reaction indicates what the nature of the reaction (or reactions) was. You can describe the symptoms in coded or text form (in the scenario, the symptoms included a rash, nausea, abdominal pain and diarrhoea). There’s a fair bit of detail in there, and some of the fields are duplicates of what is in the AllergyIntolerance. This is intentional, as there may be circumstances where the reaction is described in one encounter – and ascribed to an AllergyIntolerance in another.

So adding a new allergy to the list will involve:

1. Creating a new AllergyIntolerance resource (which may involve new Substance and AdverseReaction resources)
2. Retrieving the most recent allergy List resource – or creating a new one if none exists).
3. Adding the AllergyIntolerance to the List
4. And saving them (possibly using a transaction)…

Similar steps would be used for list updating. In the scenario for example, the patient entered ‘allergy to flu vaccine’ is updated by the clinician to ‘Adverse Reaction to Flu Shot, mild severity’. This could happen by:

1. Retrieve the allergy List resource
2. Mark the patients entry as deleted (possibly with a ‘reason’ extension to indicate updated)
3. Create a new AllergyIntolerance resource and add to the list
4. Save the list and the new allergy.

An interesting question is what to do with the patients actual AllergyIntolerance resource that has been altered. You could:

• Delete it (perhaps using a Provenance resource to indicate why and by who)
• Update it instead of deleting it and creating a new one.

Again, an implementer decision – though guidance from the FHIR community might be a good thing here.

So: Now we’ve talked about all 3 scenarios we’re proposing for the Clinical Connectathon. We need to decide which of them we want to go forward with (I doubt that we can do all of them in the time required – but that’s a topic  to discuss!)