FHIR Chat · Dependencies of other IG's · shorthand

Stream: shorthand

Topic: Dependencies of other IG's

Kirstine Rosenbeck Gøeg (Oct 28 2020 at 14:54):

I am trying to establish a link between my new fsh/sushi project and a set of core profiles that I have developed earlier.

I have used Simplifier to create a package from the profiles, valuesets and codesystems etc in my core profiles. and published it on https://simplifier.net/packages which is in my understanding equivalent to packages.fhir.org - however, I have seen that other refer to https://build.fhir.org/ig/qas.json as well, as a place to look up packages. Anyway: My package, dk.fhir.ig.kl.common.caresocial, seems to be available all these places. It also has an implementation guide: http://build.fhir.org/ig/hl7dk/KL-dk/

I declare the dependency in my config.yaml file like this:
dependencies:
dk.fhir.ig.kl.common.caresocial: 0.1.7 //(I have also tried with other versions e.g. 0.1.6 , dev and current)

Then I want to use the core-profiles in my new project e.g. using my core-profile KLCommonCareSocialObservation as a parent, e.g.

Profile: KLToolsCareRSS
Parent: KLCommonCareSocialObservation
Title: "KLToolsCareRSS"
Description: "Thirty second chair stand test score, as performed in Danish municipalities"

• code = SCT#450738001
• value[x] only integer
• valueInteger 1..1

I have also tried using the canonical url as a parent as well i.e. http://kl.dk/fhir/common/caresocial/StructureDefinition/KLCommonCareSocialObservation
And I have tried to declare a dependency to a package that I have not published myself (wondering if anything was wrong with my package)

No matter what I do, sushi does not "know" the parent - the error message simply states "Parent KLCommonCareSocialObservation not found for KLToolsCareRSS"

What might be wrong?

Nick Freiter (Oct 28 2020 at 15:27):

I've tested this out, and find that I am able to use this package if I use version 0.1.6, so my dependencies looks like:

dependencies:
  dk.fhir.ig.kl.common.caresocial: 0.1.6

Note that that the indentation before dk.fhir.ig.kl.common.caresocial: 0.1.6 is significant, the dependency will not be found if that indentation is not present.

I've found that using 0.1.7 does not work for me, but I believe this may be due to a slight issue with the package. When I download the 0.1.7 version from http://packages.fhir.org/dk.fhir.ig.kl.common.caresocial, the ImplementationGuide-dk.fhir.ig.kl.common.caresocial.json resource has its version set to 0.1.6. So SUSHI is unable to find an ImplementationGuide resource in this package with a version corresponding to the expected version, 0.1.7. If this is happening, I would expect that you should see an error like:
image.png

Do you see any errors when you run SUSHI?

Nick Freiter (Oct 28 2020 at 15:35):

It does appear also that using current as a version works for me. The current version is the one that uses build.fhir.org to get whatever version of the IG has most recently been built to there.

Patrick Werner (Feb 01 2021 at 12:59):

I'm running into an issue with dependency released on Simplifier.

Patrick Werner (Feb 01 2021 at 12:59):

https://simplifier.net/Einwilligungsmanagement/~packages
de.einwilligungsmanagement 0.0.4-snapshot

Patrick Werner (Feb 01 2021 at 13:00):

This is caused by simplifier still not properly syncing its packages to the FHIR registry.

Patrick Werner (Feb 01 2021 at 13:00):

I couldn't find a way to get this work. Pointing to the downloaded package is not an option, right?

Chris Moesel (Feb 01 2021 at 14:22):

Hi @Patrick Werner. Currently, you cannot point at a specific package file on disk to have SUSHI load it -- although that is an interesting idea! Do you know if the IG Publisher supports pointing at arbitrary packages this way? I don't see anything in ImplementationGuide.dependsOn that would allow for this, so I'm a little skeptical. We likely would not want to support it in SUSHI if it still failed at the IG Publisher step anyway.

I've just tested this myself for the package you listed. I see that while SUSHI can download the package, the package it downloads from the registry does not have the snapshot elements populated, so SUSHI cannot use it. I was able to get things working by downloading the full package from Simplifier (which does have the snapshots) and adding/replacing the de.einwilligungsmanagement#0.0.4-snapshot contents in my global FHIR cache. More specifically, all the downloaded & unzipped definition files need to exist at {USER_HOME_DIR}/.fhir/packages/de.einwilligungsmanagement#0.0.4-snapshot/package/*.

Since Simplifier also uses a slightly different file-naming and IG URL scheme than the IG Publisher, I also had to specify the package uri in my sushi-config.yaml file:

