FHIR Chat · Odd IG broken link build issue with choice data elements · IG creation

Stream: IG creation

Topic: Odd IG broken link build issue with choice data elements


view this post on Zulip Corey Spears (Sep 27 2021 at 18:39):

I am getting broken links to the elements details page for one of my extension structure definitions. The errors can be found here: http://build.fhir.org/ig/HL7/davinci-pdex-formulary/branches/stu2-draft/qa.html#internal

The error says the link (StructureDefinition-usdf-QuantityLimitDetail-extension-definitions.html#Extension.extension:DaysSupply.valueTiming.repeat.boundsDuration) is not valid. Sure enough it isn't (the page is, but the named anchor is not). For some reason, the details page has links with the choice "element[x]" in the anchor name (Extension.extension:DaysSupply.valueTiming.repeat.bounds[x]:boundsDuration), but the link (Extension.extension:DaysSupply.valueTiming.repeat.boundsDuration) does not.

For some reason the choice datatype is appearing in the anchor name for "bounds[x]", yet oddly does not happen with the higher level choice element of value (which the full name with data type is valueTiming).

I am at a loss and how no idea what might be the problem as those links and anchors are created by the IG Publisher.

view this post on Zulip Lloyd McKenzie (Sep 27 2021 at 18:43):

It sounds like the differential is using the wrong path - it should be bounds[x] with a slice name, not boundsDuration.

view this post on Zulip Corey Spears (Sep 27 2021 at 18:46):

I am not doing anything directly with differential. Where might I look to fix the issue?

view this post on Zulip Lloyd McKenzie (Sep 27 2021 at 21:27):

If you're authoring a profile, then the differential is being produced. It could be that this is a FSH-introduced thing?

view this post on Zulip Chris Moesel (Nov 09 2021 at 20:05):

I'm just looking at this again, and what's interesting is that if you look at the working anchor that Corey noted above, Extension.extension:DaysSupply.valueTiming.repeat.bounds[x]:boundsDuration, it does support the choice type renaming for the value[x] portion (e.g., valueTiming), but does not support it for the bounds[x] portion. This is inconsistent. If using boundsDuration is truly unsupported, then one would expect that valueTime would also be unsupported for the same reason.

Looking at the HTML source, there are quite a few variations of the supported anchors. It seems to me that it is just missing the one variation that the IG Publisher happens to be using as a link elsewhere in the IG.
image.png

view this post on Zulip Chris Moesel (Nov 09 2021 at 20:09):

@Grahame Grieve -- Corey is trying to get this IG approved by the Pharmacy WG, but these broken links are blocking approval. We have a whole separate thread about whether choice type renaming should be allowed, but at the moment, the most pressing issue is getting this link error fixed.

On the SUSHI side, the only way we can fix it is by disabling choice type renaming entirely -- but this affects many IGs, so I prefer not to do it until the choice type renaming thread is resolved.

view this post on Zulip Chris Moesel (Nov 09 2021 at 20:11):

Is it possible/easy to fix this link issue on on the IG Publisher side by adding the missing anchors or changing the link generation to use the normalized (non-renamed) id form?

view this post on Zulip Grahame Grieve (Nov 10 2021 at 23:32):

this is the correct form:

view this post on Zulip Grahame Grieve (Nov 10 2021 at 23:32):

Extension.extension:DaysSupply.value[x]:valueTiming.repeat.bounds[x]:boundsDuration

view this post on Zulip Chris Moesel (Nov 11 2021 at 00:11):

Thanks, @Grahame Grieve. So just to confirm, you are saying that choice type renaming is no longer allowed, and that the spec needs to be fixed to not refer to it, and that all the FHIR core vital signs profiles (and a few more) need to be updated not to use it. Because that is what is implied if Extension.extension:DaysSupply.value[x]:valueTiming.repeat.bounds[x]:boundsDuration is the only correct form.

view this post on Zulip Grahame Grieve (Nov 11 2021 at 00:14):

I didn't say 'only'

view this post on Zulip Grahame Grieve (Nov 11 2021 at 00:14):

I'm still looking into it

view this post on Zulip Grahame Grieve (Nov 11 2021 at 00:14):

but the tool covers multiple versions, so it's trying to cater for all the styles in the generated anchors (and failing).

view this post on Zulip Chris Moesel (Nov 11 2021 at 00:27):

OK, so I think you're just saying that, at this point, the best way forward to fix this particular issue for this particular IG is just to use the form you specified above. Got it. I'll work w/ Corey to try to implement a workaround to make that happen.

view this post on Zulip Grahame Grieve (Nov 11 2021 at 00:29):

hey no. I'm redoing the generation of anchors. The list it's generating misses things it needs to generate and generates things it shouldn't

view this post on Zulip Grahame Grieve (Nov 11 2021 at 00:32):

then I'll see if I can write up a general answer as to what is correct

view this post on Zulip Chris Moesel (Nov 11 2021 at 00:33):

Ah. OK. I know you are super busy. I just figured this wasn't going to make the cut. Thank you. If it ends up that you can't get to it, we can still try to implement a workaround on our end.

view this post on Zulip Grahame Grieve (Nov 11 2021 at 00:33):

I'm not sure you can work around it

view this post on Zulip Chris Moesel (Nov 11 2021 at 00:35):

I think we can work around it if we can force our ids/paths in the differential to follow the long form you specified above. I believe that was one of the anchors that's already working. Unless I'm misunderstanding the real bug.

view this post on Zulip Grahame Grieve (Nov 11 2021 at 01:59):

well, it will be fixed next release.

view this post on Zulip Grahame Grieve (Nov 11 2021 at 02:02):

here's the generated anchors now:

view this post on Zulip Grahame Grieve (Nov 11 2021 at 02:02):

image.png

view this post on Zulip Grahame Grieve (Nov 11 2021 at 02:03):

however, in general, this is the applicable wording in the stadard:

view this post on Zulip Grahame Grieve (Nov 11 2021 at 02:03):

For type choice elements, the id reflects the type slice. e.g. For path = Patient.deceasedBoolean, the id is Patient.deceased[x]:deceasedBoolean

view this post on Zulip Grahame Grieve (Nov 11 2021 at 02:04):

so you'll see that one of the paths in the list above is that one

view this post on Zulip Grahame Grieve (Nov 11 2021 at 02:07):

and that implies that you should change to the long form I specified above, since it's that form

view this post on Zulip Grahame Grieve (Nov 11 2021 at 02:08):

the anchors are generated for other forms for backwards compatibility etc, and so you can continue to get away with the old forms, but as far as I'm concerned, the correct form is as specified in the specification, and that's what's guaranteed to work and be produced

view this post on Zulip Corey Spears (Nov 12 2021 at 07:07):

The build of my IG no longer has issues. Thanks @Grahame Grieve . :+1:

view this post on Zulip Chris Moesel (Nov 12 2021 at 19:26):

Yes, thank you so much, @Grahame Grieve!

We will follow through on your guidance and update SUSHI so that it always uses the full slice syntax in choice ids when creating the differential (e.g., Observation.value[x]:valueQuantity rather than just Observation.valueQuantity). We'll also avoid things like Observation.valueQuantity in the ElementDefinition path, and prefer simply Observation.value[x].

view this post on Zulip Eric Haas (Nov 15 2021 at 16:12):

Ok so this means I should update US Core too right?

view this post on Zulip Chris Moesel (Nov 15 2021 at 16:28):

@Eric Haas -- I thought that FHIR-33233 had already established that US Core would change the ids anyway.

view this post on Zulip Eric Haas (Nov 15 2021 at 16:38):

@Chris Moesel yes but then this whole string started about what the right answer was or even whether it was wrong. So I will go ahead if it has been decided that the shortcut way is bad.


Last updated: Apr 12 2022 at 19:14 UTC