FHIR Chat · The link "XXX" for "coding" cannot be resolved · IG creation

Stream: IG creation

Topic: The link "XXX" for "coding" cannot be resolved

Etienne Cantineau (Apr 24 2020 at 08:02):

Hello, i have an error in some profiles: The link "StructureDefinition-XXX-definitions.html#XXX.XXX.coding" for "coding" cannot be resolved (valid targets: XXX targets).
It's always with a slice, the link for coding is missing the slice name in the differential view but not in the snapshot view.
Example: a profile PractitionerRole with a slice named SNOMED-CT in code;
The differential view link: <a href="StructureDefinition-be-practitionerrole-definitions.html#PractitionerRole.code.coding"> broken
The snapshot view link: <a href="StructureDefinition-be-practitionerrole-definitions.html#PractitionerRole.code:SNOMED-CT.coding"> OK

Grahame Grieve (Apr 24 2020 at 11:07):

can I reproduce this?

Etienne Cantineau (Apr 24 2020 at 13:50):

I've added the PractitionerRole profile in this repo: https://github.com/ec-ehealth/Sushi-examples. I run the last publisher version.

Grahame Grieve (Apr 29 2020 at 04:26):

is there an actual IG where I can reproduce this? looking at the outcomes doesn't help

Etienne Cantineau (Apr 29 2020 at 07:22):

Yes, here is my temp one: https://github.com/ec-ehealth/Build-source,
with outcome: https://ec-ehealth.github.io/ehealthplatformstandards/

Etienne Cantineau (May 18 2020 at 07:10):

@Grahame Grieve Hello, any news about these broken links?
Here is the QA from IG build: https://build.fhir.org/ig/ec-ehealth/Build-source/qa.html

Jose Costa Teixeira (May 18 2020 at 08:31):

I just checked this and I have a question: Does the publisher need all the elements in the path to be defined in the differential, like this?

      {
        "id": "Claim.supportingInfo:Annex",
        "path": "Claim.supportingInfo",
        "sliceName": "Annex"
      },
      {
        "id": "Claim.supportingInfo:Annex.category",
        "path": "Claim.supportingInfo.category"
      },
      {
        "id": "Claim.supportingInfo:Annex.category.coding",
        "path": "Claim.supportingInfo.category.coding"
      },
      {
        "id": "Claim.supportingInfo:Annex.category.coding.system",
        "path": "Claim.supportingInfo.category.coding.system",
        "patternUri": "http://terminology.hl7.org/CodeSystem/claiminformationcategory"
      },

or we can just define the sub-elements that matter?

      {
        "id": "Claim.supportingInfo:Annex",
        "path": "Claim.supportingInfo",
        "sliceName": "Annex"
      },
      {
        "id": "Claim.supportingInfo:Annex.category.coding.system",
        "path": "Claim.supportingInfo.category.coding.system",
        "patternUri": "http://terminology.hl7.org/CodeSystem/claiminformationcategory"
      },

I don't know if this is generic behaviour or for a slice.

Jose Costa Teixeira (May 18 2020 at 08:44):

(if I put all the paths, the errors are gone)

Rob Hausam (May 18 2020 at 13:14):

It's always been the case that the "full" (not "sparse") differential is needed, either in the profile generally or in a slice. I don't think that has changed (and your experience corroborates that). It can be a pain sometimes, if you include all of it, as you noted, then it should work.

Jose Costa Teixeira (May 18 2020 at 13:26):

@Chris Moesel is this already considered sushi?

Jose Costa Teixeira (May 18 2020 at 13:27):

@Etienne Cantineau please confirm - were these profiles generated in sushi?

Etienne Cantineau (May 18 2020 at 13:33):

Yes they were

Chris Moesel (May 18 2020 at 13:35):

My understanding is that while the publisher used to require all differential paths to be completely represented, it now supports sparse differentials... BUT sparse differentials are not allowed for paths with slices. I thought that SUSHI always filled in all the elements when slices are involved, so if that's not happening, it's a bug.

Chris Moesel (May 18 2020 at 13:35):

@Etienne Cantineau -- are you using the most recent version of SUSHI (0.12.6)?

Chris Moesel (May 18 2020 at 13:36):

(You can find out via sushi -v)

Chris Moesel (May 18 2020 at 13:38):

Actually, I take that back. I was thinking about the requirement that the element that declares the sliceName must be in the differential (even if it is from the parent profile and not actually changed). If the path under that is not allowed to be sparse, I think that may be news to us.

Chris Moesel (May 18 2020 at 13:40):

@Grahame Grieve -- are we not allowed to have sparse differentials in paths under a slice? Or is that something the publisher should be handling?

Rob Hausam (May 18 2020 at 13:42):

I know that this has been discussed on multiple occasions, but I don't have any clear recollection that it has actually changed. I would be happy to be proven wrong, though. :)

Etienne Cantineau (May 18 2020 at 13:43):

It was 0.12.5 but got the same with the newest version

Chris Moesel (May 18 2020 at 13:45):

Thanks, @Etienne Cantineau. We'll be working on some bug fixes over the next few days. If Grahame confirms that sparse differentials are not allowed under slices, we can probably fit in a fix this week.

Grahame Grieve (May 18 2020 at 19:04):

I will have to investigate

Chris Moesel (May 18 2020 at 20:20):

OK. I just found another case where the publisher is failing on sparse differentials. It's a bit of an edge case, but the following differential crashes the publisher:

  "differential": {
    "element": [
      {
        "id": "Observation.value[x].extension",
        "path": "Observation.value[x].extension",
        "short": "An extension to apply to all choices"
      }
    ]
  }

Stacktrace:

