Stream: terminology
Topic: ValueSet.url and .identifier on expansions
Alexander Henket (Jul 19 2016 at 15:58):
Hi. Continuing a conversation I had with Grahame where we reached a number of conclusions and left 2 items open on the topic of ValueSet expansion and the expectation on certain properties.
Here's the conclusion so far. On a ValueSet expansion:
- ValueSet.id -- leave empty unless one can retrieve the exact same expansion under that id
- ValueSet.identifier -- SHALL be that of the master ValueSet, usually the definitional ValueSet, but in rare cases it could be that the definition is not available in the FHIR realm and so only an expansion is available
- ValueSet.url -- SHALL be that of the master ValueSet, usually the definitional ValueSet, but in rare cases it could be that the definition is not available in the FHIR realm and so only an expansion is available
- ValueSet.expansion.identifier -- SHOULD be a uuid to allow receivers to track a particular expansion (I would prefer SHALL here)
Alexander Henket (Jul 19 2016 at 16:02):
So here's the thing where we did not reach agreement yet. On any resource we have, that carry .url and .identifier, they point to the object they are on. However when we talk about ValueSet expansions they point to the master ValueSet that the expansion was generated from.
Grahames argueing that the master ValueSet holds the idea behind the expansion and .url and .identifier always point to the underlying idea so there is no inconsistency.
I'm having trouble agreeing with that so I would like to poll for opinions here. Maybe I'm wrong, maybe I'm not. Please share.
Yunwei Wang (Jul 19 2016 at 17:38):
Questions about ValueSet.expansion.identifier. Is it unique per $expand operation? In order to do that, the server need to track/save all $expand operations. But for how long? For example, if the client submit a operation ValueSet/23/$expand?filter="abc" today and then the client submit the same operation one week later, should the server return the same expasion.identifier?
Alexander Henket (Jul 19 2016 at 18:32):
There is no guidance on that here: http://hl7-fhir.github.io/valueset-operations.html#expand. There is exactly 1 sentence that could lead you to believe that in most cases every expansion is unique: "The value set expansion returned by this query should be treated as a transient result that will change over time (whether it does or not depends on how the value set is specified), so applications should repeat the operation each time the value set is used."
The other notion is that expansion.identifier is likely a uuid, so that sort of resolves the issue of uniqueness
Alexander Henket (Jul 19 2016 at 18:33):
In OID terms you could just keep numbering under a branch. Whether you have one branch for all expansions or a branch per ValueSet is server discretion
Alexander Henket (Jul 19 2016 at 18:35):
You could file a tracker item for guidance. You could also see if a ConformanceProfile would be a suitable place for clients to find out server behavior for expansions. Or maybe ExpansionProfiles are a better place but I've not yet read what they do
Alexander Henket (Jul 19 2016 at 18:42):
I think that if I were building a server I would keep static expansions handy for extensional and occasional expansional ValueSets and update them as I update the master ValueSet. For intentional ValueSets I would probably decide on a case by case basis.
Grahame Grieve (Jul 19 2016 at 19:10):
my server - and others - cache the results of $expand pretty aggresively. If you ask for the same expansion again, you'll get the same expansion. with the same expansion.id.
Grahame Grieve (Jul 19 2016 at 19:11):
the rule is simple:
- if the expansion.id is the same, the content of the expansion in the resource must be a perfect match.
- if the expansion.id is different, the content of the expansion may or may not be the same as any other expansion
Grahame Grieve (Jul 19 2016 at 19:12):
I think that answers Yunwei's queation, and I'd be happy to make more clarity on that
Grahame Grieve (Jul 19 2016 at 19:13):
@Alexander Henket : you keep using this phrase: "On any resource we have, that carry .url and .identifier, they point to the object they are on"
Grahame Grieve (Jul 19 2016 at 19:14):
but this is not true. Take Patient, for instance; there can be multiple different patient resources, from diffrerent servers, with very different details , but they all have the same identifier, because they all describe the *same underlying idea*.
Grahame Grieve (Jul 19 2016 at 19:15):
reosurce.id is the thing that points to the object
Alexander Henket (Jul 19 2016 at 19:23):
I think I can finally follow that for .identifier. A person under SSN 12345 may have records in many EHRs. I'm not there yet for canonical URL, but if .url like you said is about that same "idea" then the same logic would apply
Lloyd McKenzie (Jul 19 2016 at 22:04):
Both URL and identifier are version-independent identifiers. It's quite possible for there to be multiple instances on a server that share the same URL and business identifier for most/all conformance resources - that's why we have a business "version" element. The tricky part here is that for an expansion, you might be talking about the same business version too - and we haven't talked about what happens if you find multiple instances on the same server that share both business identifier/canonical URL *and* business version. So I think it makes sense for the value set resource to talk about that piece.
Robert McClure (Jul 19 2016 at 22:32):
I agree with @Grahame Grieve approach. I'm not following @Lloyd McKenzie situation...
Lloyd McKenzie (Jul 19 2016 at 22:59):
@Robert McClure I was just saying that having multiple instances on a server that share the same business identifier and canonical URL will be common (so that's not an issue), but having multiple instances that also share the same ".version" value will be uncommon, so having some extra documentation on the ValueSet resource that discusses that (and points you to look at .expansion.id to disambiguate) would be useful.
Grahame Grieve (Jul 19 2016 at 23:01):
that's logically part of the documentation around persisting expansions
Alexander Henket (Jul 20 2016 at 19:37):
Since we seem to be reaching more and more conclusions and since my holiday starts a day from today: what to do with the tracker item that is in desparate need of more targeted text? @Grahame Grieve are you taking on to update that with what we came up here, or shall I? GF#10375
Grahame Grieve (Jul 20 2016 at 21:48):
well, let's just a dd areference to this topic to the task
Alexander Henket (Jul 21 2016 at 05:41):
Done
Grahame Grieve (Jul 21 2016 at 05:44):
thx
Michael Lawley (Jul 27 2016 at 23:11):
*.url is badly named (IMO) - it is not a Location, it is an Identifier - as I understand things, the "URLness" is actually a statement about its type
Last updated: Apr 12 2022 at 19:14 UTC
