FHIR Chat · Bad links on Detailed Description tab

Stream: IG creation

Topic: Bad links on Detailed Description tab

Mark Kramer (Jan 22 2020 at 22:05):

I am getting a large number of errors because of bad links on the Profile "Detailed Description" pages. They refer to anchors not on the page. Is it possibly something I'm doing? pasted image

Lloyd McKenzie (Jan 22 2020 at 23:24):

Typically it's caused by snapshot generation issues

Mark Kramer (Jan 23 2020 at 00:09):

The StructureDefinition input to the IG Pub has this: "comment": "For a discussion on the ways Observations can be assembled in groups together see [Notes](observation.html#notes) below." So, somewhere in the publication process the wrong root URL was added. Is this the fault of the IGP, or a bad configuration in the IG json file, perhaps?

Lloyd McKenzie (Jan 23 2020 at 00:19):

That's something the publisher should be fixing as part of the publication process. Is this checked in somewhere?

Mark Kramer (Jan 23 2020 at 12:27):

Yes, https://github.com/standardhealth/fsh-mcode.

Lloyd McKenzie (Jan 23 2020 at 13:17):

@Grahame Grieve

Chris Moesel (Jan 23 2020 at 13:41):

When we create profiles, we start by cloning the base resource and then constraining it. Maybe we should be removing the "comment" field since it's really a comment about the base resource (and not necessarily the profile)? Perhaps the same goes for "description" and other fields? Clearing "comment" when we create a profile would fix at least this one specific instance noted above.

Jose Costa Teixeira (Jan 23 2020 at 13:44):

My opinion: I'd start with that, yes. If this part of the cloning brings this issue, we should remove it.

Jose Costa Teixeira (Jan 23 2020 at 13:45):

Generally, I'd be in favour of not keeping anything from the cloning that we do not need or that can cause issues.

Jose Costa Teixeira (Jan 23 2020 at 13:46):

that's 2 cents. :)

Chris Moesel (Jan 23 2020 at 13:49):

I'll make a list of the properties that we may want to consider clearing when we clone a resource for the purpose of profiling it. Then we can discuss.

Jose Costa Teixeira (Jan 23 2020 at 13:51):

Blacklist? Why not whitelist?

Chris Moesel (Jan 23 2020 at 14:01):

Programmatically, we are literally cloning the JSON. So from that standpoint, we are clearing the things we don't want. I suppose we could create a blank SD and then clone in the things we do want from the original SD. I guess after we have a better understanding of what we keep vs what we toss the best approach might be more clear.

Chris Moesel (Jan 23 2020 at 14:03):

But the overall approach w/ profiling (for SUSHI) is to clone all the snapshot elements from the parent SD, then to apply constraints on top of them (making it easier to track incompatible/invalid constraints) -- then we programatically compare the new snapshots to the olds snapshots to determine the differentials. (More or less...)

Jose Costa Teixeira (Jan 23 2020 at 14:07):

I did not mean change the code to a new approach. I meant that as we make that list, we can consider everything to be a candidate for removal until proven useful. All suspects until proven innocent.

Jose Costa Teixeira (Jan 23 2020 at 14:08):

(but uit was just an idea, the net result will be the same, and I do not know the practical impact of implementing in a different way, sorry if it was distracting)

Mark Kramer (Jan 23 2020 at 14:23):

I would be super, super happy if we would eliminate my "favorite" text repeated 20 times in every StructureDefinition: "There can be no stigma associated with the use of extensions by any application, project, or standard - regardless of the institution or jurisdiction that uses or defines the extensions. The use of extensions is what allows the FHIR specification to retain a core level of simplicity for everyone."

Jose Costa Teixeira (Jan 23 2020 at 14:38):

Well, that is in the comment field for extension, so depending on how this is implemented, you can get indeed rid of that as soon as we do not clone the .comment

Mark Kramer (Jan 23 2020 at 14:40):

I think the issue is diffs -- any change in an element would need to be reported as a diff.

Jose Costa Teixeira (Jan 23 2020 at 14:49):

you mean conformance-wise, we should not change the content of .comment?
Otherwise I don't see an issue - we just have to delete all fields called "comment" that are descendants of the structuredef.

Jose Costa Teixeira (Jan 23 2020 at 14:53):

Removing comments should be in profiling, not in code.
So, you may want to profile the structuredefinition-extension to have an extension that has no "no stigma" in it
a "structuredefinition-extension-no-no-stigma" :)

Jose Costa Teixeira (Jan 23 2020 at 14:56):

@Chris Moesel do you support recursive changes?
Does FSH support that?
can we say "all descendants called "comment" will have this value"?

Mark Kramer (Jan 23 2020 at 14:58):

Not (yet) supported in Shorthand. Never occurred to me that would be useful.

Chris Moesel (Jan 23 2020 at 15:01):

No, we don't support recursive changes. And regarding diffs, it depends on where we're making the change.

If we change a top-level resource metadata attribute (not in snapshot elements), then there is no effect on diff
If we change something in a snapshot element, technically I think it is supposed to result in a diff. So removing comments from snapshot elements might require diffs, which just starts to get a little noisy.
@Lloyd McKenzie -- it's been a while since I asked. Are there any fields in ElementDefinition that we can change or remove without requiring it to be reflected in the differential?

Lloyd McKenzie (Jan 23 2020 at 17:04):

Differential must reflect all changes. Snapshot gets generated from the differential. Even if you provide a snapshot, many tools will wipe it and re-generate.

Lloyd McKenzie (Jan 23 2020 at 17:05):