java.lang.Exception: Error generating snapshot for SampleObservation(sample-observation): Unable to generate snapshot for http://hl7.org/fhir/sushi-test/StructureDefinition/sample-observation in /Users/cmoesel/dev/fhir/sushi/build/input/profiles/structuredefinition-sample-observation
    at org.hl7.fhir.igtools.publisher.Publisher.generateSnapshots(Publisher.java:4181)
    at org.hl7.fhir.igtools.publisher.Publisher.loadConformance(Publisher.java:3563)
    at org.hl7.fhir.igtools.publisher.Publisher.createIg(Publisher.java:826)
    at org.hl7.fhir.igtools.publisher.Publisher.execute(Publisher.java:688)
    at org.hl7.fhir.igtools.publisher.Publisher.main(Publisher.java:7310)
Caused by: org.hl7.fhir.exceptions.FHIRException: Unable to generate snapshot for http://hl7.org/fhir/sushi-test/StructureDefinition/sample-observation in /Users/cmoesel/dev/fhir/sushi/build/input/profiles/structuredefinition-sample-observation
    at org.hl7.fhir.igtools.publisher.Publisher.generateSnapshot(Publisher.java:4234)
    at org.hl7.fhir.igtools.publisher.Publisher.generateSnapshots(Publisher.java:4179)
    ... 4 more
Caused by: java.lang.IndexOutOfBoundsException: Index: 0, Size: 0
    at java.util.ArrayList.rangeCheck(ArrayList.java:657)
    at java.util.ArrayList.get(ArrayList.java:433)
    at org.hl7.fhir.r5.conformance.ProfileUtilities.processPaths(ProfileUtilities.java:878)
    at org.hl7.fhir.r5.conformance.ProfileUtilities.generateSnapshot(ProfileUtilities.java:540)
    at org.hl7.fhir.igtools.publisher.Publisher.generateSnapshot(Publisher.java:4232)
    ... 5 more

Chris Moesel (May 18 2020 at 20:22):

If I add empty Observation and Observation.value[x] elements to the differential, then the publisher is happy.

Perhaps SUSHI should just play it safe and always avoid creating sparse differentials. While it does create some more "noise" in the profile, it's not technically incorrect and seems to be more publisher-friendly.

Rob Hausam (May 18 2020 at 20:39):

I think that's what is needed now, and is always safe.

Jose Costa Teixeira (May 18 2020 at 21:13):

Chris Moesel said:

Perhaps SUSHI should just play it safe and always avoid creating sparse differentials. While it does create some more "noise" in the profile, it's not technically incorrect and seems to be more publisher-friendly.

Agree, sounds better.

Chris Moesel (May 18 2020 at 21:15):

IIRC, the first versions of SUSHI actually did this. We took it out when we found that the publisher seemed to be supporting sparse differentials just fine. Oh well!

Jose Costa Teixeira (May 18 2020 at 21:18):

I think this will be few lines of code and a few lines in the resulting json, but much less lines of questions and complaints in Zulip

Grahame Grieve (May 19 2020 at 07:47):

ok. I fixed that. Wasn't really anything to do with sparse per se. In the next release

Grahame Grieve (May 19 2020 at 07:48):

@Etienne Cantineau I don't think this is related to your problem. It's still on my list

Etienne Cantineau (May 19 2020 at 08:34):

Ok thank you

Grahame Grieve (May 20 2020 at 05:10):

fixed next release

Chris Moesel (May 27 2020 at 18:06):

Based on the conversation and recommendations in this thread, the most recent version of SUSHI added intermediate differential elements to avoid "sparse differentials". We were under the impression that doing such a thing was harmless, but it seems that may not be the case -- as @Saul Kravitz has found a case where the not-sparse differential causes an IG Publisher error (but if you change it to a sparse differential, the error goes away). See: https://chat.fhir.org/#narrow/stream/179252-IG-creation/topic/Error.20in.20snapshot.20generation

Jose Costa Teixeira (May 27 2020 at 18:08):

if Grahame says this is not related to the sparse differentials, do you want to try and reverse this?

Chris Moesel (May 27 2020 at 18:12):

Maybe? But as far as I know, having non-sparse differentials should be completely valid too; so we shouldn't need to back it out. I guess I'd defer to @Grahame Grieve regarding whether SUSHI should actively avoid producing sparse differentials, or intentionally allow them (by only including elements that truly changed or introduce slices).

Jose Costa Teixeira (May 27 2020 at 18:20):

(or we figure out why the other error is happening which would be safer)

Grahame Grieve (May 27 2020 at 20:09):

I think that in general, sushi should avoid trying to be smart here - it should insert or remove anything it doesn't get told to do. As much as I can tell, sparse or not is ok; in this case, there was a bug that sparse triggered, but it was going to trigger eventually. I'll have to debug the other case to figure out what the problem is

Chris Moesel (May 27 2020 at 20:52):

I think that in general, sushi should avoid trying to be smart here - it should insert or remove anything it doesn't get told to do.

OK. So I think I need to interpret that as "don't try to make differentials unsparse" -- keep them sparse if that's the way authors define the profile. This assumes that IG Publisher _should_ always handle sparse differentials fine. And if it doesn't, that's a bug. Yes?

Rob Hausam (May 27 2020 at 20:56):

Or that the authors shouldn't/can't make the differentials sparse? It would be good to know which way it is supposed to be.

Chris Moesel (May 27 2020 at 20:59):

Right now, FSH doesn't provide a way that an author could say "put this element in the differential even though it actually has no differences in it".

Grahame Grieve (May 28 2020 at 00:21):

it's a bug if a sparse differential doesn't work

Last updated: Apr 12 2022 at 19:14 UTC