Stream: implementers
Topic: NLM VSAC Server
Robert Nielsen (Oct 15 2020 at 17:29):
How does everyone think resolving VSAC value sets and code systems should work, architecturally? Obviously the NLM servers (both FHIR and REST API) are the source of truth for these value sets ... but can or should they be asked to handle requests from all the installed FHIR servers in the world? Are the NLM servers behind a CDN (thus spreading the load)? Should everyone use a prescribed caching design? What do people do now?
Grahame Grieve (Oct 15 2020 at 19:13):
They certainly should not be used from production systems. The lack of a SLA should ensure that, but NLM should state that somewhere.
Grahame Grieve (Oct 15 2020 at 19:16):
we distribute an NPM package containing the value sets from the authoritative source so systems don't need to hit the NLM servers directly
Robert Nielsen (Oct 15 2020 at 19:45):
Where can I get that NLM package?
Robert Nielsen (Oct 15 2020 at 19:45):
And that only works for intensional value sets, right?
Grahame Grieve (Oct 15 2020 at 21:19):
the package contains all the value sets, intensional or not. FHIR servers should be able to work with both. The package is here: http://fhir.org/packages/us.nlm.vsac/ (I really need to put an HTML interface there...)
Robert Nielsen (Oct 21 2020 at 22:27):
Grahame, a quick question. I downloaded the package.tgz file from the web site you referenced, and unpacked it. I was playing around and checking references to other ValueSets inside the ValueSets in that file, and found that some of them (well, actually 190) weren't in the package ... but the ValueSet URIs start with http://cts.nlm.nih.gov/fhir/ValueSet/ and when I look on the VSAC web site, they seem to be valid.
For example, ValueSet 2.16.840.1.113883.3.666.5.2316 is referenced by 2.16.840.1.113883.3.666.5.696 and 2.16.840.1.113883.3.666.5.2256 ... but is not included in the package.tgz file.
Should it (and the others) have been included in the file? Or do I need to go somewhere else to get the definition of that ValueSet?
(Happy to send you the full list .. but thought I would ask first).
Thanks,
Robert
Grahame Grieve (Oct 21 2020 at 23:06):
it should be in there. I don't know why it isn't?
Grahame Grieve (Oct 27 2020 at 02:51):
@Robert McClure is this one of the intentional value sets?
Gay Dolin (Oct 27 2020 at 14:41):
2.16.840.1.113883.3.666.5.696 (Any infection) is a grouping value set containing. 2.16.840.1.113883.3.666.5.903 Any Infection ICD10CM
2.16.840.1.113883.3.666.5.902 Any Infection ICD9CM
2.16.840.1.113883.3.666.5.2316 Any Infection SNOMED CT
All of these are extensional sets, NOT intensional ones. So, that is not the cause. Do intensional sets typically cause this retrieval issue STILL?
Robert McClure (Oct 27 2020 at 15:16):
As Gay noted, these are not intensional, and they exist in the published space (all member value sets must be also published to get included in a grouper.) Given the approach you took to generate the package I don't know why those did not get included.
I'm compelled to note that VSAC does require a free license to gain access to the value sets. While there is no explicit (that I can find) noted prohibition of redistribution of VSAC content, VSAC use falls under the UMLS license and that license in section 3 and 12 does prohibit redistribution of "subsets" or derivative works. @Grahame Grieve should confirm the package you've made available is in compliance with the UMLS license or is covered by a different agreement.
Grahame Grieve (Oct 30 2020 at 00:58):
no there's no different agreement. I'm going to withdraw it and require everyone to provide an APIKey to use VSAC value sets
Jean Duteau (Oct 30 2020 at 01:39):
won't that effectively mean that no one can reference NLM VSAC value sets in their implementation guides? How would it work if I wanted to and needed to provide an APIKey?
Grahame Grieve (Oct 30 2020 at 02:47):
you'll have to register with NLM for an APIKey. Then you'll have to put the key in a local configuration file, so that the IG Publisher has a copy. The ci-build and publication machines will use my own personal APIKey for their builds
Gay Dolin (Oct 30 2020 at 04:18):
FYI: @Brett Marquard @Eric Haas
Jean Duteau (Oct 30 2020 at 04:55):
Ah understood.
Robert Nielsen (Oct 30 2020 at 17:31):
So Grahame, you still think it is a good and proper thing to download the ValueSet definitions and use them locally (with the understanding that they become stale after a while), right? Or is the proper way to handle ValueSets defined by VSAC to always contact the VSAC API ... every FHIR request? I would think not (and of course there would be caching). But I would like your opinion.
Robert Nielsen (Oct 30 2020 at 17:33):
And I suppose I could just contact the VSAC server and cache the definitions of the 190 or so that are missing from the package. Not sure how much of a load that would even be.
Eric Haas (Oct 30 2020 at 22:51):
OK so catching up here. What I hear is if we intend to use VSAC where we can (and we do) we need to:
- get an API Key
- add it the fhir.ini file so we can see the VSAC terminology in our local builds
- when we push it to the auto-publisher it will still work
Brett Marquard (Nov 02 2020 at 18:23):
@Grahame Grieve do you have an example fhir.ini with a fake key populated for us to follow?
Vassil Peytchev (Nov 02 2020 at 18:53):
It is likely not in fhir.ini, as that is tracked in git. Grahame wrote "a local configuration file".
Eric Haas (Nov 02 2020 at 19:05):
Yes whatever it is ... where is is documented/and an example so I can get started?
Vassil Peytchev (Nov 02 2020 at 19:40):
I am assuming that there will be an announcement, with documentation, when the change will take place. It is pretty clear how it will work, isn't it?
Maybe we can give Grahame some time to flesh it out, especially if the API may be still in a fine-tuning stage.
I appreciate the "early access" running commentary on things to come.
Vassil Peytchev (Nov 02 2020 at 19:42):
Or is the proper way to handle ValueSets defined by VSAC to always contact the VSAC API ... every FHIR request?
My understanding is that the VSAC API will be contacted when an IG is being built and published. The use of the IG would not require contacting the VSAC API.
Robert McClure (Nov 02 2020 at 20:15):
Here is the technical documentation for the UMLS REST API that beginning Jan1, 2021 all NLM API will require. As has always been a characteristic for NLM API use, this also expects a specific user's credentials. As it stands, any access will need to generate the ticket with their own UMLS API Key. This is not "being fine tuned," it is set and has been operational for months.
Of particular note @Vassil Peytchev is that use of an IG absolutely will be under the requirement that the user meets the requirements of the UMLS license. This is the same for all HL7 artifacts: IE: any user of an IG MUST satisfy the IP requirements for any terminology utilized by the user in implementing the IG.
Vassil Peytchev (Nov 02 2020 at 20:24):
My point was that the IP requirements for using VSAC value sets is not equivalent to requiring the use the UMLS REST API when there is a code placed in a FHIR resource, which a system is returning as a result of a FHIR RESTful GET or search.
Grahame Grieve (Nov 02 2020 at 20:44):
I have not yet done this - I was just getting the external requirements in place for when I do it
Grahame Grieve (Nov 02 2020 at 20:44):
I will give doco when I do. For now, you still have to use the VSAC package
Eric Haas (Nov 02 2020 at 20:53):
I am eager to use VSAC in US Core and my question is specific to local builds where I put the basic authentication stuff:
- Will this be available near term and within the ballot deadline
- Is the VSAC package approach = dependency in the IG resource?
Grahame Grieve (Nov 02 2020 at 20:59):
yes for now, do it as a dependency.
Last updated: Apr 12 2022 at 19:14 UTC
