Stream: terminology
Topic: Indicating in a ValueSet SNOMED CT GPS Codes
Oliver Egger (May 04 2020 at 18:19):
I would like to document in a ValueSet which codes are coming from the SNOMED CT GPS (Global Patient Reference Set). I intended to use a different include system for the SNOMED CT GPS codes. For both http://snomed.info/sct?fhir_vs=refset/787778008 source or http://snomed.info/valueSet/GPS source the IGPublisher responds with an error: Unable to provide support for code system ...
1.) Is this the right approach to reference the GPS ValueSet or should it be done differently?
2.) With which canonical can I reference the GPS ValueSet?
For now I just use http://hl7.org/fhir/StructureDefinition/valueset-system to document, example is up here, but I would prefer to have it validated with the terminology server.
Peter Jordan (May 04 2020 at 21:04):
Hi @Oliver Egger . It would be informative to understand your use case for indicating which codes in a ValueSet of SCT Concepts are also members of the GPS RefSet. For example, is it because the ValueSet will be used by non-SNOMED members? AFAIA, the agreed canonical URL for the GPS is http://snomed.info/valueSet/gps (n.b. it's deliberately not a FHIR-specific uri); however, I don't know if this is currently recognised by the IG Publisher.
Grahame Grieve (May 04 2020 at 21:31):
@Peter Jordan I'd be happy to have a validator test case submitted to make sure it is recognised (that is, a profile using the value set, and 2 examples, one valid and one not).
@Oliver Egger the current example looks correct. the GPS is a value set, not a different code system. It seems to me that you want a different copy right statement there instead, something like
"This value set includes content from the Global Patient set (GPS) sub-set of SNOMED Clinical Terms® (SNOMED CT®) which is copyright of the International Health Terminology Standards Development Organisation (IHTSDO). The Global Patient Set is produced by SNOMED International and is licensed under the Creative Commons Attribution 4.0 International License. The GPS is made available to users at no cost. For more information contact http://www.snomed.org/snomed-ct/getsnomed-ct or info@snomed.org."
Grahame Grieve (May 04 2020 at 21:36):
if you wanted to publish a value set and ensure that the contents are only from the GPS, then you would do this:
"compose" : {
"include": [{
"system" : "http://snomed.info/sct",
"concept" : [{
"code" : "49727002"
},{
"code" : "84229001"
}],
"valueSet" : ["http://snomed.info/valueSet/gps"]
}
}
Grahame Grieve (May 04 2020 at 21:36):
if one of the listed codes is not in the GPS, it will not be included in the expansion
Rob Hausam (May 04 2020 at 21:38):
@Oliver Egger SNOMED International has created the refset identifier for GPS, but (at least so far) they haven't actually released it as a refset yet. There is ongoing discussion about that. I don't think that the Snowstorm server supports that (yet)? Are you sure if the GPS value set url is official now, @Peter Jordan? We can inquire further about all of this on the SNOMED on FHIR call tomorrow.
Rob Hausam (May 04 2020 at 21:40):
In the meantime, we've defined FHIR value sets for the entire GPS (as well as several subsets) in the IPS IG here and here.
Rob Hausam (May 04 2020 at 21:50):
If we are able to define the GPS value set using the reset implicit value set syntax for the IPS IG build with the tx.fhir.org server, we would prefer to do that - but in the meantime we've done what I've shared above.
Peter Jordan (May 04 2020 at 22:39):
@Rob Hausam I'm not sure if that GPS value set url is official but, as you say, we can ask that question on tomorrow's call. BTW, not sure how I missed this, but I've just noticed -from those IPS IG links - that 7 concepts, relating to the Coronavirus, were added to the IPS value set in March. Were these also added to the GPS value set as well?
Rob Hausam (May 05 2020 at 00:37):
Yes, pretty much. They've stated that those 7 coronavirus concepts in the March 9 interim release will be part of the upcoming GPS release, and that they can be used as GPS concepts now.
Oliver Egger (May 05 2020 at 07:43):
Peter Jordan said:
Hi Oliver Egger . It would be informative to understand your use case for indicating which codes in a ValueSet of SCT Concepts are also members of the GPS RefSet. For example, is it because the ValueSet will be used by non-SNOMED members?
The ValueSet is currently used to describe the symptoms for the Corona Science App in Switzerland. Switzerland has a SNOMED CT license. Their are currently talks to internationalise the Corona Science App and for that we wan't to document which codes are in the GPS and which ones are not. I think (but I'm not a lawyer) that a version for another country which has no SNOMED CT licenses could not use the non GPS codes. At the moment I was just looking how to document it in the Implementation Guide, that we have not yet another Excel Sheet around documenting which codes are from where :grinning:
Oliver Egger (May 05 2020 at 07:48):
Grahame Grieve said:
if one of the listed codes is not in the GPS, it will not be included in the expansion
Thanks a lot for the input. I was not aware that I can use the valueSet in this way, now so obvious :tada:
Peter Jordan (May 05 2020 at 23:46):
Following today's SNOMED on FHIR call, the url for the GPS Value Set on my Server is now http://snomed.info/id/787778008 There were also discussions on using the implicit value set syntax, but that is problematic for SNOMED Member Countries until the GPS becomes an ófficial' SNOMED RefSet and not feasible at all for non-members.
Grahame Grieve (May 06 2020 at 00:18):
can you explain this a little more please
Peter Jordan (May 06 2020 at 00:34):
At present, the GPS isn't distributed in RF2 format. An implementation in a SNOMED Member Country might transpose it into that format (using SCTID 787778008 which is now in the International Edition) and this would make it accessible, via a FHIR API, using the implicit ValueSet Syntax - http://snomed.info/sct?fhir_vs=refset/[sctid].
OTOH, an implementation in a non-member country has to treat the GPS as an extensional value set using the elements in the distribution format (id, active, FSN & preferred term) - it has no mechanism for transposing this to a Reference Set, i.e. no concept, description or relationship objects.
Grahame Grieve (May 06 2020 at 00:34):
why does that dictate the identification?
Peter Jordan (May 06 2020 at 00:36):
The identification has to be constant across member and non-member countries and is not specific to FHIR.
Grahame Grieve (May 06 2020 at 00:37):
well, I agree with that but I still don't know why a technical representation issue relates to the identification. I'm at a disadvantage, since I don't know where the minutes are, but now I'm just confused - is there a formal decision?
Peter Jordan (May 06 2020 at 00:40):
https://confluence.ihtsdotools.org/pages/viewpage.action?pageId=106707563 No formal decision.
Grahame Grieve (May 06 2020 at 00:41):
they don't help much. So let's see if I can rephrase this decision:
- we can't use the usual way of identifying a reference set since people who can't use reference sets can't build the GPS as a reference set.
Rob Hausam (May 06 2020 at 00:42):
Yes, it was not a formal decision, but it was at least an informed opinion with significant SNOMED staff input.
Grahame Grieve (May 06 2020 at 00:42):
huh?
Grahame Grieve (May 06 2020 at 00:42):
that decision doesn't make sense to me
Rob Hausam (May 06 2020 at 00:45):
I'm not sure that was actually the conclusion. We were just asking about the preferred identification for the GPS value set. But my recollection is that we didn't explicitly say where it could (or couldn't) be used as the canonical url. The discussion in my opinion didn't quite squarely address that point. But I'm not even sure what set of alternatives we are discussion here - Peter mentioned http://snomed.info/id/787778008 as the recommended one.
Peter Jordan (May 06 2020 at 00:52):
Well, that's at least the 3rd version of a Constant value for the url that I've implemented. :)
Grahame Grieve (May 06 2020 at 01:16):
it has a refset associated with it, right?
Rob Hausam (May 06 2020 at 01:18):
That's part of the issue. It has a refset id, but (so far) does not have a published (or otherwise available) refset. Up until now they chose not to publish the refset - but they are reconsidering that.
Grahame Grieve (May 06 2020 at 01:28):
but it's not like they can use it for anything else
Rob Hausam (May 06 2020 at 01:33):
Not sure if I know what you mean by that - but no, they can't. Right now it's an id for what I guess you could call a "suppressed" refset - the contents of which are obtainable only from a different (csv) file distribution, and without the full refset metadata.
Grahame Grieve (May 06 2020 at 01:33):
can still be a valid identifying refset then
Rob Hausam (May 06 2020 at 01:34):
Yes, I agree it can - as in http://snomed.info/id/787778008.
Rob Hausam (May 06 2020 at 01:36):
A subtype of 446609009 |Simple type reference set (foundation metadata concept)|.
Grahame Grieve (May 06 2020 at 01:39):
why not http://snomed.info/sct?fhir_vs=refset/787778008 ?
Rob Hausam (May 06 2020 at 01:46):
The main reason would be that since the refset isn't published in the SNOMED CT distribution, that would mean that in the "normal" case when you use that url for the value set you will get nothing returned when you expand it. However, a particular server could choose to do some special behind the scenes "magic" and make that implicit value set syntax work, which would be perfectly acceptable, but that wouldn't happen "out of the box".
Peter Jordan (May 06 2020 at 01:46):
Grahame Grieve said:
That will only work for an implementation in a SNOMED member country.
Michael Lawley (May 06 2020 at 01:50):
In a world where the refset is not published, the most practical approach might be something like http://snomed.info/valueSet/gps that has compose.include.valueSet = http://snomed.info/sct?fhir_vs=refset/787778008 and possibly an explicit expansion with the actual codes listed.
Grahame Grieve (May 06 2020 at 01:51):
That will only work for an implementation in a SNOMED member country.
why? That's the logic I don't follow
Grahame Grieve (May 06 2020 at 01:52):
if anything, I think the argument shows that the reverse is true
Michael Lawley (May 06 2020 at 01:53):
will not work for us (unless we write special-case code) because there is no refset to provide the data
Rob Hausam (May 06 2020 at 01:54):
To fully implement the implicit value set syntax the server obviously needs access to the full SNOMED distribution, and when you provide the content to a SNOMED non-member you can only provide what is included in the GPS distribution (no synonyms, relationships/properties on $lookup, etc.).
Grahame Grieve (May 06 2020 at 01:55):
unless we write special-case code
but you have to do that anyway
Grahame Grieve (May 06 2020 at 01:55):
when you provide the content to a SNOMED non-member you can only provide what is included in the GPS distribution
And what has this got to do with the identification of the value set?
Michael Lawley (May 06 2020 at 01:57):
For us, implicit URIs are protected (you can't define an explicit VS using and implicit URI), so for these sorts of cases we need some way to get special content in.
Using a URI like http://snomed.info/valueSet/gps would be far easier to support.
Michael Lawley (May 06 2020 at 01:59):
i.e., via data not code
Rob Hausam (May 06 2020 at 02:04):
Yes, you beat me to it, but I was going to also say that what data is returned by $lookup isn't related to the issue of value set identification. I'm not sure that I know what "implicit URIs are protected" means?
Michael Lawley (May 06 2020 at 02:07):
It means that if you try to create a ValueSet on Ontoserver with ValueSet.url = to an implicit URI, then we have a business rule that will reject it.
Rob Hausam (May 06 2020 at 02:10):
OK, I suppose that's reasonable.
Michael Lawley (May 06 2020 at 02:17):
What we could possibly do it unprotect this one specific implicit URI to allow for an explicit ValueSet
Rob Hausam (May 06 2020 at 02:17):
So what about using the implicit value set syntax in the "normal" way to reference the GPS value set as http://snomed.info/sct?fhir_vs=refset/787778008? It's seeming to me that this should be fine (assuming that the server implementation deals with obtaining the content outside of the normal SNOMED CT distribution).
Jim Steel (May 06 2020 at 02:18):
Why does the ValueSet for GPS need to be explicit?
Rob Hausam (May 06 2020 at 02:21):
It probably doesn't. It just may have seemed that it would most likely be done that way (particularly because the content is obtained separately from the SNOMED CT distribution).
Jim Steel (May 06 2020 at 02:21):
Seems like it should be distributed as a CodeSystem fragment, since that's what it is
Jim Steel (May 06 2020 at 02:22):
(or a refset within a full distribution, eventually - seems crazy not to do that as well)
Grahame Grieve (May 06 2020 at 02:22):
it's a value set, not a code system fragment.
Jim Steel (May 06 2020 at 02:22):
Why isn't it a CodeSystem fragment?
Jim Steel (May 06 2020 at 02:23):
(I mean, I agree it also exists as a ValueSet)
Rob Hausam (May 06 2020 at 02:23):
I agree it could be distributed as a code system fragment. But I'm not sure why that would be useful. The need for it is as a value set.
Grahame Grieve (May 06 2020 at 02:24):
it doens't define any new properties or displays. just a set of concepts and displays that are in a particular subset
Michael Lawley (May 06 2020 at 02:24):
It's potentially useful as a fragment because other (simple) ValueSets could be expanded relative to it
Jim Steel (May 06 2020 at 02:25):
If I'm in a non-SNOMED country, I feel like I'd want it as a CodeSystem fragment. I feel like there's an assumption (perhaps unwritten) that there is always a CodeSystem resource behind a ValueSet import
Rob Hausam (May 06 2020 at 02:26):
Yes. The only use I can see for it as a fragment is if you don't have a license to access the full distribution.
Rob Hausam (May 06 2020 at 02:27):
There is always a code system, but not necessarily (and quite often not) a CodeSystem resource.
Grahame Grieve (May 06 2020 at 02:47):
Sounds like we should fix on http://snomed.info/valueSet/gps, and go ahead and publish a value set and a code system fragement. @Peter Williams what's the chance that SI could agree to that? (so we should publish thos resources in the interim until SI is ready to do it)
Peter Jordan (May 06 2020 at 02:48):
Actually, I don't believe that a Member Country can implement the GPS as a Reference Set unless it uses the corresponding version of the International Edition with the US English language reference set. Any other edition/version/language reference set combination would produce different preferred terms. Therefore, I'm going back to http://snomed.info/valueSet/gps and note, that while typing this, Grahame is now proposing that.
Rob Hausam (May 06 2020 at 02:56):
Sorry that you have to keep changing it. :( I came away from our SNOMED on FHIR call discussion a little unclear on this - have we documented (officially) the use of http://snomed.info/valueSet/gps for referencing the GPS value set?
Jim Steel (May 06 2020 at 02:57):
is there a reason/precedent for valueSet as opposed to ValueSet or valueset?
Grahame Grieve (May 06 2020 at 02:58):
uppercase would be better. I copied Michael without noticing that
Peter Jordan (May 06 2020 at 03:00):
No problem changing a 'constant' :) I believe that the thinking was not to use 'ValueSet' as it's not a FHIR-specific identifier. FWIW, my vote would be for 'valueset' .
Rob Hausam (May 06 2020 at 03:00):
That was brought up in earlier discussion, but I don't recall if there was a clear rationale for valueSet. But one reason for not using ValueSet may be (and I think this was discussed?) that it is not specifically or necessarily referring to a FHIR ValueSet resource.
Rob Hausam (May 06 2020 at 03:00):
As Peter just also said.
Grahame Grieve (May 06 2020 at 03:01):
I think that's short sighted. I agree that the identifier will find use outside FHIR, but that's no reason to clutch defeat from the jaws of victory and use valueSet or valueset instead of ValueSet
Rob Hausam (May 06 2020 at 03:02):
Your point makes sense, but I'm not sure about your conclusion - why is ValueSet a victory?
Rob Hausam (May 06 2020 at 03:05):
I do agree that the use of that convention for ValueSet doesn't necessarily imply (and isn't limited to) the use of FHIR.
Grahame Grieve (May 06 2020 at 03:07):
because if SI ever want to make http//snomed.info to be a FHIR end-point, which is what we usually do for IGs like this, then http://snomed.info/ValueSet/gps is valid and ready to go. I woouldn't argue for this outcome if it wasn't a small change, since that's speculative, but really, http://snomed.info/valueSet/gps vs http://snomed.info/ValueSet/gps - just get it right for the future in case
Rob Hausam (May 06 2020 at 03:15):
Whether it has to do with being "right" or not, I agree it probably makes sense to be set up and prepared for that possibility.
Michael Lawley (May 06 2020 at 04:57):
SI will put in a redirect to the FHIR server anyway
Michael Lawley (May 06 2020 at 04:57):
valueSet follows SI conventions of lowerCamelCase
Michael Lawley (May 06 2020 at 04:59):
I am quiet happy with that because it is a URI not a URL. IMO the valid use-case for treating a URI as a URL is for people and to return a human-oriented result, not a machine-readable one.
Rob Hausam (May 06 2020 at 21:54):
Apologies for waffling, but it sounds like we should follow the SI convention for this.
Max Masnick (Jul 18 2021 at 21:11):
Hi -- is this expected to work for limiting to the subset of SNOMED codes included in GPS?
* include codes from system SCT and valueset http://snomed.info/valueSet/gps where concept descendent-of #441742003
I'm getting this error when I try it:
Error from server: Unable to find value set "http://snomed.info/valueSet/gps"
Rob Hausam (Jul 19 2021 at 02:45):
@Max Masnick The tx.fhir.org terminology server doesn't know of the GPS value set at that url address. Try using the copy at this url, instead: http://terminology.hl7.org/ValueSet/snomed-intl-gps The value set needs to be known and available on the terminology server for that type of value set definition to be expanded successfully so it can be used by the IG publisher. This should work (let me know if it doesn't for any reason).
Rob Hausam (Jul 19 2021 at 02:49):
When I've done it I've used the valueset keyword first, before system and the where clause, but I expect that the order shouldn't matter (if the order actually does turn out to matter, that would be good to know).
Peter Jordan (Jul 19 2021 at 06:08):
@Rob Hausam that URL doesn't work for me and TTBOMK the ValueSet.url value that was agreed for the GPS is http://snomed.info/valueSet/gps (I recall that it was deliberately not FHIR-specific).
Rob Hausam (Jul 19 2021 at 12:17):
@Peter Jordan Whether that url "works" depends on how and where you are using it. You can access the value set on tx.fhir.org here:
http://tx.fhir.org/r4/ValueSet?url=http://terminology.hl7.org/ValueSet/snomed-intl-gps
And in the THO CI build (not yet the official release) here:
http://build.fhir.org/ig/HL7/UTG/ValueSet-snomed-intl-gps.html
The FHIR IG Publisher is able to use it. We need to keep in mind that there is only one SNOMED CT code system and therefore also only one GPS (available as a SNOMED CT refset or the separate publication), but there is not any expectation or agreement (that I can think of) about having only one value set that represents that content in FHIR. In fact, that really wouldn't make sense - since there is more than one way to define (in ValueSet.compose) the GPS value set, each of those ways must have a different url. The http://snomed.info/valueSet/GPS url identifies the GPS value set on the Snowstorm server, where it is defined intensionally via an ECL filter and the refset id. The GPS value set identified by the http://terminology.hl7.org/ValueSet/snomed-intl-gps url is defined extensionally, and that can be used by servers such as tx.fhir.org which do not (at least not yet) support the intensional ECL-based definition (if I try to expand the intensionally defined value set on tx.fhir.org I get an OperationOutcome with: The filter "constraint = ^787778008 |Global Patient Set (foundation metadata concept)|" was not understood in the context of http://snomed.info/sct). So that is what is going on here and why there are different urls for the SNOMED CT GPS FHIR value set(s) that are being used.
@Max Masnick
Peter Jordan (Jul 19 2021 at 23:57):
@Rob Hausam - thanks for that explanation. I was thinking that all the GPS Value Sets would use http://snomed.info/valueSet/gps - as the canonical source of truth - in the .url property (i.e. as an identifier) regardless of their internal implementation (be that extensional, implicit or intensional). I use it on Terminz where it's defined intensionally via an ECL Filter, but I could equally have used a Reference Set Filter.
Rob Hausam (Jul 20 2021 at 03:21):
@Peter Jordan After thinking more about your comments I realized that my explanation was very incomplete. I've been used to seeing the ECL syntax for defining the refset-based value set and I was ignoring the simpler refset syntax using 'in`. The tx.fhir.org server does support that refset-based syntax. But the International Edition distribution doesn't contain the GPS or IPS refsets, so we still can't use that on tx.fhir.org at the moment. And I guess that we may have not actually specified whether we should expect value sets that use different definition syntaxes, but are supposed to be equivalent and that should contain the same expansion contents, either should or could use the same canonical urls? I don't think I had ever really considered that before - and I'm not sure actually what the best practice is.
Robert McClure (Jul 26 2021 at 09:49):
Each version of “a” value set as defined by one canonical úrl can have a different CLD. That said, it makes sense that SNOMED source of truth would have a canonical that others who are accurately representing the entire value set metadata and CLD could use the same canonical. But I’d be against using the same canonical if you have a different CLD or metadata. The expansion should not be all you consider
Michael Lawley (Jul 29 2021 at 04:18):
You would have to be very careful that the CLD was the same - eg an enumeration of codes is only the same as a refset/ECL filter if you are explicit about versions
Last updated: Apr 12 2022 at 19:14 UTC
