Stream: IG creation
Topic: fhir.dicom has no ImplementationGuide resource
Abderrazek Boufahja (Dec 03 2021 at 13:19):
Hello. When we perform a dependency to fhir.dicom package, by configuring the sushi-config.yaml like this:
dependencies:
fhir.dicom:
uri: http://fhir.org/packages/fhir.dicom
version: 2021.4.20210910
We have a warning in the QA.html :
location: ImplementationGuide.dependency[1].url
message: The canonical URL for an Implementation Guide must point directly to the implementation guide resource, not to the Implementation Guide as a whole
fhir.dicom package does not have an ImplementationGuide resource. I suppose that it makes sense, as this package contains only value sets from DICOM, and is not seen as an IG. However, I don't know how can I fix the generated warning within QA.html .
Grahame Grieve (Dec 03 2021 at 18:49):
this is probably something to raise on #shorthand
Chris Moesel (Dec 03 2021 at 19:27):
@Grahame Grieve -- If the warning is in QA.html then it is coming from IG Publisher. I'm not sure there is anything SUSHI can do about it. I think a more generic version of the question is this: If a dependency package does not contain an ImplementationGuide resource, then what URI should be used in the primary IG's dependsOn.uri field (which is 1..1)? What the proper way to specify that dependency? This question is not specific to IGs built using FSH/SUSHI.
Grahame Grieve (Dec 03 2021 at 19:31):
oh the qa.html? I wasn't paying attention because this doesn't appear for any other package... oh and that's because the dicom package has no IG canonical URL, so you can't include a canonical URL in the reference to it.
Grahame Grieve (Dec 03 2021 at 19:36):
hmm. but it's a required element. I wonder why this hasn't come up before... I'll have to investigate
Diana_Ovelgoenne (Dec 09 2021 at 12:20):
@Grahame Grieve @Chris Moesel by the way, i tried putting as a dependency the package http://fhir.org/packages/fhir.dicom/2021.5.20211122/package.tgz and it doesn't work, i needed to use the 2021.4.20210910 to be found by sushi
Chris Moesel (Dec 09 2021 at 14:35):
SUSHI uses packages.fhir.org and packages2.fhir.org. It looks like packages.fhir.org doesn't have any versions of fhir.dicom on it. packages2.fhir.org only lists the 2021.4.20210910 version. See: https://packages2.fhir.org/packages/fhir.dicom
Grahame Grieve (Dec 22 2021 at 07:10):
the 2021e release is fixed up now
Grahame Grieve (Dec 22 2021 at 07:18):
message: The canonical URL for an Implementation Guide must point directly to the implementation guide resource, not to the Implementation Guide as a whole
fhir.dicom package does not have an ImplementationGuide resource
So the answer is to pretend that it does have an implementation guide e.g.
http://fhir.org/packages/fhir.dicom/ImplementationGuide/fhir.dicom
Chris Moesel (Dec 22 2021 at 13:55):
@Grahame Grieve -- can this be generalized to http://fhir.org/packages/${packageId}/ImplementationGuide/${packageId} for all cases where there isn't an IG resource? Or will the base part of the URL be different depending on the package?
Jose Costa Teixeira (Jan 04 2022 at 19:22):
@Chris Moesel ${packageId} or ${ig_id} ?
Chris Moesel (Jan 04 2022 at 19:32):
I assume ${package_id} because if it doesn't have an IG resource, would there even be an ${ig_id}? (Actually, I guess in the package spec we call it package name).
Jose Costa Teixeira (Jan 04 2022 at 19:39):
right. I looked at the id/ImplementationGuide/id thing and it really looks like the /ImplementationGuide/xxx convention would expect the id of the IG.
Chris Moesel (Jan 04 2022 at 19:53):
Yeah. I think that's the point. There is no IG, so we're making it up, pretending like there is one. And as long as we pretend the way Grahame says to pretend (using that format), then the IG Publisher will go along with it.
Grahame Grieve (Jan 04 2022 at 21:01):
yes
John Moehrke (Jan 19 2022 at 16:02):
should we expect that when calling on a DICOM valueset, that the IG rendering of that has a redirect thru simplifier?
John Moehrke (Jan 19 2022 at 16:03):
for example - http://build.fhir.org/ig/HL7/fhir-radiation-dose-summary-ig/StructureDefinition-modality-device.html
John Moehrke (Jan 19 2022 at 16:05):
The Device.type is bound to the DICOM modality canonical URI; but the rendering skips thru simplifier. @Grahame Grieve
John Moehrke (Jan 19 2022 at 16:08):
</span><a href=\"https://simplifier.net/resolve?scope=fhir.dicom@2021.4.20210910&canonical=http://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_33.html\">Modality</a>
John Moehrke (Jan 19 2022 at 16:43):
is this just an artifact of the way fhir.dicom is defined/published?
Ward Weistra (Jan 19 2022 at 20:53):
@John Moehrke The IG Publisher would normally figure out from the Implementation Guide resource in a package where the documentation for a specific resource lives. The fhir.dicom package is published without one. The Simplifier resolve functionality is used as a backup mechanism to find a relevant page for it.
John Moehrke (Jan 19 2022 at 20:56):
so... it is expected? The ballot on this IG complained about this. so, we were not sure if it was expected or not... and it seems odd to do differently
John Moehrke (Jan 19 2022 at 20:57):
that is to say.. there were comments on the ballot that complained about this.
John Moehrke (Jan 20 2022 at 15:34):
would be good if the IG builder would decorate these links such that a copy grabs the canonical, not the simplifier redirect.
Diana_Ovelgoenne (Jan 20 2022 at 15:49):
It would still be ok if simplifier redirects properly, currently it isn't working on the IG John mentioned above
John Moehrke (Jan 20 2022 at 15:57):
it was working
John Moehrke (Jan 20 2022 at 16:00):
I thought it was working before. but yes you need to go to the simplifier page, and then copy the canonical from there.
Grahame Grieve (Jan 27 2022 at 03:12):
this is a bug in the publisher somewhere. It should not be referring to that package as it it were a simplifier project
John Moehrke (Jan 27 2022 at 16:12):
okay, that is what the II wg presumed.
John Moehrke (Jan 27 2022 at 16:16):
I created an IG publisher issue - https://github.com/HL7/fhir-ig-publisher/issues/382
Grahame Grieve (Jan 28 2022 at 18:40):
fixed next release
Ward Weistra (Feb 07 2022 at 10:58):
@Grahame Grieve I don't see the new fhir.dicom in the package feed yet: http://fhir.org/packages/package-feed.xml
Grahame Grieve (Feb 07 2022 at 13:01):
duh thanks - missed updating the package feed. Doing it now
Grahame Grieve (Feb 07 2022 at 13:19):
done. thanks
John Moehrke (Feb 23 2022 at 23:14):
I think I am noticing that I can use DICOM codeSystem, but when I try to use a DICOM valueSet I don't get a valueSet but rather I get a link to the DICOM specification. I presume this is because DICOM has used html URLs for their canonical URI for their valueSets. These canonical URL do seem to be in their valueSets in the fhir.dicom package... Is this a known problem? Should I create a sample IG that shows off the problem?
Grahame Grieve (Feb 23 2022 at 23:26):
what do you mean, 'you don't get a valueset'?
Elliot Silver (Feb 24 2022 at 00:02):
The canonical URLs that DICOM wants to use are the html pages in the spec for that value set. Are you suggesting that the resolution is failing because the canonical ends in .html?
John Moehrke (Feb 24 2022 at 00:11):
Elliot, i don't know. I suspect this is true.
John Moehrke (Feb 24 2022 at 00:11):
Grahame, I will make a sample IG that shows you what I am seeing in my bigger IGs.
John Moehrke (Feb 24 2022 at 01:31):
Here is my test IG for DICOM codes and valuesets use - http://build.fhir.org/ig/JohnMoehrke/testDicom/branches/master/index.html
John Moehrke (Feb 24 2022 at 01:31):
github repo - https://github.com/JohnMoehrke/testDicom
John Moehrke (Feb 24 2022 at 01:40):
so, the dicom valueSet does seem to get used to validate a code is in that valueSet.... when that valueSet is directly called for in the profile. But call on that valueSet in your own valueSet and you just get a non-expanded valueSet that does not do validation. Further there are odd errors and warnings as indicated .
John Moehrke (Feb 24 2022 at 01:44):
Didn't seem to matter if I had a depends on the fhir.dicom or not.
Chris Moesel (Feb 25 2022 at 22:29):
FYI - The latest SUSHI 2.3.0 release will now infer an IG URL of the format http://fhir.org/packages/${packageId}/ImplementationGuide/${packageId} when a dependency package doesn't have its own IG resource.
John Moehrke (Mar 01 2022 at 03:19):
@Grahame Grieve I was expecting that the valuesets that dicom does have in that package would be available, but it seems they are not. See http://build.fhir.org/ig/JohnMoehrke/testDicom/branches/master/index.html
Grahame Grieve (Mar 01 2022 at 03:42):
you really can't pay attention to http/https issues...
Grahame Grieve (Mar 01 2022 at 03:42):
fix those up and try again
John Moehrke (Mar 01 2022 at 03:53):
I changed the https to http. seems better, but still odd qa error
John Moehrke (Mar 01 2022 at 03:55):
the valueset pulling in the dicom modality valueset worked -- http://build.fhir.org/ig/JohnMoehrke/testDicom/branches/master/ValueSet-JustModalitiesVS.html
John Moehrke (Mar 01 2022 at 03:56):
but binding an element to a dicom valueset, seems to bind it to a web page, not valueset. See the .modality element on this profile http://build.fhir.org/ig/JohnMoehrke/testDicom/branches/master/StructureDefinition-JohnMoehrke.testDicom.testImage.bind.html
Grahame Grieve (Mar 01 2022 at 03:56):
what's the odd qa error?
John Moehrke (Mar 01 2022 at 04:01):
okay, so the ci-build doesn't throw it. my local build throws
Error from server: Unable to find value set "https://dicom.nema.org/medical/dicom/current/output/chtml/part16/sect_CID_29.html"
which I double checked that I always asked for http:
John Moehrke (Mar 01 2022 at 04:01):
I guess I should clear all my caches, and try again?
Grahame Grieve (Mar 01 2022 at 04:03):
yes
John Moehrke (Mar 01 2022 at 04:06):
that error went away with flushed caches
Last updated: Apr 12 2022 at 19:14 UTC
