Stream: IPS
Topic: Allowed ways to declare absence of allergies
Morten Ernebjerg (May 28 2021 at 06:59):
Hi IPSers :wave: In the IPS AllergyIntolerance profile, the code element is sliced and the absentOrUnknownAllergyIntolerance slice has a required binding to a 5-element ValueSet of (custom) codes for lack of information or known absence of allergies. Is this slice meant to just provide an example of/guidance on how to report absence of info/allergies, or does it signal that it is illegal in IPS to communicate such information using other codes that are not in the slice ValueSet ( e.g. by using the SNOMED CT code 716186003 - "No known allergy")? I did not see any statement about this in the IPS FHIR IG.
Giorgio Cangioli (May 28 2021 at 07:10):
Hi @Morten Ernebjerg the intent was that implementers use these codes for known absent / unknown, but this is not technically enforced in the profile, due to the difficulty to state you shall use these codes for expressing exceptional cases, but you are open to use whatever you want for the proper ones (even if some are preferred) :-)
Giorgio Cangioli (May 28 2021 at 07:12):
but happy to have suggestions on this...
Morten Ernebjerg (May 28 2021 at 09:04):
Thanks @Giorgio Cangioli , makes sense! It would of course be ideal to know for sure which absent/unknown codes can occur. But given that such a constraint cannot be technically enforced, I don't think it would make sense to have it as hard constraint expressed merely in text, either- I wouldn't rely on a constraint I cannot automatically check anyway. I also imagine it could be a significant burden on data sources to have to catch all the various absent/unknown codes in their system (even codes that are already in SNOMED GPS like 716186003|No known allergy) and map them to the IPS ones.
Conversely, if one takes the approach that this is mainly a problem of understanding codes - whether they are for allergies or the absence thereof - then I suppose one could consider another approach: Given that GPS is already used & recommended in IPS, one could extend the subset of GPS bound to the GPS slice to also include relevant SNOMED codes for allergy absence/no info (e.g. 716186003 & all children - currently not all in GPS - plus a "no info" code). Alternatively, it could be a separate slice bound go GPS codes for specific allergies (conditions) & then these extra codes. Then one could drop the "absence/unknown" slice and focus on encouraging users to use GPS for codes, also for the absent/unknown case. It still wouldn't solve the problem of absent/unknown codes from other systems. But it would allow systems that use SNOMED codes to just send those without mapping & would mean that receiving system only have to consider one "best-case" code system. Of course, a separate absent/unknown slice provides more direct visibility in the IG, but I'm not sure it gives more certainty/convenience. Was that approach considered?
Yunwei Wang (May 28 2021 at 14:56):
I am wondering what the intention is for such slicing. If the intention is that "implementer SHALL use these SNOMED code or these absent code", then why the slicing is "open" which allow other coding to be used? If the intention is that "implementer SHOULD use these SNOMED code but SHALL use these absent code if no data present" then why the first binding is required instead of extensible?
Rob Hausam (May 28 2021 at 15:31):
That is an option that has been considered, @Yunwei Wang. We have chosen to use the slicing because it makes the available choices much more visible, as you can clearly see the available IPS-specific absent/unknown codes, rather than having them much more "hidden" inside the larger value set (in this case it would be the AllergyIntolerance.code preferred binding to an updated Allergy intolerance substance condition - IPSvalue set - possibly with a new name - that would also contain the absent/unknown codes). It still seems like that is a useful choice for the reason that I described. And, getting back to @Morten Ernebjerg's original question, I don't think that including the absent/unknown codes in the larger value set would be of any help in resolving if these particular IPS codes for absent/unknown are the only ones that can be used - if we decided that we wanted to try (somehow) to enforce that restriction.
Morten Ernebjerg (May 31 2021 at 07:38):
@Rob Hausam Yes, I agree that using other codes for absent/unknown would not solve the issue that we cannot prevent the use of other codes & the explicit slice is definitely a clear signal to implementers. However, thinking about it again, one thing I am wondering about is why IPS uses custom codes for the absent/unknown value set, rather than using GPS codes. That way one could maintain the visible, separate slice, but data sources using GPS could use their absent/unknown data out of the box rather than having to map it.
Rob Hausam (May 31 2021 at 12:37):
@Morten Ernebjerg Yes, that's a very good question, too (and I had intended to answer it when you mentioned it previously but I didn't get to that). Once the GPS became available as an option we did think about using the existing and/or new SNOMED CT codes in the GPS for this instead of using our own IPS-specific codes. We worked with the SNOMED CT modeling and editorial team to have our codes added, but that was ultimately only partially successful. They agreed to add the additional "No known" codes, and all of those are now in SNOMED CT and the GPS, but they objected to adding any of the "No information" codes that we have defined. As I recall, the objections were about creating any codes representing the idea of "No information" (instead the suggestion being to handle that in the information model) and possibly even more so against the "relevancy of information" notion where in our "No information" code definitions we say (emphasis added) "This can mean either that there are none known, or that those known are not relevant for the purpose of this record". We still felt that the notion of relevancy of the data is needed for what we are doing in IPS (as it is a summary). So we reached an impasse on this, and rather than creating a value set with half of the codes from SNOMED CT and the other half from our IPS "Absent and Unknown Data" code system, we elected at that time to remain with using the codes from our code system entirely. We could reconsider that decision at this point, if there is a value in doing so. Or we could approach SNOMED again with a revised (in some way) proposal, but the expections for success would likely still be limited and, even if successful, it likely would take considerable effort to work through and resolve the issues and then also there is still significant time before any additional new codes that they might agree to add would be available in a future SNOMED CT release. So that's where we stand with this at the moment.
Morten Ernebjerg (May 31 2021 at 13:28):
@Rob Hausam Thanks for the thorough explanation (always curious about the reasoning)! Indeed, if there is no clean map onto pure GPS, I am not sure partially using codes would be an improvement since one would still need to have the mapping logic in place.
Last updated: Apr 12 2022 at 19:14 UTC