It's totally fine to refine usage notes to reflect the constrained context of a profile, but I'm not a fan of wiping all comments "just because" and it also shouldn't be necessary to wipe comments because they have links that don't resolve properly.

David Hay (Jan 23 2020 at 17:17):

When we create profiles, we start by cloning the base resource and then constraining it.

Would be interesting to know if that's the approach that Forge takes - @Ward Weistra ? (BTW - is Michel Rutten still around?

Grahame Grieve (Jan 23 2020 at 19:46):

The link should resolve. I thought I sorted this months ago. I’ll look later today

Chris Moesel (Jan 24 2020 at 03:40):

It sounds like maybe not everyone is a fan of wiping some of the high-level metadata from the resource when creating a derived profile. Before I knew this, however, I put together a proposed approach toward what would get wiped and what we would keep. Comments welcome:

id - overwrite w/ new id
meta - clear
implicitRules - clear
language - clear
text - clear
contained - clear
extension - clear (see https://github.com/FHIR/sushi/issues/116)
modifierExtension - clear
url - overwrite w/ new url
identifier - clear
version - overwrite w/ IG version (author can override if maintaining per-profile versions)
name - overwrite w/ new name
title - clear or overwrite w/ new title (if applicable)
status - currently defaults to active but FSH should add (required?) keyword
experimental - clear
date - clear
publisher - clear (or overwrite w/ publisher from config?)
contact - clear (or overwrite w/ contributors from config?)
description - clear or overwrite w/ new description (if applicable)
useContext - clear
jursidiction - clear
purpose - clear
copyright - clear
keyword - clear or keep? Would parent keywords still be applicable to child profiles?
fhirVersion - set to target version (should match anyway)
mapping - keep (assuming mappings are still valid and because removing them would require use to remove mappings from every element, creating tons of diffs)
kind - keep (this should not change)
abstract - keep or set to false. If you set an abstract profile as a parent should you need to explicitly toggle abstractness to false? Or should we default to false?
context - keep (assuming context is still valid for child extensions)
contextInvariant - keep (assuming context is still valid for child extensions)
type - keep (this should not change for profiles or extensions)
baseDefinition - overwrite w/ the parent URL of the new profile/extension
derivation - set to constraint (so far, SUSHI only supports constraints)
snapshot - keep, but elements will obviously be overwritten by constraints
differential - clear, as the differential starts from scratch to reflect changes the profile has made to the parent

Lloyd McKenzie (Jan 24 2020 at 03:55):

When you're creating a new profile, you really shouldn't be starting by copying the original profile at all. You should be setting all of the meta to the appropriate values for what you're creating - so copyright, jurisdiction, etc. shouldn't be clear - they really ought to be populated with what's correct for the artifact you're creating. Also note that there are no defaults in FHIR. You shouldn't ever start with a snapshot.

Chris Moesel (Jan 24 2020 at 13:43):

What I mean by clear is that we clear them before we set them with the appropriate profile-specific metadata. This means that in cases where there is metadata the profile does not specify, it's properly not-specified in the profile rather than inheriting it from the parent.

Grahame Grieve (Jan 24 2020 at 20:07):

I used to actually omit the inherited extension documentation stuff, since I agree that people don't want to see it, but I had to remove that special case logic as part of reconciliation with simplifier

Ward Weistra (Jan 28 2020 at 02:22):

When we create profiles, we start by cloning the base resource and then constraining it.

Would be interesting to know if that's the approach that Forge takes - Ward Weistra ? (BTW - is Michel Rutten still around?

I'll check with @Abel Enthoven! Michel is focusing on other projects right now.
On the 'inherited extension documentation stuff': if we'd define fields like comment as not applicable to derived profiles we can of course change the snapshot logic to exclude them.

Abel Enthoven (Jan 28 2020 at 09:47):

Forge does 'whitelisting' as @Jose Costa Teixeira suggested. The following properties are populated:

type - copied from base
url - initialized with an example URL
status - initialized as 'draft'
fhirVersion - copied from base
kind - copied from base
abstract - initialized as 'false'
baseDefinition - initialized as {base.url}
derivation - initialized as 'constraint'
mapping - copied on user request (via setting)

As to documentation in the elements: Clearing any documentation there would indeed mean those elements all need to be repeated in the differential (if we stick to the current snapshotting strategy). Apart from the huge differentials this may result in, I also think automatically clearing documentation in one of the elements changes the meaning of that element. One could argue the same goes for the general profile documentation, although the chances of a user not wanting to change those are very slim

Chris Moesel (Jan 28 2020 at 14:14):

Thanks, @Abel Enthoven --that is helpful. I think we'll align SUSHI/FSH with this. I had actually just done an initial implementation last night that is extremely close to this, so I should only need to make a few tweaks.

Chris Moesel (Jan 28 2020 at 14:27):

One thing you didn't note was context or contextInvariant. It seems to me that if someone profiles an Extension, it might make sense for the context/contextInvariant to default to that of the base. E.g., if the parent applied to Patient, it seems unlikely that the child would apply to something else (except maybe a profile on Patient). So for SUSHI, we'll probably copy those two from the base.

Grahame Grieve (Jan 28 2020 at 19:20):

if an extension defines an context, a constraint on the extension can't specify a different context

Lloyd McKenzie (Jan 28 2020 at 19:39):

To confirm, if you constrain an existing extension, you can't narrow the context for that constraint?

Grahame Grieve (Jan 28 2020 at 19:43):

you can narrow it. but not change it

Abel Enthoven (Jan 29 2020 at 10:17):

I can confirm that @Chris Moesel , context is also copied

Last updated: Apr 12 2022 at 19:14 UTC

Main menu

FHIR Chat · Bad links on Detailed Description tab · IG creation