dependencies:
  de.einwilligungsmanagement:
    uri: https://simplifier.net/guide/einwilligungsmanagement
    version: 0.0.4-snapshot

Chris Moesel (Feb 01 2021 at 14:24):

This is, of course, not ideal -- and your IG will fail the HL7 Auto Build process (since it will try to use the one from the registry) -- but if you just have to get it working locally, this is at least an approach you can consider.

David Pyke (Feb 01 2021 at 14:26):

So we can't set the URI to a local file path?

Patrick Werner (Feb 01 2021 at 14:28):

hey @Chris Moesel
The java validator allows this by using the -igparameter and providing a location of a downloaded FHIR package/ or a URL where a package is downloadable.

Patrick Werner (Feb 01 2021 at 14:30):

Thanks for the explanation! So Simplifier always just puts in the differentials inside of the package registry (IIRC).

Patrick Werner (Feb 01 2021 at 14:31):

This is a problem for sushi consuming Simplifier packages, right?

Chris Moesel (Feb 01 2021 at 14:40):

@David Pyke -- the uri is supposed to be the canonical URI of the IG, so setting it to the local file path wouldn't be correct -- and it still wouldn't work because SUSHI uses the URI only for metadata purposes (and can't assume that canonical URLs are resolvable anyway).

David Pyke (Feb 01 2021 at 14:42):

However, if you look at it and it's a local file path, then you could assume it's not a canonical and use it as a base ig.

Chris Moesel (Feb 01 2021 at 14:43):

@Patrick Werner -- we can look into how the IG Publisher does it and see if we can offer a similar behavior in SUSHI. And yes, StructureDefinitions without snapshots is a problem for SUSHI because SUSHI doesn't generate snapshots -- but it needs snapshots in the base profiles in order to correctly generate differentials for new profiles based on them.

Chris Moesel (Feb 01 2021 at 14:46):

David Pyke: However, if you look at it and it's a local file path, then you could assume it's not a canonical and use it as a base ig.

Maybe? But then it's not a canonical URL anymore, so when SUSHI attempts to use it for metadata reasons, it would be wrong. That structure in sushi-config.yaml is intended to mirror what will go in the generated IG JSON for dependsOn. Using it for a duel purpose would confuse matters. I think if SUSHI needs to support pointing to local packages we just need to create a very specific feature for that rather than overloading an existing field.

Patrick Werner (Feb 01 2021 at 15:11):

Chris Moesel said:

Patrick Werner -- we can look into how the IG Publisher does it and see if we can offer a similar behavior in SUSHI. And yes, StructureDefinitions without snapshots is a problem for SUSHI because SUSHI doesn't generate snapshots -- but it needs snapshots in the base profiles in order to correctly generate differentials for new profiles based on them.

This will lead to confusion, as Simplifier packages always only contain diffs, and IG packages Snapshots?

Chris Moesel (Feb 01 2021 at 15:18):

Yeah, it's not ideal. In a perfect world, Simplifier would publish to the registry w/ snapshots. I feel like this has already been discussed in the past, so I think the Simplifier team (or at least someone on the team) already knows about it. I think.

Patrick Werner (Feb 01 2021 at 15:24):

@Ward Weistra this is a related issue to https://jira.hl7.org/browse/HSCR-1

Ward Weistra (Feb 01 2021 at 15:33):

Thanks for the mention @Patrick Werner! I consider them separate issues (not that it's very relevant, but for bookkeeping). HSCR-1 is just making sure we bring registry.fhir.org Elastic in sync every x time with the packages database behind it, above is on whether Simplifier.net should or should not mandate snapshots when creating packages.
The latter has certainly been discussed and I was under the impression we did for new packages. Lemme check...

Patrick Werner (Feb 01 2021 at 15:36):

thanks! (and i agree, separate issues, related only through impact on downstream tooling)

Ward Weistra (Feb 01 2021 at 15:38):

I was wrong, we don't. I'll get it back on the agenda. @Patrick Werner @Chris Moesel

Patrick Werner (Apr 06 2021 at 08:01):

Hey @Ward Weistra any progress on including Snapshots into the packages?
I think this issue will affect more and more people as many people are shifting to sushi at the moment.

Ward Weistra (Apr 06 2021 at 09:59):

@Patrick Werner Yes, we continued discussing this here: https://chat.fhir.org/#narrow/stream/215610-shorthand/topic/Dependencies/near/230725234

Last updated: Apr 12 2022 at 19:14 UTC