Stream: implementers
Topic: Value set definition vs expansion
Elliot Silver (Jul 06 2021 at 22:46):
Lloyd McKenzie said:
It does point out a short-coming in the CodeSystem resource - we can't differentiate "this is what I'm prepared to tell you right now" from "this is what I actually know and am capable of telling you"
This reminds me of an issue I was looking at recently of how to differentiate a value set definition from a particular expansion of it. The challenge is to manage the definition independently of the expansion. The definition may be refined over time. The code systems that the expansion draws on may also change over time, resulting in different expansions.
How do I search for valueset definitions vs. expansions? If I search by canonical (and business version) will I get definitions, expansions, or both? (Or viewed a different way, can I have two value set resource with identical canonical and business versions?)
I think part of the answer to this comes down to the expansion identifier, but I didn't see relevant documentation.
Robert McClure (Jul 07 2021 at 15:41):
This is confusing to all because the same resource tyoe (and often the same instance) to represent the definition (ValueSet.compose) and the expansion (ValueSet.expansion). Yes, the ValueSet.expansion.identifier, which is a business identifier, is how you "find" a specific expansion. VSAC calls these "expansion versions" but that is misleading because an expansion is a an instance thing - it is the result of doing an $expand operation that cannot be versioned, it is the identifier for a result. Keep in mind that the intent of that expansion identifier
An identifier that uniquely identifies this expansion of the valueset, based on a unique combination of the provided parameters, the system default parameters, and the underlying system code system versions etc. Systems may re-use the same identifier as long as those factors remain the same, and the expansion is the same, but are not required to do so. This is a business identifier
is that it should be specific to the parameters that produced it but it is unlikely that the same identifier will "mean" the same thing on different servers.
Elliot Silver (Jul 07 2021 at 18:58):
Does that imply that there is no short way to determine the equivalence of an expansion of a definition on one system compared to the expansion of the definition on another system?
Robert McClure (Jul 07 2021 at 19:08):
Elliot Silver said:
Does that imply that there is no short way to determine the equivalence of an expansion of a definition on one system compared to the expansion of the definition on another system?
You can not use .identifier to confidently know that an expansion from two servers will contain the same members. That said, if two expansions have Valueset.expansion.parameter elements that match, the expectation (I have) is that the expansion members will be the same. @Peter Jordan @Michael Lawley @Grahame Grieve Do you agree?
Robert McClure (Jul 07 2021 at 19:26):
Robert McClure said:
Elliot Silver said:
Does that imply that there is no short way to determine the equivalence of an expansion of a definition on one system compared to the expansion of the definition on another system?
You can not use .identifier to confidently know that an expansion from two servers will contain the same members. That said, if two expansions have Valueset.expansion.parameter elements that match, the expectation (I have) is that the expansion members will be the same. Peter Jordan Michael Lawley Grahame Grieve Do you agree?
Actually I just realized what I just said only works if the parameters specify both codesystem.version and valueset.version if those are not specified then you can not be sure of a match. And then any other parameters provided also match.
Elliot Silver (Jul 07 2021 at 19:29):
OK, thanks. I'm glad there isn't something completely obvious that I missed as a terminology newbie. Is it worth submitting a ticket, or are these all known issues?
Peter Jordan (Jul 08 2021 at 01:32):
Given an identical ValueSet definition and identical (and comprehensive) search parameters passed to an $expansion request, it's a reasonable expectation that the same set of concepts will be returned. As Rob says, matching versions (which for SCT means both edition and version) are critical. However, in practice you will still see variations as can be demonstrated via @Michael Lawley's excellent ValueSet $expand comparison tool. A couple of notable differences in server behavior are whether inactive codes are served by default and with some of the more complex text filter searches.
Rob Hausam (Jul 08 2021 at 01:41):
The idea of having "Valueset.expansion.parameter elements that match" includes both the explicit parameters that are passed in the $expand request plus all of the "default" or otherwise unspecified parameters (including all code system versions, etc.) that the server used in arriving at the expansion results. Some of it is only a SHOULD (for non-persisted expansions), but the Comments on ValueSet.expansion.parameter state:
The server decides which parameters to include here, but at a minimum, the list SHOULD include all of the parameters that affect the $expand operation. If the expansion will be persisted all of these parameters SHALL be included. If the codeSystem on the server has a specified version then this version SHALL be provided as a parameter in the expansion (note that not all code systems have a version).
Michael Lawley (Jul 12 2021 at 13:52):
OTOH, it is entirely up to the server how the filter parameter matches. In this case you can never expect two expansions to be the same. (e.g., variations in behaviour may include acronym/abbreviation handling, spelling correction, stemming, other fuzzy matching, etc)
Last updated: Apr 12 2022 at 19:14 UTC
