Mapping to the FHIR Allergy/Intolerance Resource

Nov 1, 2014

I’ve just posted an updated Allergy/Intolerance resource for the candidate FHIR DSTU2. This is closely very based on the shared FHIR/openEHR achetype, though the resource has been renamed. As part of preparing it, a few of us surveyed existing systems, and it seems useful to post the details of these here. Here’s a variety of allergy/intolerance data entry screens from around the interwebs (only one betrays it’s original directly). Each of them is marked with a set of numbers that identify the fields in the Allergy/Intolerance resource: 1. .type

  1. .substance
  2. .status
  3. criticality
  4. .event.manifestation
  5. .comments
  6. .event.onset
  7. .category
  8. .recorder

Issue

There’s several issues here.

The first is the way that the existing recording systems differentiate so poorly between the condition and the event - they are either completely silent about this, or they are quite confusing. The first 4 simply don’t address this - you could record either an actual adverse reaction event, or you could record a patient’s claim that they are likely to have one. The last 3 all quite confusing - they allow you to record a single onset date, but calls the concept a ”patient allergy / effect”, or the completely ambiguous “adverse reaction”, (which some people believe absolutely means “an event” while other people absolutely think it means “a condition, a likelihood”. My daughter is quite allergic to cashew nuts, and my experience is that different doctors, nurses and educators use the terms interchangeably).

So is this date the onset of the allergy, or the onset of the first reaction, or the onset of a reaction? or the date of the last reaction. Faced with this UI, I think that different users would pick different dates, and also that it would depend on what the patient said. The last 2 add to this confusion by tracking “status” - which suggests the condition (since sometimes it can resolve)

I presume that particular communities of users have their own rules about how to use the input screens that they share, but the process of working through this between HL7 and openEHR has demonstrated that there’s a complete lack of consistency around this.

There’s a related issue - finding this kind of information - what systems are doing - is very difficult. In fact, in many cases, that’s protected information. That’s one additional great way to ensure that standards don’t match normal clinical practice (as, additional to the one above which shows that there is no normal clinical practice)

Finally, the severity of the effect is very difficult - grading severity is difficult and controversial, so many commenters suggest to us that it shouldn’t be done (or exchanged). But many systems track severity (by a variety of different names), and there’s quite a difference between a minor allergy to latex that causes irritation, and a very sensitive response to a common antibiotic that can cause system wide shock. We’ve currently got only 2 levels of what we ended up calling “criticality” but this will be an ongoing discussion (e.g. CCDA uses 6 snomed levels for severity, though CCDA isn’t entirely clear about whether this the severity of a past reaction, or a potential future severity - but how could it be, given the screenshots above (they’re not all from US systems, but they seem representative of the variance found in this space)