Stream: implementers
Topic: substanceExposureRisk
Jose Costa Teixeira (Dec 30 2020 at 10:54):
Why is this extension a complex one, that replaces the AllergyInolerance.code?
http://build.fhir.org/extension-allergyintolerance-substanceexposurerisk.html
Lloyd McKenzie (Jan 04 2021 at 18:24):
@Michelle (Moseman) Miller
Michelle (Moseman) Miller (Jan 06 2021 at 17:37):
Based on http://build.fhir.org/allergyintolerance.html#9.1.4.2, we noted:
The substanceExposureRisk extension is also available for use as a more completely structured and flexible alternative to the 'code' element for representing positive and negative allergy and intolerance statements (either the 'code' element or the substanceExposureRisk extension may be used, but not both).
Not sure if I know what you mean by "complex" but the intent was to offer a way to negate a substance when a precoordinated code doesn't exist. For example, the extension isn't needed for "No known latex allergy (situation)" since a SNOMED code exists SCTID: 716184000. However, less common assertions may require a combination of the substance + exposureRisk of no-known-reaction-risk
Jose Costa Teixeira (Jan 06 2021 at 18:20):
Complex extension - contains several elements - https://www.hl7.org/fhir/extensibility-examples.html#complex.
The main question is - why does the extension replace an element that is in the core resource? Doesn't seem a good approach.
For example I cannot make the AllergyIntolerance.code mandatory.
Jose Costa Teixeira (Jan 06 2021 at 18:22):
Michelle (Moseman) Miller said:
the intent was to offer a way to negate a substance when a precoordinated code doesn't exist. For example, the extension isn't needed for "No known latex allergy (situation)" since a SNOMED code exists SCTID: 716184000. However, less common assertions may require a combination of the substance + exposureRisk of no-known-reaction-risk
For that purpose, isn't a Modifier extension better?
Jose Costa Teixeira (Jan 06 2021 at 18:22):
https://www.hl7.org/fhir/extensibility.html#isModifier
Jose Costa Teixeira (Jan 06 2021 at 18:23):
I don't see a reason why we'd duplicate (and in this case replace) the core elements.
Michelle (Moseman) Miller (Jan 08 2021 at 16:29):
I'm going to phone a friend here since @Rob Hausam created the original JIRA and created the extension as part of J#10358 back in 2016.
Rob Hausam (Jan 08 2021 at 17:11):
Yes, that was a long time ago. :) Let me catch up on this thread, and I'm happy to contribute.
Jose Costa Teixeira (Jan 08 2021 at 18:35):
I don't think (unless there is a reason for it) that the ExposureRisk should repeat the substance code. It could well be a simple extension(or modifier extension if that is more accurate).
Jose Costa Teixeira (Jan 08 2021 at 18:37):
If I want to say a) "allergic to seafood", and if I want to say b) "allergic to seafood - risk of anaphylaxis", I don't see why "seafood" in case a) is in one element, and in case b) is another element in an extension
Jose Costa Teixeira (Jan 08 2021 at 18:37):
makes profiling esp difficult, because I want to make allergyIntolerance.code mandatory, which I cannot do if I am to support this extension
Rob Hausam (Jan 08 2021 at 20:13):
I agree with @Jose Costa Teixeira's inclination to have the code in only one place, but there is a little more to it than that. Even though we didn't actually make it explicit in the extension with a value set binding (and I think I probably should have, as preferred or example), the idea was that in the extension we retain the original semantics and the name of the 'substance' element, rather than the broader semantics of 'code', which logically would mean binding it to a more restricted value set that contains only codes for substances. If we were to try to do this in the base spec using the 'code' element, I'm not sure how we would (or if we even could) go about that. I don't think that we can effectively use an invariant to restrict or change the the allowable set of codes in the way that we would want. So, even with the issues that Jose points out, I think it's probably best to leave the extension as it is - or, if we think that it is not useful (which may well be the case) or is too confusing or misleading, then instead to just remove it. @Michelle (Moseman) Miller
Jose Costa Teixeira (Jan 08 2021 at 20:31):
I'm not going to use it because it messes up the profile
Jose Costa Teixeira (Jan 08 2021 at 20:54):
I can understand in some cases may be for a different concept - but I don't see the use case for different codes.
Still, the issue, more than duplication, is the fact that I the extension prevents the use of allergyIntolerance.code
Last updated: Apr 12 2022 at 19:14 UTC
