FHIR Chat · Forge added extension explicit-type-name · tooling

Stream: tooling

Topic: Forge added extension explicit-type-name

Richard Townley-O'Neill (May 20 2020 at 07:25):

When I use Forge 24.2 for R4 to profile Composition, if I change the cardinality of Composition.section the extension http://hl7.org/fhir/StructureDefinition/structuredefinition-explicit-type-name is added to the differential, even though this is inherited from Composition.

<element id="Composition.section">
    <extension url="http://hl7.org/fhir/StructureDefinition/structuredefinition-explicit-type-name">
        <valueString value="Section"/>
    </extension>
    <path value="Composition.section"/>
    <min value="1"/>
</element>

Richard Townley-O'Neill (May 20 2020 at 07:27):

The igPublisher strips this addition out.
I think that this addition to differential is invalid as the element is in the resource from which it inherits.
Is that right?

Grahame Grieve (May 20 2020 at 08:00):

yes this is one of those extensions that should not be inherited

Ward Weistra (May 20 2020 at 14:26):

Thanks @Richard Townley-O'Neill @Grahame Grieve, we'll add this to the hardcoded list of extensions not to be inherited with the next release. And include it in the discussion how to generalize that information.

Ward Weistra (May 20 2020 at 14:49):

Added this to FHIR#27535.

Chris Moesel (May 20 2020 at 17:54):

@Ward Weistra -- this affects SUSHI as well. Is the list in the link for 27535 complete (as far as we know)? I think right now, SUSHI is just wiping out all extensions on the base resource, but using a black list is probably more correct.

Ward Weistra (May 20 2020 at 18:20):

@Chris Moesel Yes, this whole shebang started when a customer pointed out their extension on a datatype (if I remember correctly) was being wiped out by Forge, so we changed that practice.

And we seem to continue to discover more so far, so I wouldn't expect it to be complete yet :slight_smile:

Chris Moesel (Jul 14 2020 at 21:13):

I'm implementing this in SUSHI and ran into a few more extensions I'm not sure should be inherited. For example:

• http://hl7.org/fhir/StructureDefinition/structuredefinition-fmm : Is it right for a profile to inherit the same maturity as the resource it is derived from? A comment in the extension says "Though this is defined for resources, it can be used for any artifact." I'd expect a profile's FMM should never be higher than the resource it is derived from, but it might be lower.
• http://hl7.org/fhir/StructureDefinition/structuredefinition-wg: I think it might be fairly common for a profile to be maintained by a different WG then the resource it is derived from, right?

What do you think?

Grahame Grieve (Jul 15 2020 at 00:53):

neither of these should be inherited.

Grahame Grieve (Jul 15 2020 at 00:53):

we really haven't figured out how to handle these properly. :-(

Chris Moesel (Jul 15 2020 at 13:43):

Thanks, Grahame. @Ward Weistra -- I mentioned these in a comment on FHIR#27535, but can you add them in the body of the issue?

Ward Weistra (Jul 23 2020 at 08:15):

Doesn't seem like I'm allowed to @Chris Moesel, probably because it's already triaged or something.

Chris Moesel (Jul 24 2020 at 12:38):

Ah, OK. Well then, I guess we'll just use comments to add more applicable extensions as we find them.

Ward Weistra (Jul 27 2020 at 08:01):

@Grahame Grieve @Chris Moesel How about http://hl7.org/fhir/extension-elementdefinition-translatable.html, should that be added to the no-inherit list? We seem to have customers unhappy with Forge adding it since recently.

Patrick Werner (Jul 27 2020 at 09:04):

i think it should be also added. (being the unhappy customer :slight_smile: )

Patrick Werner (Jul 27 2020 at 09:07):

@Ward Weistra I was wondering why Forge adds these anyway. They are part of the base resource, when i don't change anything on an item Forge still produces a diff entry only containing some (e.g. translatable) extension entries.
This never should appear in a diff, or am i missing smth?

Ward Weistra (Jul 27 2020 at 09:29):

@Patrick Werner I believe that's because otherwise there is no way to make the distinction between making no changes to the extensions and deliberately removing all extensions that a parent has. Right @Abel Enthoven?

Ward Weistra (Jul 27 2020 at 09:29):

