Stream: implementers
Topic: AllergyIntolerance.type - Snomed codes?
Jose Costa Teixeira (Mar 23 2020 at 06:12):
We want to use SNOMED-CT codes for types of allergy:
609328004 | Allergic disposition (finding)
782197009 | Intolerance to substance (finding)
609396006 | Non-allergic hypersensitivity disposition (finding)
Jose Costa Teixeira (Mar 23 2020 at 06:13):
but AllergyIntolerance.type has an HL7 value set and is required. Is this the right field?
If so, shouldn't we prefer snomed codes if they exist?
Lloyd McKenzie (Mar 23 2020 at 13:35):
We can only prefer SNOMED codes if they're made free worldwide. We also don't use SNOMED for 'code' elements because they're opaque. With appropriate licensing we could publish a mapping though
Jose Costa Teixeira (Mar 23 2020 at 13:36):
ok but the binding is required, should it not be preferred?
Lloyd McKenzie (Mar 23 2020 at 13:39):
For code, it has to be 'required'. We don't want variation there.
Jose Costa Teixeira (Mar 23 2020 at 14:01):
so mapping / licensing are the ways into this?
Lloyd McKenzie (Mar 23 2020 at 15:41):
Y
Jose Costa Teixeira (Mar 23 2020 at 15:59):
whom should we contact? I can do that mapping for Belgium but I guess that would be relevant for others, right?
Lloyd McKenzie (Mar 23 2020 at 17:41):
If you want stuff included in the core spec, the licensing discussion would need to happen through the HL7 Terminology Authority (HTA).
Rob Hausam (Mar 23 2020 at 18:34):
@Lloyd McKenzie By "licensing discussion" are you referring to having the particular content included as part of the SNOMED CT global patient set (GPS) so that it can be included in the core FHIR spec? If that the case (and maybe that's not what you were thinking), the next opportunity for including new content to the GPS will be September 2021 - I just sent the updates for the IPS contribution to the GPS for September 2020 this morning and I'm not aware that we've identified anything additional from the FHIR spec for this round - and from the SNOMED Int. perspective I know they are ready to close the door now for GPS updates for the 2020 release (and had originally wanted to have closed it last week).
@Jose Costa Teixeira
Peter Jordan (Mar 23 2020 at 19:10):
Jose Costa Teixeira said:
We want to use SNOMED-CT codes for types of allergy:
609328004 | Allergic disposition (finding)
782197009 | Intolerance to substance (finding)
609396006 | Non-allergic hypersensitivity disposition (finding)
Aside from licensing issues, I'd suggest using 419199007 |Allergy to substance (finding)| , rather than 609328004 | Allergic disposition (finding). so that all 3 concepts in the Value Set are children (direct descendants) of 418038007 |Propensity to adverse reactions to substance (finding)|
Rob Hausam (Mar 23 2020 at 19:11):
Yes, good pick up.
Jose Costa Teixeira (Mar 23 2020 at 19:11):
Thanks @Peter Jordan
Lloyd McKenzie (Mar 23 2020 at 20:44):
@Rob Hausam I'm not totally clear on the licensing rules. Technically here we wouldn't be 'using' the SNOMED codes - but we would be looking at publishing them and declaring semantic equivalence, so it's not clear to me if we need any licensing for that to happen or not.
Rob Hausam (Mar 23 2020 at 21:00):
@Lloyd McKenzie @Jose Costa Teixeira If they're in the GPS then all that is needed is the copyright statement (which we have). If they're not in the GPS, then either we need to request to have them added or not use them (other than in example bindings). Of the four concepts mentioned (including Peter's suggestion of 419199007 |Allergy to substance (finding)|), three of them are currently in the GPS - the one that is missing is 609396006 | Non-allergic hypersensitivity disposition (finding)|. Since I just made the overall request to SNOMED International this morning, I think I can make an additional request to also have that one included in the September 2020 release - and we can see if they will accept that.
Jose Costa Teixeira (Mar 23 2020 at 21:03):
thanks. By the way, do we also have a code for "unknown type of reaction, still to be seen if it is allergy or intolerance or hypersensitivity"?
Rob Hausam (Mar 23 2020 at 21:14):
The intent for representing the "unknown reaction" is to omit AllergyIntolerance.type.
Lloyd McKenzie (Mar 24 2020 at 02:18):
@Rob Hausam We wouldn't be "using" them - the code in the instance would have to be a FHIR code - one that HL7 defines. We won't use SNOMED codes for 'code' elements, regardless of whether they're in the GPS because they're not meaningful to implementers reading the instance. The question is whether we could publish 1..1 mappings from the FHIR codes to the SNOMED codes as part of the spec. Any 'use' of the codes would be converting to or from SNOMED codes which wouldn't be something that had to happen, but something implementers could choose to do (if licensed).
Lloyd McKenzie (Mar 24 2020 at 02:18):
Would doing that require GPS?
Rob Hausam (Mar 24 2020 at 02:54):
Right - AllergyIntolerance.type is a code with a required binding, so SNOMED can't be used there. There's been some discussion about whether the FHIR spec should only publish SNOMED CT codes that are included in the GPS (which isn't the case now), but the answers so far from SNOMED International from those discussions is that there isn't a specific requirement to do that. So I think that these mappings as you have described should be fine and wouldn't require the SNOMED concepts to be in the GPS.
Jose Costa Teixeira (Mar 24 2020 at 09:41):
Where do we put the SNOMED codes then? in an extension?
Lloyd McKenzie (Mar 24 2020 at 13:26):
If you have to transmit them, yes. Though if mappings are freely available, it's not clear why they'd need to appear in the instance at all. (SNOMED codes in an extension SHOULD NOT be used in place of the HL7 codes - if they appear they should be in addition.)
Last updated: Apr 12 2022 at 19:14 UTC
