Stream: IPS
Topic: National valuesets and GPS.
Elliot Silver (Nov 30 2021 at 00:29):
We've run into an interesting problem around IPS-compatible profiling in Canada. For many CodeableConcept elements, there is a slice with a required binding to SNOMED GPS. We have also added a slice bound to a SNOMED CT CA subset. However, these two valuesets overlap, and we can't discriminate. How are other jurisdictions dealing with the overlap between these value sets?
We have considered creating "for profile use-only" value sets that include our published SNOMED CT CA valueset, but exclude GPS concepts, but before we implement this wanted to see if what the community approach is.
Richard Townley-O'Neill (Nov 30 2021 at 01:41):
What happens if you define a Canadian profile that is not derived from IPS with the Canadian binding and require instances to conform to both your profile and IPS?
Rob Hausam (Nov 30 2021 at 04:51):
@Elliot Silver This is a good question. I still think there is value in having these slices, which represent a choice of bindings (as opposed to creating large value sets that contain potentially everything under the sun, including likely multiple equivalent and overlapping codes). But, if we keep these slices, maybe we should stop trying to discriminate on them in instance validation? We could then allow - and even "embrace" - the overlap. That would also allow us to not force the binding strength on the slices to be "required" - which has always seemed odd, and potentially is quite confusing. These are just some musings at this point - curious about thoughts from others.
Rob Hausam (Nov 30 2021 at 05:16):
What I just proposed in my musing seems to go against the guidance here. But should this possibility really be excluded? At the least, if you don't specify a discriminator, maybe one of the things you are saying is that the slices don't have to be (and likely aren't intended to be) disjoint and discriminated against in instance validation?
Elliot Silver (Dec 01 2021 at 20:06):
That guidance is part of what raised this concern for us. I don't think you can do slicing without a discriminator, even if the discriminator is just text.
Rob Hausam (Dec 02 2021 at 03:02):
I don't think that is strictly true, @Elliot Silver. Having one or more discriminators is certainly strongly encouraged, but it isn't required. The Definition of ElementDefinition.slicing.discriminator says (emphasis mine) "If one or more discriminators are provided ...". In the Comments it says "If there is no discriminator, the content is hard to process, so this should be avoided." And the eld-1 invariant on ElementDefinition.slicing is If there are no discriminators, there must be a definition discriminator.exists() or description.exists(). So if we provide some text for ElementDefinition.slicing.description, that would satisfy the rule. And I heard Lloyd make statements today during an IG review on the FMG call that indicate it is a possibility (even if not recommended) to have slices with overlapping content based on the value set bindings.
Grahame Grieve (Dec 02 2021 at 03:04):
I want to go back to the start:
We have also added a slice bound to a SNOMED CT CA subset. However, these two valuesets overlap, and we can't discriminate. How are other jurisdictions dealing with the overlap between these value sets?
Why add a slice? what is it that you're trying to achieve here?
Sheridan Cook (Dec 02 2021 at 15:04):
Grahame Grieve said:
I want to go back to the start:
We have also added a slice bound to a SNOMED CT CA subset. However, these two valuesets overlap, and we can't discriminate. How are other jurisdictions dealing with the overlap between these value sets?
Why add a slice? what is it that you're trying to achieve here?
We're writing a national implementation guide in Canada, that covers cross-border + cross-jurisdiction exchange. Within some jurisdictions terminology is standardized but across jurisdictions multiple standards exist (SNOMED CT CA, ICD 9 CM, etc) and many are still using local codes/free text.
Purpose is two fold - 1) Educate and encourage the use of known nationally standardized value sets in derivative guides, 2) we'd like to eventually use the slices to help differentiate which systems are properly using GPS, SNOMED CT Canadian Extension, ICD9 from those that don't match any slice & are entirely local code systems/free text.
Sheridan Cook (Dec 02 2021 at 15:08):
Has anyone else run into this problem? Trying to manually isolate GPS codes from the SNOMED CT CA content every release seems like an unnecessary burden on our Terminology Gateway just to get around a slicing discriminator. We're considering adding an exclude statement to the SNOMED CT CA value set and calling out any of the GPS codes as exclusions - but hoping for a more sophisticated solution.
Lloyd McKenzie (Dec 02 2021 at 17:38):
You can define a valueset that explicitly excludes another value set - that'd be one way to avoid overlap.
Grahame Grieve (Dec 02 2021 at 18:11):
I don't really understand why you're imposing an operational price on systems when you could just ask them when they connect to the system
Grahame Grieve (Dec 02 2021 at 18:12):
I expected you to say 'we are using the canadian version of snomed internally, and we don't want to lose the canadian code when we also provide a GPS code'.
Grahame Grieve (Dec 02 2021 at 18:14):
GPS is based on the international SCT version, so I expected to say, 'how on earth could receiving systems tell which code is which when they read the document?' and that the only possible answer is 'you'd have to put require the snomed version in the ca slice, and add a discriminator based on .coding.version'
Grahame Grieve (Dec 02 2021 at 18:16):
but maybe what you're doing is off in a different direction, and it's too hard for a receiving a system to sort that out, and they can only know that it's not the canadian SCT version code because they looked in the SCT-ca edition and didn't find it? In which case, there's no discriminator and you need to write a policy statement, not use slices
Last updated: Apr 12 2022 at 19:14 UTC