(And I hope you're generally a happy customer :wink:)

Patrick Werner (Jul 27 2020 at 09:34):

ah! that makes sense. Ok then type name and translatable just should be on the "negative-list" if inhereting.

Abel Enthoven (Jul 27 2020 at 11:07):

hi @Ward Weistra and @Patrick Werner , yeah that's right. There's no distinction possible yet based on the definition, so if we want it not-inherited we should add it to the list

Grahame Grieve (Jul 27 2020 at 11:16):

and I'm not sure

Patrick Werner (Jul 27 2020 at 11:24):

about what?

Chris Moesel (Jul 27 2020 at 13:18):

Ward Weistra said:

I believe that's because otherwise there is no way to make the distinction between making no changes to the extensions and deliberately removing all extensions that a parent has.

@Ward Weistra -- Are you suggesting that if an element in a differential does not repeat an extension from the parent profile, that should be interpreted as a request to remove the extension from the snapshot? If so, that's new to me; I assumed if you explicitly didn't want an extension, you had to set max to 0 (although that would be prohibiting it, which is certainly different than just choosing not to explicitly list it).

Abel Enthoven (Jul 27 2020 at 14:02):

hi @Chris Moesel the extensions you are talking about (correct me if I'm wrong) are really extension definitions. If a profile of a Patient has an extension definition, then you can restrain that definition in a derived Patient profile (e.g. set it to 0..0). But like a Patient, StructureDefinition is a Resource too and thus can have it's own extensions. Those extensions would not be visible in Forge, for they are not definitions but actual extensions and they apply to the metamodel (the StructureDefinition itself). Any extension definitions you define on a Patient are in fact ElementDefinitions in a StructureDefinition and end up in the differential. Any extensions (instances of an extension) on StructureDefinition can occur on every possible element within the definition. This distinction actually throws me off too all the time :)

Patrick Werner (Jul 27 2020 at 15:13):

@Ward Weistra right now i'm deleting loads of elements only containing the translatable extension to get a decent rendering in Simplifer :-(

Patrick Werner (Jul 27 2020 at 15:35):

And everytime i change a minor thing in a profile, the StrucDef explodes again. :bomb: :angry_devil:

Ward Weistra (Jul 27 2020 at 15:36):

@Patrick Werner I'll discuss the best solution with @Abel Enthoven tomorrow!

Patrick Werner (Jul 27 2020 at 15:36):

thanks

Ward Weistra (Jul 28 2020 at 09:56):

OK, our plan is now that we will change our Forge logic to no longer repeat untouched extension instances in the structure definition (not to be confused with element definitions defining extensions in a profile). This will mean:

• Translatable, Normative-version, etc. will no longer be in the differential if not defined in that profile
• The .NET snapshot generator will make sure these extensions are being treated as additive. @Grahame Grieve can you comment on how the Java snapshot generator treats them?
• The extensions which we have until now discovered which should not be inherited (like Normative-version) will still wrongly end up in your snapshot. This will need a fix in FHIR for FHIR#27535.

Grahame Grieve (Jul 28 2020 at 10:14):

I don't believe that the java snapshot generator does anything special for any of them. I've been waiting for this discussion to go to FHIR-I before doing anything about it

Chris Moesel (Aug 26 2020 at 12:45):

Another discussion revealed another extension that should not be inherited: http://hl7.org/fhir/StructureDefinition/structuredefinition-summary. I'll add it to the jira issue.

Chris Moesel (Aug 26 2020 at 12:45):

I also noticed that @Patrick Werner commented on the Jira issue suggesting that http://hl7.org/fhir/StructureDefinition/elementdefinition-translatable also should not be inherited.

Patrick Werner (Aug 26 2020 at 12:46):

yes. Causing a lot of troubles in Forge at the moment

Chris Moesel (Aug 26 2020 at 12:47):

This is starting to feel like wack-a-mole. It may be worth going through the extension registry and trying to proactively identify extensions that should not be inherited. Even if the solution recommended in the Jira issue is implemented, that won't help w/ older versions of FHIR.

Grahame Grieve (Aug 26 2020 at 20:18):

it feels like we're going to have an extension on the extension definition here

Ward Weistra (Aug 27 2020 at 14:48):

Patrick Werner said:

yes. Causing a lot of troubles in Forge at the moment

Please test again with the just released Forge 25.1 if this resolves the element extension inheritance issues!
It does in my tests: https://simplifier.net/ForgeLetsBuild/HospitalXPatientNZ/$diff/2/4/Original

Ewout Kramer (Sep 07 2020 at 09:02):

Grahame Grieve said:

it feels like we're going to have an extension on the extension definition here

This is the only real solution - the author of the extension has to indicate whether this extension propagates. It's well-known territory, because exactly the same features exists on attributes in .NET (https://docs.microsoft.com/en-us/dotnet/standard/attributes/writing-custom-attributes#inherited-property) and Java annotations (https://docs.oracle.com/javase/tutorial/java/annotations/predefined.html, see @Inherited - which is an annotation on an annotation indeed)

Grahame Grieve (Sep 07 2020 at 09:34):

do you want to create a task and take it to FHIR-I?

but that's a longer term solution, I think, because it requires technical corrections and I have no energy for that right now given everything going on

Grahame Grieve (Sep 07 2020 at 09:34):

so we'll have to settle for a list in the short term

Ewout Kramer (Sep 07 2020 at 09:38):

agree.

Ewout Kramer (Sep 07 2020 at 11:22):

https://jira.hl7.org/browse/FHIR-28441

Ward Weistra (Sep 07 2020 at 13:16):

I guess that the solution for (or duplicate of) ticket FHIR#27535 then.

Ewout Kramer (Sep 07 2020 at 13:24):

yes, sorry, Ward, that's almost a duplicate (it mentions using extensions as the "programmatic" way).

Patrick Werner (Sep 08 2020 at 08:21):

thank you for resolving this issue!

Last updated: Apr 12 2022 at 19:14 UTC