Stream: terminology
Topic: VSAC Value Sets
Steve Emrick (Jun 18 2018 at 21:10):
Does anyone know if FHIR can retrieve all available definition versions for a given OID? For example:
https://cts.nlm.nih.gov/fhir/ValueSet?identifier=2.16.840.1.113883.3.526.2.39
This gives me back:
<version value="20180302"/>
But there are other definition versions that have been published that I may want to choose from. Is this within the FHIR spec?
Lloyd McKenzie (Jun 18 2018 at 23:01):
FHIR allows this - it's a question of whether the server exposes multiple versions or not. VSAC could expose all of the versions, with a different 'id' for each, but the same OID and canonical URLs and different ValueSet.version elements. If it did, your query would return all of them. However, VSAC doesn't have to do that, and there are some complexities to doing so if VSAC also wants a direct GET on the canonical URL. They're not impossible to work around, but it adds complexity to server design.
Steve Emrick (Jun 18 2018 at 23:42):
Right. Well my thinking is that since VSAC allows viewing of all past and present definition versions in the UI, returning them in the API is not too far out of reach. @Lloyd McKenzie do you know of other implementations that already do this?
Lloyd McKenzie (Jun 18 2018 at 23:45):
No. In fact, just last week we were in deep discussions about the appropriate way to do it ourselves with HL7's integrated terminology management solution (which will handle v2, v3, CDA and FHIR terminology as an integrated whole using FHIR under the covers).
Lloyd McKenzie (Jun 18 2018 at 23:46):
On the other hand, the fact I don't know anyone who's doing it means very little :)
Steve Emrick (Jun 19 2018 at 00:07):
Interesting. Well my use case is that my implementation needs to be able to be aware of value set definition versions in a standards-based way, regardless of the 'profiles' or bindings that are using them for some other program or purpose. Ideally the relevant metadata regarding the value set definition could be returned in some fashion.
Lloyd McKenzie (Jun 19 2018 at 02:51):
What you're wanting seems reasonable. @Robert McClure, thoughts?
Rob Hausam (Jun 19 2018 at 03:55):
As Lloyd says, FHIR itself is definitely capable of this. From my recollection, I think the only real reason that it wouldn't (or couldn't) work that way for VSAC now is that they have chosen to use the value set OID as the actual 'id' of the ValueSet resource on the server, and not just as a value of 'identifier' (as referenced in your query). Rob M. has definitely discussed this issue with them.
Grahame Grieve (Jun 19 2018 at 11:17):
I think that VSAC made the wrong decision for their use case. I agree that they are conformant; just that the decision they made means that they can't support your use case. As said, this has been a signficant discussion with VSAC
Steve Emrick (Jun 19 2018 at 20:39):
ok I see. they are not making a distinction between the internal server ID and a public-facing OID. @Grahame Grieve or anyone else, is what I am asking for available on other FHIR implementations?
Michael Lawley (Jun 20 2018 at 03:37):
Ontoserver would support this. If you store each version with a separate id, then you can use each separately at an instance level, they'll all be visible via search, and assuming that the versioning scheme matches either semantic versioning or datestamp versioning then the latest version will be selected when a specific version/instance isn't specified.
Michael Lawley (Jun 20 2018 at 03:44):
Note, you could also support the VSAC convention where the id == the oid in the case of the latest version.
For example, for https://cts.nlm.nih.gov/fhir/ValueSet?identifier=2.16.840.1.113883.3.526.2.39 you would store version 1.0.0 as https://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.3.526.2.39 then when a later version (say 1.1.0) is to be published, this would replace https://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.3.526.2.39 but you would the re-publish the 1.0.0 version as https://cts.nlm.nih.gov/fhir/ValueSet/xyz (for some arbitrary xyz, or just use POST and let the server chose). This way https://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.3.526.2.39 will always be the latest version, but historical versions will still be present and returned in a search like https://cts.nlm.nih.gov/fhir/ValueSet?identifier=2.16.840.1.113883.3.526.2.39
Grahame Grieve (Jun 20 2018 at 09:18):
I think most other servers support it
Robert McClure (Jun 20 2018 at 17:57):
Sorry, been off zulip for a bit. @Steve Emrick, VSAC says they have some sort of solution for this but they have not told me how that can work. I assume we've not seen this used much is because users are not exercising it yet - I agree that most servers I know of do support it. I do know of one situation in C-CDA: Problem Type where two versions of the same value set are needed, but once a user downloads the value set, it's not clear they would need API-based access to the version-specific expansion on an ongoing basis. Sure, I absolutely want the VSAC FHIR API to support this, and I'll note that the native VSAC API does, as you know. But most of the use-cases I bring up are constructed to demonstrate the need. Can you be more specific on what your need is? Perhaps then we could push VSAC a bit harder.
Steve Emrick (Jun 20 2018 at 19:58):
@Robert McClure thanks. Normally I would happily use the SVS API, however the <version> element returned in those calls are not definition versions, but expansion versions that either a) represent the date at which the expansion took place or b) are actually versions of profiles/bindings (e.g. 'MU2 2018....Update'). See example: https://vsac.nlm.nih.gov/vsac/oid/2.16.840.1.113762.1.4.1116.221/versions
In addition, if your value set is not bound to a profile, the expansion version of that value set (via the SVS API) is auto-replaced when VSAC updates relevant terminologies. We encountered this recently in our dev environment when a value set version that was referenced for drug allergies literally disappeared. So effectively, unbound value sets only have 1 (volatile) expansion version available via the SVS API. They may have announced this behavior on the VSAC listserv at some point after I left NLM so maybe I missed it.
The use case is that our software platform is pulling in value sets for drug allergies/intolerances. If we update a definition version of a value set within VSAC, I would like our platform to be aware of the fact that there is a new definition version and give our Science staff the option of updating the content to align with the new versions (as we will publish a metadata file that includes OID, Name, Definition Version, Code System, and Code System Version). Now, I realize we can create a profile in VSAC that will give us binding versions, but this is suboptimal for our use case because we would effectively have to publish a new binding version as a pre-requisite for the definition version to become visible, or alternatively use the 'draft' options (I know the eCQM crowd uses this if I recall correctly). Bottom line is that VSAC has definition versions available in the user interface, so it does have knowledge of available definition versions for all OIDs. Making them available over web services for implementations to discover is the ask. @Robert McClure let's discuss more...
Robert McClure (Jun 21 2018 at 11:24):
@Steve Emrick Let's email and find a time to talk next week. A couple of comments:
So effectively, unbound value sets only have 1 (volatile) [Latest] expansion version available via the SVS API.
You've discovered a key item in VSAC workflow and there are actually two ways to have a fixed "expansion version" live in VSAC:
1. An expansion that is created for a release, is tied to a VSAC expansion version and given the expansion version name as it's expansion version identifier.
2. An expansion that is explicitly created for publication by the author using the expansion/publication UI. This type of expansion will be given a publication date string as it's expansion version id. It is this second approach you can use for any of your value sets to insure they are officially published forever. And while not available originally, you can now do this for any value set definition version and code system combination, and so you can create a published expansion for older content.
None of this fixes the API issues you have identified and you, better than most, understand getting this changed may not be easy...
Last updated: Apr 12 2022 at 19:14 UTC
