Stream: IG creation
Topic: Forge propagating normative flags
Lloyd McKenzie (Apr 09 2020 at 16:49):
Forge is now propagating the 'structuredefinition-normative-version' into derived profiles (which is triggering errors because of how the extension is defined). I understand the errors will go away eventually when/if we push a technical correction to R4. However, I want to focus on a different issue:
Are these extensions appropriate to propagate? More specifically, what happens when we start taking profiles normative, but want to note that certain elements (even certain elements within particular slices) are not normative? How will we do that? Should we be asserting the model within which the normative assertion is being made? That's the only convention I can think of given that there's no real mechanism to keep extensions from propagating through derived models
Grahame Grieve (Apr 09 2020 at 20:25):
well, isn't it a claim that the profile itself is normative?
Lloyd McKenzie (Apr 09 2020 at 20:51):
They show up on elements, not on the overall profile. And they get inherited in the derivation process
Grahame Grieve (Apr 09 2020 at 20:53):
so are they claiming the element itself is normative, or that this element definition profile is normative?
Lloyd McKenzie (Apr 09 2020 at 20:53):
You certainly don't want the fact an element is normative in a resource to mark it as normative in profiles
Frank Oemig (Apr 10 2020 at 06:33):
When a profile goes normative, it is statically bound to the used resources?!
Lloyd McKenzie (Apr 10 2020 at 14:12):
I'm not sure what you mean Frank. A profile can't go normative until the underlying resource has gone normative. A profile is always tied to exactly one resource.
Grahame Grieve (Apr 11 2020 at 07:15):
A profile is always tied to exactly one resource.
not nessarily
Frank Oemig (Apr 19 2020 at 10:49):
@Lloyd McKenzie we have a lot of profiling work, some of which is referencing outdated fhir stuff. But they are declared somehow normative. (Well, not in the HL7 sense, but in their minds.) So, I would say that you can make a profile normative although the underlying resource is not.
I also would say that it is bad practice, but on the other hand in order to make progress and to use fhir we cannot wait until all needed resources are normative.
The problem here in Germany is that the ones who are heavily promoting that they use the newest standard fhir, are not too familiar with all associated details.
Lloyd McKenzie (Apr 19 2020 at 14:01):
There's nothing to stop a designer with authority from mandating whatever they like. That's not the same as 'normative' though. 'Normative' promises that future versions will interoperate with past versions without breaking changes. It doesn't matter who the designer is or what level of authority they have, they can't make that promise if HL7 hasn't made the same promise with respect to the underlying resource definitions. 'Normative' is absolutely not a prerequisite for widespread implementation though (as can be clearly seen with FHIR's rate of adoption pretty much everywhere).
All implementers should certainly encourage designers/regulators to be familiar with the FHIR Maturity Model and adhere to its spirit - trying to lock things down without adequate implementation experience inevitably creates problems. However, we can't force it on anyone.
David Pyke (Apr 19 2020 at 15:10):
Grahame Grieve said:
A profile is always tied to exactly one resource.
not nessarily
Okay, I'll bite. How can a profile have multiple resources?
Lloyd McKenzie (Apr 19 2020 at 15:19):
Profiles can navigate down into contained resources
David Pyke (Apr 19 2020 at 15:29):
Oh, okay, that one I knew.
Ward Weistra (May 06 2020 at 08:58):
@Lloyd McKenzie Should we have a way to indicate that some extensions should not be inherited?
Most extensions should probably be inherited, except for some extensions on profiles. Like the extensions http://hl7.org/fhir/StructureDefinition/structuredefinition-standards-status and http://hl7.org/fhir/StructureDefinition/structuredefinition-normative-version of Element should probably not be inherited by every type of element. Thus @Abel Enthoven suggested perhaps adding an extension with 'do not inherit' on those.
Lloyd McKenzie (May 06 2020 at 15:17):
That's the question I'm asking. I don't know we've landed on an answer - @Grahame Grieve ?
Grahame Grieve (May 06 2020 at 19:56):
well, maybe. I think 'do not inherit' is too simplistic a notion. It's kind of like is this data or metadata, and if it's metadata, what kind of metadata is it?
Lloyd McKenzie (May 06 2020 at 20:38):
I see two alternatives - either we say that certain extensions don't propagate, or we need to require that extensions on structure definitions recognize that they will propagate.
Lloyd McKenzie (May 06 2020 at 20:39):
(Which in this case, would mean the declaration of normative would also have to specify what canonical it was normative as part of.)
Abel Enthoven (May 07 2020 at 07:46):
I like your solution of always propagating Lloyd, because it does not rely on tools to understand any extra meta info communicated in extensions. Would require changing the definition of the mentioned extensions' definitions (and every instance of them) then, right?
Lloyd McKenzie (May 07 2020 at 14:58):
Correct
Ward Weistra (May 20 2020 at 14:41):
Created FHIR#27535 for this.
Last updated: Apr 12 2022 at 19:14 UTC
