Adverse reaction risk: how to report general patient symptom?

Clinical Ask an editor
1

If we want to record some of the usual data points about an allergy or intolerance (for the typical hospital list of precautions), I do not see how to record the general patient symptom, e.g. anaphalaxis, swelling etc. There is a 0…many inclusion of ‘CLUSTER.adverse_reaction_event’ which allows recording of particular reaction episodes.

We just want to record something like:

  • shellfish / anaphalaxis /

This is usually just based on the patient’s info, in the usual way, when he/she is asked on admission.

I don’t see a data point for the general symptom / reaction type in the EVALUATION archetype, although there are other things like ‘reaction mechanism’, which is really a clinical assessment, not a simple symptom category.

thoughts?

2

So is this simple symptom expression intended to trigger decision support or is it more about gathering information about possible allergies but prior to it being curated and chcked.

If it intended to be an actual allergy cds triggering record i would use gbe adverese reactionarchetyoe with the manifestation element to record the symptom.

If eg an admission document id either use a symptom archetype or perhaps the oroblem dagnosis questionnaire to recod do you havd any allergies etc. Which is then checked and posdibky some or all are added to the formal allergy list later.

3

Well it’s ‘simple’ entries on an allergies list as from a Cerner system. Mainly just substance, but according to Stan and others who know the data environment, it would be likely that the kind of reaction could be recorded.

An allergies list created or updated on (say) ED admission isn’t a detailed list of prior allergic reaction events as such, just the allergies (usually patient-reported), so staff know what not to give the patient (including food).

It seems to me that the EVALUATION.adverse_reaction_risk archetype is more oriented toward a clinical work up of the actual allergies. The manifestation item for example is only inside the CLUSTER.adverse_reaction_event, but we are not recording any events, just the general situation.

If I hadn’t already known of the existence of these particular archetypes I probably would have gone looking for some sort of allergy summary archetype, but that doesn’t exist either.

4

If it is an ‘allergies list’ feed then at some level someone is curating it, and as you say, it is being used to support decision-making.

It may not be THE allergies list but it is AN allergies list, perhaps contextual to the nursing team. In secondary care these kind of lists are often contextual , or rebuilt from scratch hat admission. That twould certainly be common in the UK.

I’m still drawn towards adverse reaction risk and the associated cluster to record the manifestation (symptom) but if I thought it was contextual and not global, place it in a template that made that clear.

If this was a front-line system I would actually push back on that approach and try to get people to maintain a single allergy list but that requires a reconciliation process against each external source of allergies info.

5

It’s a good question. My impression is that Intermountain has essentially global lists for things like problems, allergies and medications lists (having been in for various consultations for family members and myself at different locations), so it’s better than one might have expected (or surely was in the past).

