Stream: IG creation
Topic: VSAC/PhinVads Warnings
Sarah Gaunt (Nov 14 2020 at 02:48):
Getting:
ImplementationGuide.dependency[2].url warning The canonical URL for an Implementation Guide must point directly to the implementation guide resource, not to the Implementation Guide as a whole
For the VSAC and PhinVads dependencies.
This is what I have:
<dependsOn>
<uri value="http://fhir.org/packages/us.cdc.phinvads"/>
<packageId value="us.cdc.phinvads"/>
<version value="0.7.0"/>
</dependsOn>
<dependsOn>
<uri value="http://fhir.org/packages/us.nlm.vsac"/>
<packageId value="us.nlm.vsac"/>
<version value="0.1.0"/>
</dependsOn>
Presuming it's correct, can I suppress the warnings?
Jose Costa Teixeira (Nov 14 2020 at 09:14):
I think the warning is right: the url should not point to a package
Grahame Grieve (Nov 15 2020 at 10:36):
right. you should point to http://fhir.org/packages/us.cdc.phinvads/ImplementationGuide/us.cdc.phinvads
Grahame Grieve (Nov 15 2020 at 10:36):
etc
Sarah Gaunt (Nov 15 2020 at 22:28):
Thanks!
Eric Haas (Nov 16 2020 at 01:53):
OK I fixed that but I am back to getting a vsac login popup for the vsac valuesets I reference.
for example clicking on the ethnicity codes here...
http://build.fhir.org/ig/HL7/US-Core/StructureDefinition-us-core-ethnicity.html
Eric Haas (Nov 16 2020 at 01:54):
I thought this I resolved this on Friday but I must have signed in or something. @Sarah Gaunt , are you getting the same thing?
Sarah Gaunt (Nov 16 2020 at 02:01):
Just checked and yes, I am.
Sarah Gaunt (Nov 16 2020 at 02:02):
Also getting:
Bundle/bundle-jurisdiction-fetal-death-not-named: resource.value.ofType(CodeableConcept) (l780/c39) warning [Unable to determine whether the provided codes are in the value set http://phinvads.cdc.gov/fhir/ValueSet/2.16.840.1.114222.4.11.7582 because the value set or code system is not known to the validator]
Bundle/bundle-jurisdiction-fetal-death-not-named: resource.value.ofType(CodeableConcept).coding[0] (l781/c29) information Code System URI 'urn:oid:2.16.840.1.114222.4.5.274' is unknown so the code cannot be validated
I thought those were supposed to go away with the dependencies.
Grahame Grieve (Nov 16 2020 at 02:03):
back to getting a vsac login popup for the vsac valuesets I reference
When?
Sarah Gaunt (Nov 16 2020 at 02:04):
Actually - I take that back - the VSAC one I just checked still has the old format. I'll fix it and get back to you...
Sarah Gaunt (Nov 16 2020 at 02:09):
But the link in this profile brings up the login: https://build.fhir.org/ig/HL7/case-reporting/StructureDefinition-characteristics-of-home-environment.html
Sarah Gaunt (Nov 16 2020 at 02:10):
Brings up the API login though:
image.png
Probably some setting that I have - it's been pretty annoying since they change the logins...
Grahame Grieve (Nov 16 2020 at 04:05):
I don't understand. Of course it brings up the log in, since the source for the value requires that I don't distribute it and (b) you have a log in to see it
Eric Haas (Nov 16 2020 at 04:09):
@Grahame Grieve I was under the impression that the user would be able to view the values. I know is not your policy but then there is no value in using VSAC in IGs if the users can't access the values. So we are back to maintaining ValueSets :-(
Sarah Gaunt (Nov 16 2020 at 04:14):
Anybody can get a VSAC login though... No way am I putting all those value sets that have a home in VSAC inside the IG to be set in stone until the next update of the IG.
Eric Haas (Nov 16 2020 at 04:18):
having the readers jump through hoops to see the values is absurd and discourages use. Making it easier for the author and harder for the reader is not a sound enough reason and this login requirement to view VSAC is a non-starter for me.
Lloyd McKenzie (Nov 16 2020 at 04:24):
For something like CPT codes, it's the only way. The hoop-jumping is dictated by the IP-owner.
Lloyd McKenzie (Nov 16 2020 at 04:25):
For others, it depends on how dynamic the value set needs to be. If it needs to be dynamic, it either needs to be in VSAC or UTG.
Sarah Gaunt (Nov 16 2020 at 05:05):
It's not just that it makes it easier for the author - if you put them inside IG, they are totally static for the life of the IG which can't be good. It's like we have tools that are getting better and better for the source of truth for value sets, and then we statically list out the codes in the IG. It's almost as bad as listing them inside a CDA IG Word document....
Grahame Grieve (Nov 16 2020 at 05:17):
@Eric Haas I agree it's absurd. But it's not our absurdity. Take it up with @Robert McClure who can convey onwards our feeling of absurdity
Sarah Gaunt (Nov 16 2020 at 05:45):
So in terms of these PhinVads warnings I'm getting - are they expected?
Bundle/bundle-jurisdiction-fetal-death-not-named: resource.value.ofType(CodeableConcept) (l780/c39) warning [Unable to determine whether the provided codes are in the value set http://phinvads.cdc.gov/fhir/ValueSet/2.16.840.1.114222.4.11.7582 because the value set or code system is not known to the validator]
Bundle/bundle-jurisdiction-fetal-death-not-named: resource.value.ofType(CodeableConcept).coding[0] (l781/c29) information Code System URI 'urn:oid:2.16.840.1.114222.4.5.274' is unknown so the code cannot be validated
Grahame Grieve (Nov 16 2020 at 23:04):
well, yes and no. The code system is not defined anywhere in the packages that I can see, so yes, you'll get that error message. But why is it not in the package? I'm not sure about that
Sarah Gaunt (Nov 16 2020 at 23:09):
Ok, I'll make a note to ask you again after ballot... It's not super important (for me at least) right away.
Sarah Gaunt (Nov 17 2020 at 06:57):
So I thought it was only PhinVads that was not finding stuff, but it's VSAC too:
WARNING: MedicationAdministration/medicationadministration-eve-everywoman-naloxone-response: MedicationAdministration.extension[0].value.ofType(CodeableConcept): ValueSet http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.10.20.15.2.5.12 not found by validator
There are a bunch of them and they are definitely in VSAC (https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.10.20.15.2.5.12/expansion/Latest).
Any ideas? (I'm still using 0.1.0 because it still crashed the last time I tried 0.2.0)
My dependencies are:
<dependsOn>
<uri value="http://fhir.org/packages/us.cdc.phinvads/ImplementationGuide/us.cdc.phinvads"/>
<packageId value="us.cdc.phinvads"/>
<version value="0.7.0"/>
</dependsOn>
<dependsOn>
<uri value="http://fhir.org/packages/us.nlm.vsac/ImplementationGuide/us.nlm.vsac"/>
<packageId value="us.nlm.vsac"/>
<version value="0.1.0"/>
</dependsOn>
Robert McClure (Nov 17 2020 at 16:35):
@Eric Haas @Grahame Grieve The problem is not VSAC (although I agree the tech needs to improve) because the agreement NLM crafted with the IP owners at the time (decades ago) was dependent on individual user identification. The problem today, given current publisher and web-rendering capabilities, is that the community of FHIR/HL7 has not stepped up to craft an agreement with IP owners that allows unidentified users to "see" IP-protected content within the context of the IG.
I'd be interested in comments on why some seem to think it is unreasonable for IP-protected content to be included, but not visible to any viewer/reviewer that can not demonstrate they have the right to see the content? And that logging in is an unreasonable approach to demonstrate proof of rights met?
Robert McClure (Nov 17 2020 at 16:37):
@Sarah Gaunt So I'm clear, the problem you are flagging is that you can not directly include VSAC value sets within your IG - correct?
Grahame Grieve (Nov 17 2020 at 16:37):
the community of FHIR/HL7 has not stepped up to craft an agreement with IP owners that allows unidentified users to "see" IP-protected content within the context of the IG.
could we do that? if we could, that would be... the HTA, right?
Grahame Grieve (Nov 17 2020 at 16:38):
it is unreasonable for IP-protected content to be included
it is unreasonable for content to be IP protected to see, since most of it isn't actually IP protected.
Robert McClure (Nov 17 2020 at 16:39):
This was an interest I had when a member of the HTA but there was lack of support for this. Given the upcoming restructuring, that likely will have an impact on terminology governance, etc, it may not be HTA and could be TSC or other. But I absolutely think we should pursue.
Sarah Gaunt (Nov 17 2020 at 20:19):
@Robert McClure - my issue is a warning I'm getting on the VSAC value sets I'm including in my IG. (I think this is either something I'm doing wrong, or an issue with the VSAC package that the IG publisher uses)
@Eric Haas raised the issue that you need to login to VSAC to be able to view the values in a value set that is referenced in an IG. i.e. you click on the link to the value set in your IG and it takes you to the VSAC login page rather than just straight to the value set. (I think that's the issue anyway).
Grahame Grieve (Nov 17 2020 at 22:04):
it takes you to the VSAC login page rather than just straight to the value set
it takes you to the value set, but VSAC requires you to log in order to see what is actually unprotected IP
Eric Haas (Nov 17 2020 at 22:10):
@Sarah Gaunt is correct, I want the codes to be click away from the readers eyeballs. but let's table that for now since is a policy issue that will take a while to sort out. I too am getting an error with a VSAC VS that may is in the v0.1.0 package and I have manually confirmed that it will be resolved with v 0.2.0. Will 0.2.0 be ready in time for ballot? @Grahame Grieve
Grahame Grieve (Nov 17 2020 at 22:11):
0.3.0 is released to fix the issue
Grahame Grieve (Nov 17 2020 at 22:11):
well, the issue with 0.2.0. I haven't investigated Sarah's issue yet
Sarah Gaunt (Nov 17 2020 at 22:12):
Is 0.3.0 ready to go now? I can test, maybe it will fix my issue.
Eric Haas (Nov 17 2020 at 22:14):
is broken for me is sushi... I will verify is only in sushi..
Sarah Gaunt (Nov 17 2020 at 22:15):
I'm testing anyway - I like to live dangerously....
Eric Haas (Nov 17 2020 at 22:46):
still not working fro me - getting a very slow build and getting a mixed message from the log
2020-11-17 14:31:25.675 [main] INFO o.h.f.u.npm.BasePackageCacheManager [BasePackageCacheManager.java:79] Failed to resolve package us.nlm.vsac#0.3.0 from server: http://packages.fhir.org
Installing us.nlm.vsac#0.3.0 to the package cache
Fetching:............................................................................................................
......................................................................
Installing: ........................................................................................................................
.......................................................... done.
Load vsac (http://fhir.org/packages/us.nlm.vsac) from us.nlm.vsac#0.3.0 (00:44.0211)
Load Package us.nlm.vsac#0.3.0
Initialization..
...
No value set found at http://www.fhir.org/guides/test3/StructureDefinition/extension-blah#Extension.value[x] (url = 'http://vsac.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1186.8')
This package did indeed download locally and I confirmed the presence of the valueset. is there something wrong in my definition...
...
{
"id": "Extension.value[x]",
"path": "Extension.value[x]",
"type": [
{
"code": "code"
}
],
"binding": {
"strength": "required",
"description": "A bunch of example codes",
"valueSet": "http://vsac.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1186.8"
}
}
]
}
}
Grahame Grieve (Nov 17 2020 at 22:49):
how do I reproduce these issues?
Eric Haas (Nov 17 2020 at 22:51):
Its all local right now let me commit.
Eric Haas (Nov 17 2020 at 23:19):
@Chris Moesel sushi is failing with the v0.3.0 package for vsac causing the autobuild to crash. @Sarah Gaunt did you get it to work?
Sarah Gaunt (Nov 17 2020 at 23:23):
No, but I think just because I'm a moron and put in 0.2.0 instead of 0.3.0 - waiting for it to build again. Will let you know.
Sarah Gaunt (Nov 17 2020 at 23:30):
It does seem to be taking a very long time. Started at 9:14 and it's 9:30 now...
Sarah Gaunt (Nov 17 2020 at 23:31):
Of course, as soon as I posted that it finished. It didn't crash. Will check error messages.
Sarah Gaunt (Nov 17 2020 at 23:33):
Same number of warnings and errors, so it hasn't fixed any errors, but also hasn't introduced any new ones.
Sarah Gaunt (Nov 17 2020 at 23:39):
And, maybe it has fixed that issue I was having with this warning: "MedicationAdministration/medicationadministration-eve-everywoman-naloxone-response: MedicationAdministration.extension[0].value.ofType(CodeableConcept): ValueSet http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.10.20.15.2.5.12 not found by validator"
I can't find it and it's not one of my suppressed warnings, so... Whatever, I'll take it!
Sarah Gaunt (Nov 17 2020 at 23:41):
@Eric Haas You need: cts.nlm.nih.gov - not vsac.nlm.nih.gov
Eric Haas (Nov 18 2020 at 00:02):
what does 'cts' stand for and why does 'vsac' work for others like :
"binding": {
"strength": "required",
"valueSet": "http://vsac.nlm.nih.gov/fhir/ValueSet/2.16.840.1.114222.4.11.837"
}
Eric Haas (Nov 18 2020 at 00:04):
and build is taking forever...
Grahame Grieve (Nov 18 2020 at 00:13):
cts = common terminology services - an hl7 standard from before FHIR
Grahame Grieve (Nov 18 2020 at 00:14):
but generally cts = common terminology server now
Eric Haas (Nov 18 2020 at 00:16):
thanks but does it need to be
"valueSet": "http://vsac.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1186.8"
or
"valueSet": "http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1186.8"
?
Eric Haas (Nov 18 2020 at 00:31):
sushi is happy now
Sarah Gaunt (Nov 18 2020 at 00:55):
I'm trying to find the thread where I decided I had to change it from vsac to cts, but I can't. I did a bulk search and replace at some point. Now I'm second guessing myself.
@Grahame Grieve can you confirm what the correct reference is please? (cts or vsac)
Sarah Gaunt (Nov 18 2020 at 00:58):
Was this thread: https://chat.fhir.org/#narrow/stream/179202-terminology/topic/VSAC
Grahame Grieve (Nov 18 2020 at 00:59):
I think you are asking about canonical URL, and the canonical URL are http://cts.nlm.nih.gov/fhir/ValueSet/{{oid}}
Sarah Gaunt (Nov 18 2020 at 00:59):
Yes, thanks.
Eric Haas (Nov 18 2020 at 02:10):
ok thanks, I missed that nugget...
Gay Dolin (Nov 18 2020 at 16:02):
Read the thread and I am not sure if this is solved now. If not, IT MUST BE, because of all of the reasons Sarah states (wrt to "It's not just that it makes it easier for the author - if you put them inside IG, they are totally static for the life of the IG which can't be good. It's like we have tools that are getting better and better for the source of truth for value sets, and then we statically list out the codes in the IG. It's almost as bad as listing them inside a CDA IG Word document...." PLUS the authoring issues ... Its just crazy that this is an issue still. Sounds like policy people banging heads together refusing to move in to the 21st century and its VERY frustrating. I've got 100's of value sets I built in VSAC for the Multiple Chronic Conditions IG - which will be hugely problematic for those that have taken over the project (though I think think IG still sits only in Trifolia and so I can still access the value sets via the IG. Though I do have to go through 7 clicks to get to a value set the first time I open the IG for a session). That project is NIH funded. US Core is ONC funded ... and yet neither project can efficiently access an NLM funded project/tool that is VSAC. Is this not IN YOUR FACE ridiculous???
Gay Dolin (Nov 18 2020 at 17:25):
Also - looks like for Extensional sets one must use one API and for Intensional another??? Also VERY problematic and frustrating as value sets should be defined intensionally whenever possible. Yet technically and policy wise solvable. :-( image.png
Eric Haas (Nov 18 2020 at 18:34):
I am at wits end over this. here is my IG with VSAC v.0.3.0 dependency:
I converted the canonicals from:
"http://vsac.nlm.nih.gov/fhir/ValueSet/{OID}"
to
http://cts.nlm.nih.gov/fhir/ValueSet/{OID}"
http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.11.20.9.49
Eric Haas (Nov 18 2020 at 18:36):
here are a set of screen shots for one valueset:
Eric Haas (Nov 18 2020 at 18:37):
Gay Dolin (Nov 18 2020 at 18:41):
I have this URL https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1222.6/expansion - in the MCC IG in Trifolia. It resolves to the VSAC value set. (Of course this was after my 7 click first sign on for the day) image.png
Eric Haas (Nov 18 2020 at 18:41):
I'm note done yet
Eric Haas (Nov 18 2020 at 18:42):
it gets crazier
Gay Dolin (Nov 18 2020 at 18:43):
Re your last screen shot -- after you finally find and get your API key - then you get the warning in the screen shot I pasted above where you have to use a different API for intensional sets
Eric Haas (Nov 18 2020 at 18:43):
Its taking me another 10 minutes to find the @#$# key to enter in
Gay Dolin (Nov 18 2020 at 18:44):
Problem is the ALL the people that could begin to resolve the reason for these issues are not on this thread.
Eric Haas (Nov 18 2020 at 18:46):
my @#$@$# password manager is not responding
Eric Haas (Nov 18 2020 at 18:49):
Eric Haas (Nov 18 2020 at 18:50):
and I get sent here...
Eric Haas (Nov 18 2020 at 18:51):
try it again from the ig:
Eric Haas (Nov 18 2020 at 18:51):
and I get this...
Eric Haas (Nov 18 2020 at 18:53):
So not a great user experience... I sure part of it is me fat fingering something and as Gay said the rest is not going to be resolved here. I think if we keep this in for ballot we are going tobe able to expose this lunacy and hopefully bring it to a close.
Eric Haas (Nov 18 2020 at 18:59):
Oh, I almost forgot this... lots of QA errors too:
Eric Haas (Nov 18 2020 at 19:00):
Gay Dolin (Nov 20 2020 at 22:39):
http://cts.nlm.nih.gov/fhir/ValueSet/{{oid}} resolves some IG error issues - but does NOT resolve to the value set
Grahame Grieve (Nov 23 2020 at 12:34):
what does it resolve to?
Gay Dolin (Nov 30 2020 at 17:05):
https://cts.nlm.nih.gov/fhir/index.html
Gay Dolin (Nov 30 2020 at 17:29):
Robert McClure (Nov 30 2020 at 20:42):
Ok, don't carpet bomb the messenger here, but one thing to keep in mind is that the web view of a value set is not often going to be the FHIR API endpoint. And even that is not often going to be the canonical uri. We all know that so all the issues wrt changing vsac.nlm.nih.gov to cts.nlm.nih.gov is just that the canonical (cts) url is not the same url as the web (vsac) html view. As for the access shenanigans, yep - please let VSAC know you want the system to work (don't say make it open, they will just ignore that) via the https://support.nlm.nih.gov/support/create-case/ site. Only with direct logged comments will this ever change. [he now runs for cover...]
Brett Marquard (Nov 30 2020 at 20:49):
It only lets me drop one --
What should we do for the ballot? We have loads of broken links...I want to include to highlight the brokenness, but don't want make our ballot commenters suffer...
Grahame Grieve (Dec 01 2020 at 01:58):
@Gay Dolin that makes me think I got something wrong - where is that from?
Sarah Gaunt (Dec 01 2020 at 02:13):
http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.11.20.9.49 - that takes you to the screen Gay linked to.
But if you click on it in the IG it takes you to here: https://simplifier.net/resolve?scope=us.nlm.vsac@0.3.0&canonical=http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113883.11.20.9.49
From this profile: http://build.fhir.org/ig/HL7/case-reporting/branches/master/StructureDefinition-characteristics-of-home-environment.html
Eric Haas (Dec 01 2020 at 02:19):
in US Core we had to disable the package since it was causing a memory overflow error locally, also I fat-fingered a space before the canonical urls. so with the package re-enabled and the spaces removed we should be getting the same as Sarah... which will hopefully get rid of all the errors but is a dead end in regards to viewing all the concepts.
Sarah Gaunt (Dec 01 2020 at 02:20):
And maybe I'm going crazy, but I swear at some point yesterday those links were downloading a file containing the value set.
Sarah Gaunt (Dec 01 2020 at 02:23):
They were! I found it in my downloads folder - it was this value set: https://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1099.49
And it still is downloading a text file from this profile: http://build.fhir.org/ig/HL7/case-reporting/branches/master/StructureDefinition-disability-status.html
There must be a difference in the bindings between those two profiles. Will figure it out.
Sarah Gaunt (Dec 01 2020 at 02:26):
The one that downloads is required, the one that goes to that weird page is extensible.
Sarah Gaunt (Dec 01 2020 at 02:28):
The renderings look quite different too:
image.png
image.png
Grahame Grieve (Dec 01 2020 at 02:31):
where does 2.16.840.1.113762.1.4.1099.49 come from?
Sarah Gaunt (Dec 01 2020 at 02:35):
VSAC: https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.49/definition
Grahame Grieve (Dec 01 2020 at 02:35):
the answer is: no where. The IG publisher has no knowledge of this value set other than the URL you've given, so all it can do is reference the URL.
Grahame Grieve (Dec 01 2020 at 02:36):
i don't see any value set at https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.49/definition
Sarah Gaunt (Dec 01 2020 at 02:38):
Huh?
image.png
Grahame Grieve (Dec 01 2020 at 02:39):
still. that value set is not in the current vsac package. is it new?
Sarah Gaunt (Dec 01 2020 at 02:39):
Yeah, a couple of weeks old. Yes, that would make sense that it wouldn't be in there.
Sarah Gaunt (Dec 01 2020 at 02:40):
I guess it just downloads that text file for me because I'm logged into VSAC or something.
Grahame Grieve (Dec 01 2020 at 02:41):
I'm also logged in, but that URL doesn't work. This one does: https://vsac.nlm.nih.gov/valueset/2.16.840.1.113762.1.4.1099.49/expansion
Sarah Gaunt (Dec 01 2020 at 02:43):
Well, I signed out of VSAC and this link still downloads a xml text file (f.txt) of the value set. I don't know.
Sarah Gaunt (Dec 01 2020 at 02:43):
https://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1099.49
Grahame Grieve (Dec 01 2020 at 04:38):
ok these links will be fixed next release. I'm in battle with Maven right now
Gay Dolin (Dec 01 2020 at 16:25):
When I click on the link Sarah provided above I still get to: image.png
Gay Dolin (Dec 01 2020 at 16:26):
Or is that the fix that will be in the next release?
Gay Dolin (Dec 01 2020 at 16:31):
The correct URLs are the ones with "expansion" at the end e.g.= https://vsac.nlm.nih.gov/valueset/2.16.840.1.113883.3.88.12.3221.7.4/expansion
Gay Dolin (Dec 01 2020 at 16:41):
So there are several issues that need to be resolved for different IG stakeholders:
1) IG reader - 1 click to the most current value set
2) IG creator - No errors in the IG when using links that provide #1
3) IG Implementer - Easy resolution accessing the value set via API without jumping through hoops
4) FHIR message Instance creators/testers - automagical API value set member validation
- Which of these are still open issues?
- Are any of these technically impossible?
- Which of these issues are due to policy vs technical blockers?
Gay Dolin (Dec 01 2020 at 17:12):
I want to get my story straight before I/we " let VSAC know you want the system to work "
Eric Haas (Dec 01 2020 at 19:09):
Yay ....All the US Core VSAC links are working!!! ( still need an API key - which is a policy barrier)
Grahame Grieve (Dec 01 2020 at 20:37):
there are several issues that need to be resolved for different IG stakeholders
I agree with the list, but the question is whether NLM does. I think they don't
Robert McClure (Dec 02 2020 at 02:55):
@Sarah Gaunt @Grahame Grieve @Eric Haas @Gay Dolin above has pointed out a critical issue you all need to understand. In vsac the html view links you are using (the ones that have the https://vsac.nlm.nih.gov/ base) can have two different types of endpoints. The ones that end in /expansion are going to the latest expansion (latest definition version applied against the latest code system version) and are viewable by any logged in user. The ones with /definition are only visible to vsac users that are also authors because that endpoint is displaying the latest value set definition, not the expansion. Given that the FHIR API only works for enumerated definitions, it can look the same, but it's not. I assume you never want to link to the definition because what you are interested in displaying for the user to look at is the expansion.
Gay, your list of issues are actually pretty complex requirements. I'd be interested (seriously) if any terminology server supports a friendly UI that meets all those requirements because I suspect each requirement needs a different thing (html view, true FHIR resource endpoint, free and unencumbered access to any terminology independent of IP requirements, etc.)
Grahame Grieve (Dec 02 2020 at 02:57):
I assume you never want to link to the definition because what you are interested in displaying for the user to look at is the expansion
I think that's a rather surprising assumption indeed
Grahame Grieve (Dec 02 2020 at 02:58):
I'd be interested (seriously) if any terminology server supports a friendly UI that meets all those requirements
Not a single terminology server, but that combination is exactly what everyone takes for granted unless NLM is the provider
Robert McClure (Dec 02 2020 at 03:04):
Surprising assumption to you perhaps, but why look at the definition if you can't see the expansion? Not saying that a definition isn't useful at all, just saying, given the current state of FHIR vsac, you all should be displaying the expansion.
Grahame Grieve (Dec 02 2020 at 03:07):
"never want the definition" is the surprising bit.
Sarah Gaunt (Dec 02 2020 at 03:37):
Makes sense @Robert McClure (btw, I only used that link above (with definition) when I was desperately trying to find a link for Grahame to show him the value set that did indeed exist... I am definitely NOT using that in any IG anywhere.
Just to clarify - when we are building an IG we don't put "expansion" after the oid do we - these are the links starting with "cts"? Like we would never have : https://cts.nlm.nih.gov/fhir/ValueSet/{oid}/expansion? Or would we when we always want to point to the latest version?
Grahame Grieve (Dec 02 2020 at 03:38):
when the current IGPublisher sees a reference to https://cts.nlm.nih.gov/fhir/ValueSet/{oid}, it represents it in html with a link to https://vsac.nlm.nih.gov/valueset/{oid}/expansion
Sarah Gaunt (Dec 02 2020 at 03:39):
Ok.
Robert McClure (Dec 02 2020 at 12:56):
@Grahame Grieve That sounds perfect.
Gay Dolin (Dec 02 2020 at 17:57):
This ("when the current IGPublisher sees a reference to https://cts.nlm.nih.gov/fhir/ValueSet/{oid}, it represents it in html with a link to https://vsac.nlm.nih.gov/valueset/{oid}/expansion") solves 1 and 2 in my list above, does it solve 3?
Gay Dolin (Dec 02 2020 at 17:57):
I think there is some confusion in some of the comments above: The Definition link (which is really the authoring page) is NOT what is needed - except by the authors and stewards. That does NOT mean the reader can't see the what they need of the definition. Those can be accessed on the Description and/or Intensional Definition tabs. image.png
Grahame Grieve (Dec 02 2020 at 19:29):
@Gay Dolin no it doesn't solve those problems - that's in the remit of NLM
Eric Haas (Dec 02 2020 at 19:31):
Britishism of day: remit (British): the task or area of activity officially assigned to an individual or organization.
Gay Dolin (Dec 02 2020 at 20:00):
Well, I guess it sort-of solves #1 - once a person is signed in for the day. Is #2 really the remit of VSAC or is it a collaborative remit belonging to both NLM and IG Publisher?
Grahame Grieve (Dec 02 2020 at 20:01):
#2 is the publisher, yes, and there shouldn't be errors after the last release
Sarah Gaunt (Dec 03 2020 at 00:40):
Just noticed there is a 0.4.0 VSAC package - presume we should now be using that instead of 0.3.0?
Grahame Grieve (Dec 03 2020 at 01:06):
yes I think so
Sarah Gaunt (Dec 16 2020 at 02:18):
So we (@David deRoode and I) are having issues with the VSAC package verification. (I kind of ignored (until later) these warnings for my ballot IGs but this is for an IG we are trying to publish and in this case it's causing errors, not just warnings).
e.g. we are getting this error:
Questionnaire/hai-ltcf-questionnaire-mdro-cdi-summary: Questionnaire error Questionnaire.code:PopulationSummaryReportType: minimum required = 1, but only found 0 (from http://hl7.org/fhir/us/hai-ltcf/StructureDefinition/hai-ltc-population-summary-questionnaire).
I think the reason we are getting this error is because of this warning:
Questionnaire/hai-ltcf-questionnaire-mdro-cdi-summary: Questionnaire.code[1] information Code System URI 'https://www.cdc.gov/nhsn/terminology/codesystem/cdcnhsn.html' is unknown so the code cannot be validated
because it is unable to check that a slice matching the requirements actually exists because it can't validate the code system.
The slice that is required is as follows:
<element id="Questionnaire.code:PopulationSummaryReportType">
<path value="Questionnaire.code"/>
<sliceName value="PopulationSummaryReportType"/>
<min value="1"/>
<max value="1"/>
<mustSupport value="true"/>
<binding>
<strength value="required"/>
<valueSet value="http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1190.20"/>
</binding>
</element>
The slice in the instance:
<code>
<system value="https://www.cdc.gov/nhsn/terminology/codesystem/cdcnhsn.html"/>
<code value="1891-1"/>
<display value="Summary data reporting MDRO and CDI LabID Event for LTCF"/>
</code>
That value set exists in the VSAC 0.4.0 package (from .index.json):
{
"filename": "ValueSet-2.16.840.1.113762.1.4.1190.20.json",
"resourceType": "ValueSet",
"id": "2.16.840.1.113762.1.4.1190.20",
"url": "http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1190.20",
"version": "20200807"
}
From ValueSet-2.16.840.1.113762.1.4.1190.20.json:
"url": "http://cts.nlm.nih.gov/fhir/ValueSet/2.16.840.1.113762.1.4.1190.20",
"version": "20200807",
"name": "NHSNPopulationSummaryReportTypeCode(CDCNHSN)",
"status": "active",
"date": "2020-08-07T01:00:24-04:00",
"publisher": "CDC NHSN",
"compose": {
"include": [
{
"system": "https://www.cdc.gov/nhsn/terminology/codesystem/cdcnhsn.html",
The actual code from the json file:
{
"code": "1891-1",
"display": "Summary data reporting MDRO and CDI LabID Event for LTCF"
},
The value set seems correct and the code we are using in the instance is in the json file. But it's not validating.
Grahame Grieve (Dec 16 2020 at 18:56):
the value set looks wrong to me
Grahame Grieve (Dec 16 2020 at 18:57):
it's actually a reference to this, right: https://www.cdc.gov/nhsn/cdaportal/terminology/codesystem/cdcnhsn.html
Grahame Grieve (Dec 16 2020 at 18:58):
but I also see it here:
Grahame Grieve (Dec 16 2020 at 18:58):
http://hl7.org/fhir/us/hai/STU2/CodeSystem-2.16.840.1.113883.6.277.html
Grahame Grieve (Dec 16 2020 at 18:59):
looks like HTA should sort out the correct URL for this one @Carol Macumber
Carol Macumber (Dec 16 2020 at 19:54):
I believe the former (https://www.cdc.gov/nhsn/cdaportal/terminology/codesystem/cdcnhsn.html) is correct, as it is inline with the other NHSN codesystem identifier from NHSN (HSLOC - which was registered with HTA, whereas this one was not). I'll confirm with our contact at NHSN that signed off on the HSLOC code system information.
@Julie James
Grahame Grieve (Dec 16 2020 at 19:56):
that would mean that the VSAC API is wrong (it uses https://www.cdc.gov/nhsn/terminology/codesystem/cdcnhsn.html instead of https://www.cdc.gov/nhsn/cdaportal/terminology/codesystem/cdcnhsn.html )
Sarah Gaunt (Dec 16 2020 at 21:58):
BTW: The code system listing you mention above @Grahame Grieve (http://hl7.org/fhir/us/hai/STU2/CodeSystem-2.16.840.1.113883.6.277.html) will go away next time we update the HAI FHIR IG as the code system now lives in VSAC.
Robert McClure (Dec 16 2020 at 22:14):
Given that NLM has not been engaged in much of our URL improvement work, it comes as no surprise they have some code system urls that do not align. When we find them, we can ask them to change. That said, I suspect they will be resistant. I can help HTA with this but we need HTA to be the point of that spear. @Carol Macumber
Carol Macumber (Dec 16 2020 at 22:21):
Yes @Grahame Grieve , VSAC is wrong. I've confirmed two things with CDC NHSN.
1) The URL should be https://www.cdc.gov/nhsn/cdaportal/terminology/codesystem/cdcnhsn.html
2) VSAC is in the process of updating incorrect information, per a request made by CDC in mid-November. They were told it could take up to three months...
Last updated: Apr 12 2022 at 19:14 UTC
