Stream: implementers
Topic: SNOMED Global Patient Set version URI
Alexander Zautke (Sep 16 2019 at 14:07):
When using a coding based on the newly published SNOMED Global Patient Set, what would be the correct way to specify the version? Do the same rules apply as documented on the Using SNOMED CT with FHIR' page? Are there already some recommendations? I couldn't find any reference to a sctid in the GPS ImplementationGuide.
Grahame Grieve (Sep 16 2019 at 14:08):
we discussed this on Saturday. The global patient set is based on the international distribution, so you use the edition/version for that. We need to define an implicit value set for it. That's a question for #snomed
Rob Hausam (Sep 17 2019 at 00:01):
@Alexander Zautke and I discussed this further after Q4 today. Since SNOMED Int. isn't going to create a refset for it (Jane made that clear again this afternoon), I think it doesn't really fit as an implicit value set and we just need to create a value set for it. We can add it to tx.fhir.org (and ultimately UTG). But the question was mostly about the version - the code system version (when needed) would be the version of the International Edition that the GPS version is based on and the value set version would be whatever versions we have defined for that.
Jim Steel (Sep 17 2019 at 07:38):
Presumably it might also make sense to create a CodeSystem resource for it, with content=fragment
Alexander Zautke (Sep 17 2019 at 11:46):
I did exactly that at the Connectathon. I agreed with @Rob Hausam to share it, will publish it soon (still need to fix the metadata of the CodeSystem).
Grahame Grieve (Sep 17 2019 at 11:48):
we can define an implicit value set and then actually create an explicit one and then retire the explicit one later
Rob Hausam (Sep 17 2019 at 13:40):
still not sure how you want to define the implicit value set in this case?
if there's an obvious way to do it (not via refset) then I have no problem with that
Grahame Grieve (Sep 17 2019 at 13:53):
well, wouldn't SNOMED assign a concept id to this concept?
Peter Jordan (Sep 17 2019 at 18:43):
For implementations in non (SNOMED) member countries, I agree that a Code System fragment is a good solution providing this can define that it's a subset of properties (i.e. only FSN and PT) as well as concepts. In member countries, I'd favour an extensional Value Set and that's how I've currently implemented it. If the later was fed by an 'official' Reference Set, that would provide more options, but it's not a show-stopper. My main requirement is to determine which of the GPS concepts are used in the IPS - I'm hoping that SNOMED Int. provide a Reference Set for that, if not the whole GPS.
Alexander Zautke (Sep 18 2019 at 19:48):
OK, published the CodeSystem here: https://simplifier.net/GPS3/sct/~overview
Let me know if it needs any changes. The Simplifier project also contains a mapping language script if someone else wants to regenerate it.
CC @Rob Hausam
Alexander Zautke (Sep 18 2019 at 19:58):
What would now be the best way to define an explicit ValueSet? Include all codes of this CodeSystem?
Alexander Zautke (Sep 18 2019 at 20:31):
Oh, I just realised that in order to make it a ShareableCodeSystem, a version needs to be specified. What would be the version in our case? Just YYYYMMDD because we don't have a sctid?
Grahame Grieve (Sep 18 2019 at 20:33):
the version of the SCT release on which it's based, which is YYYYMMDD for SCT
Grahame Grieve (Sep 18 2019 at 20:34):
does it not have an Sct id to identify it?
Alexander Zautke (Sep 18 2019 at 20:35):
It does not as far as I'm aware, but instead it has its own release date (20190901)
Grahame Grieve (Sep 18 2019 at 20:37):
well, that's the value set version, not the code system version
Alexander Zautke (Sep 18 2019 at 20:38):
Ahh, makes sense
Grahame Grieve (Sep 18 2019 at 21:01):
here's the value set
Grahame Grieve (Sep 18 2019 at 21:01):
Grahame Grieve (Sep 18 2019 at 21:01):
needs a proper URL assigned
Rob Hausam (Sep 26 2019 at 01:11):
have been pulled away with some personal tasks and still getting caught up post-Atlanta
I'll look at Grahame's value set and see where we are and what we need to do
Grahame Grieve (Sep 26 2019 at 23:02):
just a proper url. Has SNOMED CT Assigned a concept to a reference set for this one?
Michael Lawley (Sep 26 2019 at 23:06):
There is 787778008 | Global Patient Set (foundation metadata concept)|
Michael Lawley (Sep 26 2019 at 23:06):
It is a "Simple Type Reference Set"
Michael Lawley (Sep 26 2019 at 23:08):
I don't believe it would be correct to (re)use the implicit Refset URI pattern for this ValueSet since there isn't such a reference set
Rob Hausam (Sep 26 2019 at 23:13):
I agree with Michael that the implicit Refset URI pattern isn't applicable in this case.
Grahame Grieve (Sep 27 2019 at 03:18):
I don’t follow. Why isn’t it a reference set?
Michael Lawley (Sep 28 2019 at 13:44):
SNOMED Intl don't publish it that way -- as a Reference Set in RF2
Grahame Grieve (Sep 28 2019 at 18:33):
is there a good reason for that?
Michael Lawley (Sep 30 2019 at 03:21):
@Rory Davidson
Rory Davidson (Sep 30 2019 at 06:16):
The GPS is not a specifically curated set, unlike all the other international reference sets. The GPS is more of a refset or refsets containing all those references sets, plus existing free sets, and so, at the moment, it has not been considered as a reference set that is produced within the International Edition. However, this may change as we get more feedback from the community.
Grahame Grieve (Sep 30 2019 at 06:19):
thanks Rory. I'm not sure that I follow that explanation - it doesn't seen inherently different to other refsets in nature, though I can see that it's different procedurally.
Grahame Grieve (Sep 30 2019 at 06:21):
we need a value set URI to identify the value set. I think we don't want people to just make up a URI... but our default if using the refset id won't work. So can we use something like http://snomed.info/sct?fhir_vs=GPS ?
Rory Davidson (Sep 30 2019 at 06:45):
Considering that there is already a reference set identifier in the terminology to represent the GPS, it would make sense to use that even with my previous statement. I think there is likely to be some flexibility in my statement as it makes sense in the long term. We had been waiting for more feedback, but we already use that identifier on our own public fhir server to identify that set at the moment.
However, adding to one of the points earlier on in this discussion, in countries where SNOMED CT isn't used, could the http://snomed.info/sct?fhir_vs=GPS be more useful?
Grahame Grieve (Sep 30 2019 at 06:49):
there is already a reference set identifier in the terminology to represent the GPS
I thought you said that there wasn't?
Grahame Grieve (Sep 30 2019 at 06:51):
what are you using as the URI?
Rory Davidson (Sep 30 2019 at 07:01):
There is not an RF2 release of the GPS, but there is an identifier already in the terminology (the July 2019 editon) - http://snomed.info/id/787778008 .
Grahame Grieve (Sep 30 2019 at 07:21):
ok so that would make the value set URI http://snomed.info/sct?fhir_vs=refset/787778008
Rory Davidson (Sep 30 2019 at 07:28):
Yes, I'd agree that is the most straightforward URI.
Grahame Grieve (Sep 30 2019 at 07:29):
@Rob Hausam we can note this explicitly at http://build.fhir.org/snomedct.html#implicit, yes?
Rob Hausam (Sep 30 2019 at 08:18):
yes, it makes sense to do that
Last updated: Apr 12 2022 at 19:14 UTC