Stream: implementers
Topic: AllergyIntolerance
David Hay (Jun 28 2016 at 00:47):
Question from some colleagues:
The FHIR AllergyIntolerance resource has a criticality element at the base resource level (AllergyIntolerance.criticality), and severity elements for each contained reaction (AllergyIntolerance.reaction.severity). These two elements are bound to different (required) value sets.
The HL7v2 messaging spec defines the AL1-4 segment for an Allergy level severity.
How can we work around the problem of mapping a FHIR resource with multiple reaction level severities into an HL7v2 message and vice versa?
And what is the correct mapping between a severity and a criticality, as the two seem to be quite distinct?
Lloyd McKenzie (Jun 28 2016 at 01:50):
I'm not sure you can convert severity to criticality in an automated way because it depends on the semantic of the reaction. High severity of a non-significant reaction might be low criticality, while moderate severity of a potentially life-threatening reaction would be high criticality
Erich Schulz (Jun 28 2016 at 02:04):
this made me pause
Erich Schulz (Jun 28 2016 at 02:05):
by "criticality" I guess FHIR means "risk to health on re-exposure"
Erich Schulz (Jun 28 2016 at 02:06):
so if you get a rash reaction to a drug with mild urticaria then this would be critical because re-exposure could cause anaphylaxis...
Grahame Grieve (Jun 28 2016 at 02:07):
it's not up to us to make that decision.
Erich Schulz (Jun 28 2016 at 02:08):
whereas a reaction of "severe constipation after oxycode" (one of my mornings patients) would not be "critical" at all... as this is a common and expected reaction...
Erich Schulz (Jun 28 2016 at 02:09):
is there a definition for the HL7v2 "severity" field?
Erich Schulz (Jun 28 2016 at 02:11):
because regardless of the distinction (which is a good distinction) between reaction severity and allergy criticality, it would seem to me that the most useful thing would be to map the v7 severity to fhir criticality (or thats how it seems to me on superficial examination)
Grahame Grieve (Jun 28 2016 at 02:23):
Agree that's what you should do, but it has to be an local mapping because the v2 definitions are very loose
Avner Matan (Jun 28 2016 at 21:15):
FHIR's definition of criticality (AllergyIntolerance.criticality): Estimate of the potential clinical harm, or seriousness, of the reaction to the identified Substance.
FHIR's definition of severity (defined per reaction, not per allergy - AllergyIntolerance.reaction.severity): Clinical assessment of the severity of the reaction event as a whole, potentially considering multiple different manifestations.
HL7v2 definition of severity (AL1^4): This field indicates the general severity of the allergy.
This definition is problematic to say the least, as you can't define a term using the same term....
However, the main problem is that these two concepts don't seem to match, as FHIR does not currently define a severity for the allergy as whole (e.g, how severe the actual allergy is, regardless of its criticality).
Lloyd McKenzie (Jun 28 2016 at 21:38):
Right. FHIR isn't designed to maximize compatibility with v2 (or v3 or CDA or OpenEHR or any of the other multitude of systems implementers might be converting from. Some conversions will be straight-forward. Others will be tricky or non-automatable. If you can't come up with a way to safely populate "criticality", then omit it. (And if you wish, add an extension to convey the v2 concept you do have.)
Erich Schulz (Jun 28 2016 at 22:33):
personally I cant see a meaningful distinction between FHIR criticality and HL7V2 severity - allergy is always a like a land-mine
Erich Schulz (Jun 28 2016 at 22:34):
and these statements are markers for clinicians about what is predicted to happen if you expose the patient to this substance
Stephen Royce (Jul 26 2016 at 01:28):
I just noticed that AllergyIntolerance.substance has disappeared from the resource definition. This would appear to be an error, but if not, what's the reason/justification?
Grahame Grieve (Jul 26 2016 at 01:29):
it was renamed to .code
Stephen Royce (Jul 26 2016 at 01:38):
Oh! Why? Is that because we're thinking of allowing more than just substances, e.g. SNOMED code for "Allergy to ..."?
Stephen Royce (Jul 26 2016 at 01:46):
Is it so that negation can be bound up in the code? Have the clinical safety ramifications of that been documented somewhere?
Grahame Grieve (Jul 26 2016 at 02:04):
yes negation can be bound up in the code
Grahame Grieve (Jul 26 2016 at 02:04):
I'm not sure about the documentation, but it's pretty obvious
Stephen Royce (Jul 26 2016 at 03:02):
The clinical safety ramifications of hiding negation in a code are obvious?
Stephen Royce (Jul 26 2016 at 03:04):
Anyway, the change is useful I think. One thing we've been wrestling with is the tension between modelling AllergyIntolerance > Substance and using (or not using!) SNOMED codes meaning "Allergic to <Substance>". This allows recognition of both.
Rob Hausam (Jul 26 2016 at 03:09):
Yes, @Stephen Royce, that was exactly the intent. It allows (and documents) the use of all of the available pre-coordinated SNOMED CT (and other) codes for allergies. The resource documentation has been updated to reflect that - but possibly still needs some further updates.
Stephen Royce (Jul 26 2016 at 03:10):
Rob Hausam (Jul 26 2016 at 03:14):
Regarding negation, there are certainly potential issues with it being "bound up" in 'code'. But there are also issues with the alternatives that have been proposed and considered, as well. The SNOMED CT "no known allergy" subhierarchy codes are at least a pretty well defined and limited (only 7 at present) set.
Stephen Royce (Jul 26 2016 at 03:17):
Bound up in the code is certainly far better than carrying a sibling element stating "not". However, we found in our work that a completely separate class of clinical exclusions is better still. FHIR seems to have shied away from that as a whole, though, so you're not left with a lot of choice, I suppose.
Rob Hausam (Jul 26 2016 at 03:34):
Right. We considered a completely separate 'AllergyIntoleranceExclusion' resource, but so far decided not to go with that, as there is pretty strong sentiment toward having all of the allergy data accessible in one place.
Jayashree Surnar (Jul 12 2017 at 05:17):
hello everyone,
what's the diff among
AllergyIntolerance.onset[x],AllergyIntolerance.reaction.oncet,AllergyIntolerance.lastOccurence.
- when to use what? actually all of them are optional but if we want to capture one of them which is most imp?
- and here given
AllergyIntolerance.onset[x]-->
onsetDateTime,onsetAge,onsetPeriod,onsetRange,onsetString where as
AllergyIntolerance.reaction.oncet-->dateTime only
Lloyd McKenzie (Jul 12 2017 at 05:21):
AllergyIntolerance.onset[x] is when the allergy first appeared in the patient. That might be a specific date (or just a year), a period (sometime beween 1980 and 1985), an age (5 years), an age range (between 5 and 10 years).
AllergyIntolerance.reaction deals with specific occurrence of the reaction - there might be multiple reactions - each having its own onset. So far, there's been no broadly indicated need to capture reaction onset dates with the same imprecision we capture the start of the allergy as a whole. AllergyIntolerance.lastOccurence would be the date of the last reaction - and it might be present even if no reaction details are present.
Jayashree Surnar (Jul 13 2017 at 09:22):
Thank you @Lloyd McKenzie
Last updated: Apr 12 2022 at 19:14 UTC
