Stream: terminology
Topic: Locale-specific SNOMEDs and validation
Max Masnick (Jul 29 2021 at 13:55):
We have an implementer of the SMART Health Cards IG who is trying to use a Canada-specific SNOMED code for identifying a COVID vaccine.
The profile in question is here: http://build.fhir.org/ig/HL7/fhir-shc-vaccination-ig/branches/dev/StructureDefinition-shc-vaccination-dm.html
This profile slices coding based on code system. There's a SNOMED slice with a required binding to descendents of SCT#787859002 (this is the code for "vaccine product").
Canada's version of SNOMED defines 28531000087107 as a descendent of 787859002. This is the code they want to use.
The problem is that the Validator doesn't recognize this as a valid descendent of 787859002, presumably because the value set is based on standard int'l SNOMED.
UK SNOMED has the same sort of situation. There may be other locale-specific versions of SNOMED as well that we haven't run into yet.
My question: is there a way we can say "descendents of 787859002 including any locale-specific codes" in the value set? Or is there another option that would lead to successful validation (like using a different terminology server)?
Rob Hausam (Jul 29 2021 at 15:00):
@Max Masnick This is rather tough. Theoretically, for SNOMED CT value sets that do not specify a version (if a SNOMED CT version is specified it must also include an edition), the terminology server should be able to include all of these codes (at least the ones that it is aware of) from any national edition as being valid members of the value set (in $validate-code or $expand), but in practice probably no servers are actually able to do that. That's because both the IGs and the terminology servers all assume some SNOMED CT edition (either by declaration in the IG or by an explicit request or default on the server). SNOMED International itself doesn't publish, and doesn't even actually have, the complete set of all SNOMED CT content (although moving in that direction has been discussed). At present it is a distributed resource. @Grahame Grieve, I think because of issues like this, a while back worked on producing a "combined" SNOMED CT "edition" (an unofficial one) that includes all of the content for all of at least the "major" SNOMED CT editions (e.g., International, US, Canada, UK, Australia, etc.). The SNOMED CT "combined" edition is actually available on tx.fhir.org. But there are issues if you actually want to use it. because (1) the version date when it was last updated on the server is 2017-03-06 (so it's very far out of date), and (2) I'm not even sure exactly how you would specify that "edition" in your value set definition, since there is no official SNOMED CT version url that would represent it (Grahame probably defined something that can be used for that, but I don't recall at the moment if that's the case or any details of it). So I don't think there is any easy solution at the moment, but it may be something that we should consider looking at again.
Lloyd McKenzie (Jul 29 2021 at 17:04):
Wouldn't this be a question of what context is passed as part of the 'expand' operation used in the validator? That seems like something we ought to be able to make configurable...
Rob Hausam (Jul 29 2021 at 17:43):
@Lloyd McKenzie Hmm. I think I agree conceptually - but in that case, I think the context would be "everything"? Which, I think still leaves us where we were, since we don't have a way to effectively express that context? But possibly I missed part of what you are thinking.
Max Masnick (Jul 29 2021 at 18:07):
Thanks! If I'm reading this right, there are two separate issues here:
- Making tx.fhir.org (or whatever terminology server is used for validation) aware of the entire universe of SNOMED CT codes including the national editions (and for our use case in the COVID-19 vaccine space, this has to be pretty recently updated)
- Having the validator ask for the correct scope when requesting the value set expansion
Lloyd McKenzie (Jul 29 2021 at 18:09):
Sorry, response had wrong context - removed
Peter Jordan (Jul 29 2021 at 21:45):
@Max Masnick Attempting to use a SNOMED Concept from a national drug extension in a SMART Health card is a bad idea. QR character limits prevent the use of descriptions and, as the Code System for ALL released SNOMED CT concepts has to be http://snomed.info/sct, any associated lookup or validation will use the default edition and version of SNOMED CT on the requesting server (wherever that may be from the card reader perspective). If you are going to use SNOMED CT Vaccine codes, my advice is to use only the concepts in the International Edition.
UPDATE Actually 28531000087107 | Vaccine product against Severe acute respiratory syndrome coronavirus 2 (medicinal product) | will be in the July 31 release of the International Edition. Prior to that it was a pre-release concept in terms of the International Edition. Please accept my apologies - this is obviously NOT a national drug extension.
To @Rob Hausam 's point - I'm not sure that what is on tx.fhir.org is a combined SCT edition, but rather a collection of some of the major editions that contain an en-xx Language Reference Set. IMHO, creating a Universal Edition, bearing in mind ever-shortening release cycles, is a wicked problem for SNOMED International to solve.
Michael Lawley (Jul 29 2021 at 21:51):
If the Coding includes the snomed version (either a full version, or even just the edition style with no date), then the validator would know where to start looking.
That is, with a binding to descendents of SCT#787859002 but not specified version, and a Coding that says
{
"code": "28531000087107",
"system": "http://snomed/.info/sct",
"version": "http://snomed.info/sct/20621000087109/version/20210331"
}
then I would expect a $validate-code (or $expand) tobe issued using the specified version
Michael Lawley (Jul 29 2021 at 21:52):
Combined editions are not really feasible since, while you can aggregate all codes, they may have conflicting properties (eg active status, and hierarchy)
Peter Jordan (Jul 29 2021 at 22:26):
That's best practice in general but, unfortunately, there is no space for including code system versions in QR codes.
Michael Lawley (Jul 29 2021 at 23:17):
QR codes in what context? I would hope there's room in a SMART Health Card QR code?
Peter Jordan (Jul 29 2021 at 23:53):
Not in the one that I saw demonstrated by Apple. This had a Patient and 2 Immunization Resources. The later contained a code system and code in the vaccineCode (codeableconcept) element - no description or version.
Max Masnick (Jul 30 2021 at 00:30):
I think we need to be able to support the various national editions of SNOMED to meet our implementers' needs.
I agree that adding in "version": "http://snomed.info/sct/20621000087109/version/20210331" to every resource is not a good choice given the payload constraints mentioned above.
Also, looking at the documentation for Coding.version it seems like this should be populated when a code's meaning is inconsistent across versions, which I don't think is the issue here -- instead, it's that the SNOMED CT code system is essentially partitioned across different "editions" and the FHIR Validator doesn't know which partition to do a lookup in.
Lloyd McKenzie (Jul 30 2021 at 03:05):
Really, it's a validation issue. Profiles that claim to be international in scope should accept codes from all known SNOMED editions. It's a question of getting the terminology servers to do that automatically - without having to create a fake 'combined' version. The different SNOMED subsets are just that - subsets. When you validate a SNOMED code, it should be validated against all subsets unless the value set constrains to only one.
Lloyd McKenzie (Jul 30 2021 at 03:05):
We shouldn't have to do anything to the instances at all.
Rob Hausam (Jul 30 2021 at 03:24):
@Max Masnick Yes, the support should work for this - but in practice at present, on any terminology server that I'm aware of, it actually doesn't get all the way there. And I agree with LLoyd's points. One question is, how is the validator handling this? At least if the bindings are extensible or preferred (not required), you shouldn't be getting actual errors because of this. And given that this is a known situation (which isn't very likely to be resolved anytime soon), if you are getting warnings from the validator because of this while doing conformance testing for an implementation, then I think those warnings should be noted and will just need to be accepted (or, if it's in the IG publication process, suppressed). Is that what you are seeing and will that work for you (at least for now)?
Peter Jordan (Jul 30 2021 at 04:10):
SNOMED Editions are not sub-sets, partitions or fragments. Together with versions, they are complete Code Systems. There are also licensing considerations, I simply do not have a license to hold anything other than the International and NZ Editions on my Terminology Server. AFAIA, Grahame has had to obtain licenses for each separate edition that is hosted on tx.fhr.org. The expectation that any given FHIR Terminology Server will provide a positive response to a $validate-code request relating to any given SNOMED CT code is an unrealistic one. At best, it might be able to identify the source of an SCTID that it does not belong to an Edition that it holds if it that SCTID contains a namespace identifier.
Rob Hausam (Jul 30 2021 at 07:12):
Yes, agree with most of that, @Peter Jordan. But SNOMED CT actually is logically a single code system - that's why we only have a single canonical url for it, and all editions are specified as different versions. There certainly is separate licensing and the rest, as you say. And all of that illustrates why this isn't so straightforward for servers and users to manage.
Max Masnick (Jul 30 2021 at 13:46):
Our value set bindings are required -- this is important because Verifiers will need to know a priori what code systems to expect or risk rejecting a truly valid SHC. (Same goes for wallet apps -- they SHOULD display human-readable versions of the info contained within the SHC, so they need to know which code systems will appear.)
Max Masnick (Jul 30 2021 at 13:47):
Thanks to everyone above for explaining how this works -- I really appreciate.
Rob Hausam (Jul 30 2021 at 16:42):
@Max Masnick Since you are using required bindings (I understand the reason for that), I think there is something that I don't believe has been mentioned yet that may solve your immediate need (if you haven't already done this). As said before, there probably aren't any servers that will support any kind of "all edition" version of the SNOMED CT code system, but you should be able to create a value set yourself that effectively does this (and should work fine for $validate-code and $expand). If you define your value set with multiple 'include' instances for descendent-of SCT#787859002, with each include specifiying the SNOMED CT 'system' and also the 'version' url for one of the SNOMED CT editions that you are interested in (the terminology server will also need to be aware of all of the editions that you specify), that should work and give you the behavior that you want. Currently tx.fhir.org is supporting the International Edition (which is also included in the national editions, but it occasionally might be a previous version) and the national editions for the US (20210301), Canada (20200331) and Australia (20210630). We're also looking at adding the UK and Swedish editions, but still have some issues to work on with adding both of those. If you need either of those or any other editions that I didn't mention, let me know. You can also see that the Canadian edition is currently out of date, which will be important to you, but that can be updated quickly - probably by today or tomorrow. I'm hoping this may work for you - let me know if you think it will or won't.
Max Masnick (Jul 30 2021 at 16:57):
@Rob Hausam this should work for us! The two national editions we've considered so far are Canada and the UK.
I'll see if I can get the value set to work with whatever is currently in tx.fhir.org for Canada as a starting point on our end.
Max Masnick (Aug 03 2021 at 15:35):
@Rob Hausam this value set isn't expanding with tx.fhir.org -- any ideas what's wrong?
{
"resourceType": "ValueSet",
"status": "active",
"name": "VaccineSNOMED",
"id": "vaccine-snomed",
"title": "Vaccine: SNOMED CT",
"description": "",
"version": "0.6.0",
"url": "http://hl7.org/fhir/uv/shc-vaccination/ValueSet/vaccine-snomed",
"copyright": "",
"compose": {
"include": [
{
"system": "http://snomed.info/sct",
"filter": [
{
"property": "concept",
"op": "descendent-of",
"value": "787859002"
}
]
},
{
"system": "http://snomed.info/sct",
"version": "http://snomed.info/sct/20611000087101/version/20210331",
"filter": [
{
"property": "concept",
"op": "descendent-of",
"value": "787859002"
}
]
}
]
}
}
Max Masnick (Aug 03 2021 at 15:36):
(That should be Canada SNOMED)
Rob Hausam (Aug 03 2021 at 17:44):
@Max Masnick The reason that didn't work is that the 20210331 version of the Canadian edition isn't supported. If you change the version data to one that is supported, like 20200331, then it works. But you may want to define the value set by specifying the edition but not the version (e.g., http://snomed.info/sct/20611000087101), so that the latest contents of International edition (the default) and the Canadian Edition will be returned in the value set expansion. I think that's what you will want - so you get the latest available content (that is known to the server) and you don't have to update your value set each time a new version of any of the SNOMED CT international or national editions is released. And with all that said, I hadn't gotten the Canadian edition update done yet, but I'm doing it now and I'll let you know when it's complete.
Rob Hausam (Aug 03 2021 at 19:55):
The SNOMED CT Canadian Edition has now been updated to the 20210331 (latest) version.
Rob Hausam (Aug 03 2021 at 20:23):
@Max Masnick Are you seeing the codes that you expect now? I'm seeing quite a few codes showing up from the Canadian Edition (for some reason they aren't being rendered with display text - that's not ideal, but at least they's showing up).
Grahame Grieve (Aug 17 2021 at 04:38):
I did define a URL for the combined value set, but I never published it because (a) it is not generated in a reliable way - it's a research thing, and (b) it's not policy that it should exist
Max Masnick (Aug 18 2021 at 00:26):
@Rob Hausam sorry I never followed up -- what you suggested for loading in Canada SNOMED worked, though the display text for the codes is missing http://hl7.org/fhir/uv/shc-vaccination/2021Sep/ValueSet-vaccine-snomed.html
There's a bit of weirdness with the way the IG publisher handles this, like image.png
(We are including int'l, Australian, and Canadian.)
It would be great if there was a way to say "include all descendants of 787859002 regardless of edition" someday :)
Rob Hausam (Aug 18 2021 at 01:06):
@Max Masnick I agree it looks a little bit odd, but the main thing is that it's working. Did you want to also explicitly include the US Edition (or not)? I should be getting support added for the Swedish edition soon, and I also expect to add the UK edition fairly soon (there's still some things to work out for that). And then earlier today there was some discussion about looking into whether we could include the Danish Edition. And yes, the "someday" for "any edition" still would be nice.
Max Masnick (Aug 18 2021 at 12:05):
I would love to include all of these -- our IG is being balloted now, so presumably we can add them before publishing the STU1 release.
Rob Hausam (Aug 18 2021 at 12:45):
@Max Masnick Yes, it seems like that should be an update that you can made for the STU1 publication.
Michael Lawley (Aug 19 2021 at 02:09):
The specification of "include all descendants of 787859002 regardless of edition" is probably relatively safe since a natural implementation is to take the union after evaluating across each edition, but things start to get tricky once you have a ValueSet that adds in exclusion criteria.
For example, "include all descendants of 787859002, except all descendants of 836377006, regardless of edition"; what should happen if a concept is excluded in one edition, but not another?
Grahame Grieve (Aug 19 2021 at 02:16):
it won't be evaluated in more than one edition at once
Michael Lawley (Aug 19 2021 at 02:20):
So the semantics is a simple "expand for each known edition and take the union of the results"?
That seems like the simplest and most generally useful approach to me.
Grahame Grieve (Aug 19 2021 at 02:21):
well, I won't be doing that, unless I really have to. I just think that almost everyone will run that in a particular context
Rob Hausam (Aug 19 2021 at 02:25):
Yes - agree that most cases will choose a particular edition.
Michael Lawley (Aug 19 2021 at 03:39):
Yes, we wouldn't do that unless there was a specific mechanism to say "all editions"
Peter Jordan (Aug 19 2021 at 06:44):
"All editions" would still leave you with the problem of which version to use as editions have different release cycles so, at any given point in time, may be based on different versions of the International Edition (IE). For example, the NZ Edition is released in April and October each year, so the current version is still based on the 20210131 version of the IE, whereas other editions are now based on the 20210731 version.
Michael Lawley (Aug 19 2021 at 08:47):
Indeed, in such a situation you may get concepts that are inactive in the international edition but still active in the New Zealand edition (or vice versa)
Last updated: Apr 12 2022 at 19:14 UTC