Indeed that is what I’m going to stick with (I’m mainly building templates to map the incoming data, not doing real clinical modelling :wink: but I’m adding a data point for now that is called ‘reaction type’ with a Snomed -coded value set.

It’s Cerner, and Cerner is global across the enterprise since 2015 (except for the bit they just acquired, which has Epic :wink: So HCPs see the same patient record in all the Intermountain hospitals (but of course not ‘out of network’ providers), so if they modify the allergies list they are modifying a global list. I don’t know how access control works yet, so it may be that some HCPs can’t modify and others can.

In general, as much as we love to criticise these products for their poor quality data and difficult APIs, they do tend to achieve one thing in the US: centralisation of data across the health system (Intermountain, Kaiser etc). This isn’t the case in the UK because hospital trusts procure systems independently of each other.

6

It is correct to consider the EVALUATION.adverse_reaction_risk archetype as a summary, although summary is not currently included in the concept name. This pattern of creating EVALs as summaries has been becoming increasingly obvious in recent years, hence my CR suggesting the change of name to indicate more clearly its purpose.

This EVAL archetype provides an overview of the propensity of a individual to experience a reaction based on clinical evidence with may or may not be supplied in the adverse reaction event summary CLUSTER or other CLUSTER archetypes yet to be developed, such as immunogenetic test results (ie identifying a propensity without being exposed at all).

If someone presents to a clinical consultation with an allergy it will usually be captured using the usual history and exam related archetypes within the context of a consultation COMPOSITION.

If desired, a summary of the key aspects of the symptoms, exposure details can be captured in the adverse reaction event summary CLUSTER and the archetype group added as an item in the Adverse reaction list. Creating contemporaneous event summaries assigning a specific substance (rather than assigning a class of substance in the EVALUATION) will support enabling recording and exchanging of a detailed reaction record, including where there may be an absence of a reaction on exposure - in which case, it begs the question whether the correct substance is considered causal or not.

The ‘Manifestation’ data element within a single adverse reaction event summary CLUSTER is used:

  1. to record details about a specific reaction event eg careful documentation of a contemporaneous event or an event requiring very detailed documentation during a pharmaceutical trials; or
  2. as a general container to record one or more manifestations of the reaction that have occurred in any unspecified events, especially historical events at unknown times - the details about the timings are optional and left empty.

This CLUSTER supports recording of all manifestations, no matter what the level of detail being recorded, both symptoms such as swelling/rash or the higher level assessments/diagnoses/conditions such as anaphylaxis.

Be careful using terms like types, categories or other groupings - they can have other meanings in this clinical context to different groups. Some use them for the physiological mechanisms underlying the propensity or whether they are food/environmental/medication etc.

You don’t make it clear what the purpose of the ‘Reaction type’ is but if it is to replicate the ‘Manifestation’ then I wouldn’t recommend breaking the usual pattern.

If you add a data point equivalent to ‘Manifestation’ within the EVALUATION you will be duplicating data points and diverging from long-established recording patterns.

For further background - until recently the Reaction event summary CLUSTER was a repeating internal cluster within the EVALUATION. The equivalent FHIR resource still models it this way. It was separated in the openEHR CKM ecosystem so the reaction event summary CLUSTER could be reused in other allergy testing contexts.

These models went through extensive review by the FHIR and openEHR communities and the clinical content jointly published in 2016. The FHIR resource was changed significantly to align with the openEHR model at the time. Both have been in broad use since then for similar purposes to which you need, including the Sparked AUCDI.

1 Like
7

Just wanted to reinforce Heather’s advice here.

The ‘Manifestation’ element in Adverse reaction event, carried within the Adverse Reaction Risk archetype is exactly how I would achieve your goal @thomas.beale , and this would be exactly in line with the FHIR allergyIntolerance resource from Cerner

   'reaction': [
      {
        'id': '12760027',
        'manifestation': [
          {
            'coding': [
              {
                'system': 'http://snomed.info/sct',
                'code': '386813002',
                'display': 'Abnormal breathing (finding)'
              }
            ],
            'text': 'Breathing abnormal'
          }
        ]
      }
    ]
1 Like
8

Personally, I would just use and code Manifestation. Stan didn’t find it the most obvious term to use. But that’s not the modelling problem. The problem is that we don’t want to record any specific reactions, we just want to record a general statement of:

  • substance
  • what kind of reaction - might be allergic, might be some other kind of intolerance
  • severity - probably = criticality

So it’s that second data point we don’t have in the top-level (summary) archetype - it’s only available in the CLUSTER.adverse_reaction_event archetype - unless it is meant to be ‘Reaction description’? Maybe that’s it.

That is /was clearly a sensible thing to do.

See comments above…!

9

Reaction mechanism

  • Immune mediated [Immune mediated reaction, including allergic reactions and hypersensitivities.]
  • Non-immune mediated [A non-immune mediated reaction, which can include pseudo-allergic reactions, side effects, intolerances, drug toxicities (for example, to Gentamicin).]

Also the description, my emphasis:

Immune-mediated responses have been traditionally regarded as an indicator for escalation of significant future risk. Contemporary knowledge suggests that some reactions previously thought to be immune are actually non-immune and still carry life threatening risk. Immunological testing may provide supporting evidence for the mechanism and causative substance , but no tests are 100% sensitive or specific for a sensitivity. It is acknowledged that most clinicians will NOT be able to distinguish the mechanism of any specific reaction. However this data element is included because many legacy systems have captured this attribute.

The type has been simplified to immune mediated and non-immune mediated reactions because to reliably determine a finer level of granularity from a clinical presentation is notoriously unreliable, I’ve been talking to immunologists from the National Allergy Council here in AU, peak body. They agree that getting the mere mortal clinicians to determine the reaction mechanism is a flawed premise.

Criticality is an indication of the severity of the propensity, but is really just crystal ball gazing in many ways. Depends on so many factors and is also potentially very unreliable. Manifestation is usually a better indicator of both the mechanism and the potential severity of a future reaction:

  • if it is a rash - low criticality, the default for any known reaction, so how does criticality help;
  • if it is a severe rash - who knows what might happen in the future;
  • if it is anaphylaxis then avoid at all costs - to re-expose someone intentionally requires a strategy to manage the likely repeat of anaphylaxis, in ICU and under steroid cover - in which case a secondary data point of ‘high criticality’ is probably redundant.

Mike Bainbridge and his MS CUI team at the time did some seminal work in this area in 2010’s. Still the best I’ve seen.

1 Like
10

This sounds right to me also. But it’s still a data point inside the CLUSTER.adverse_reaction_event archetype - we are not recording any events, just what kind of reaction (in general) the patient knows they have to the substance - this is not for a consult on the reaction, just capturing kinds of reaction on a new admission, ED admission or other encounter.

11

Just connecting these two points from previous posts:

In theory, the Reaction event summary CLUSTER can carry a list of all manifestations, effectively as a summary of ‘all events’ when there are no dates identifying a specific event - a slightly messy solution for messy data. This may be necessary if recording data from legacy systems.
However, high quality contemporaneous recording should ideally record each event separately.
A combo of these approaches should still allow a list of all manifestations to be displayed together (as per the MS CUI work) by querying on the ‘Manifestation’ data element.

1 Like