Revisiting adverse reactions

The current Adverse reaction risk archetype was first published in March 2016 after a lengthy modelling and review process detailed in this blog post by @heather.leslie.

The Adverse reaction risk archetype was always intended to be used for recording the positive presence of a general propensity to react badly to specific substances or groups of substances, for the purpose of alerting clinicians to avoid or be careful when exposing the patient to said substances. An outstanding issue has been how to record information about specific reactions when they occur out of the blue, or in a situation when you expect that a reaction is more likely to occur, such as in the first 30 minutes after vaccination.

Recently these requirements have showed up in actual implementation projects, which has reinvigorated modelling efforts in this area as well as provided use cases to guide modelling patterns.

Based on the use cases of monitoring a patient for adverse reactions after such interventions as vaccination, hyposensitisation, transfusion or chemotherapy, we’re proposing a new OBSERVATION archetype with the tentative name of ‘Adverse reaction monitoring’ (see preliminary mindmap below). As part of the scoping out of this area, it was identified that the internal cluster ‘Reaction event’ currently in the Adverse reaction risk archetype would be useful in both of these two ENTRY archetypes. We’re therefore proposing to separate this out as a CLUSTER archetype, which would mean a breaking change to the Adverse reaction risk archetype.

Additionally, we’re looking at how to best represent provocation tests such as skin prick tests, mantoux, food item provocation, etc. We’ve also briefly discussed food elimination tests as a separate concept in this space.


This was a topic that was widely discussed both in openEHR and as part of the joint discussions with FHIR.

The conclusion then, and I don’t think I see any reason to change it, was that Adverse event reporting / monitoring was out of scope of ‘Adverse reaction risk’ - you can have a Adverse event that does not represent a future risk (or at least does not require alerting/decision support) and you can have an assertion of risk that has minimal if any reaction details.

Ok but surely there is crossover in terms of ‘Reaction details’? between these 2 contexts. In fact when we looked at it, not so. The requirements for adverse reporting are often quite different from that of ‘reaction details’ as evidentiary support for an adverse reaction risk, and are sometimes mixed up with adverse events that have nothing to do with patient - wrong dose admin, wrong site etc. Furthermore these data points are often quite local to reporting agencies, authorities, pharma requirements.

“We’re therefore proposing to separate this out as a CLUSTER archetype, which would mean a breaking change to the Adverse reaction risk archetype.”

So, sorry unless things have materially changed, I don’t see a good case for changing this archetype, which is well -established, well-aligned with FHIR and (AFAIK) current recording, especially making a breaking change. The proposed archetype is fine as it stands but reporting will be driven by existing national and international event reporting standards, of which there are very many that need to be taken into account.

“An outstanding issue has been how to record information about specific reactions when they occur out of the blue, or in a situation when you expect that a reaction is more likely to occur, such as in the first 30 minutes after vaccination.”

In GP land, I would probably just record this as a symptom/sign observation, unless I felt this was potentially reportable, (vaccination being a good use case) in which case I can see the value of some sort of adverse med event cluster. I still think it will be very difficult to line this up with all of the actual reporting requirements and I can see that this might be useful to optionally pull in to a slot in the Adverse reaction risk archetype but I think forcing a breaking change at this point is a very bad idea!!

For provocation testing, it might be useful to separate out those tests which are still generally lab-reported, and would stick with the lab test series (adapt if needed) from e.g Mantoux which are ‘patient-level’ observations.

1 Like

Thanks for your response, Ian!

First of all, at this point we’re not proposing anything related to general recording of ‘adverse events’, only ‘adverse reaction events’, ie physiological reactions mainly to the administration of medications or other therapeutic substances. So no falls, omitted doses, wrong patient, etc.

Secondly, we’re not primarily modelling the ‘Adverse reaction monitoring’ concept for reporting purposes, but for clinical use. More or less all the elements of the current ‘Reaction event’ internal cluster of the ‘Adverse reaction risk’ archetype are also relevant when recording information about a reaction in the mentioned use cases (vaccination, transfusion, chemo, etc).

Agree about this when we’re talking about reactions “out of the blue”, and I see I forgot to follow up on this mention in my initial post. We definitely think these should be recorded as symptom/sign, also in hospitals.

Agree, we’re mainly thinking of the ones where the patient is observed directly. Any blood tests etc will definitely be lab tests.


We’ve continued this work, and uploaded two new and one modified archetype to the CKM.

We’d love to get some input from the community before we move on with these.


some thought (finally found time), side note: in our implementation adverse events are still in a legacy data model.

I like the concept of seperating out OBSERVATION of adverse events from the EVALUATION, adverse reaction risk. They should be aligned off course.

I also like the concept off reusable cluster for event details. If a breaking change is problematic for the current implementation of the EVALUATION there are multiple ways of mitigating that proble (wait with changing the eval, keep maintaining previous major version, supply templates, ensure only technical changes and no sementic changes to keep allignment with FHIR).

I would like to reuse the cluster sign symptom in these archetypes to record the symptoms that are evidence/observations related to a reaction.

I would like to discuss the naming further. Can be at review time.

I think the Mantoux test and the like are conceptually at a different level, (reusing these archetypes) but I don’t think they are lab tests.

I would also like to think about modelling instructions from a doctor to a nurse to watch for adverse reaction signs.

1 Like

If you consider this an ‘order’ (i.e. a formal request), and you want its Actions recorded (e.g. 2h nurse obs or whatever on that patient) then Instruction makes sense, and the archetyping will work just as well as for medication orders and the like.


Yes, it would be a formal order, an instruction is what I have in mind. What I haven’t solved is how this instruction can specify technically that certain elements of the OBSERVATION.adverse_reaction_monitoring must be recorded (at stated time, place and by a discipline).
But it’s similar for blood pressure orders and the like. How do we solve it there?

1 Like

Doing this properly is Task Planning territory, but you can get a fair way with using CLUSTER archetypes plugged into a slot in both an ACTION archetype and the OBSERVATION archetype. I would need to see details more precisely, but the clinical modellers should probably comment first, I’m sure they’ve seen this use case.