FHIR Chat · Hard coding an Extension: messageheader-response-request · implementers

Stream: implementers

Topic: Hard coding an Extension: messageheader-response-request


view this post on Zulip John George (Nov 30 2021 at 16:42):

Hi All, in the UK we would like to hard code the HL7 Common Extension: messageheader-response-request <http://hl7.org/fhir/extension-messageheader-response-request.html> to the UKCoreMessageHeader profile. However, we can't make this optional as this common HL7 extension has a cardinality of 1..1. Incidentally, our profile tool (Forge) adheres to this only allowing that mandatory cardinality (1..1) for this extension. I can see two ways to deal with this:

  1. Not to hard code the extension in the UKCoreMessageHeader profile, but instead to provide guidance to use it if necessary in the Extension Library of our implementation guide.

  2. To create a clone of this HL7 Common Extension, so we could make this optional and hard code this into our profile. Though someone might argue why we have done this when there is a common HL7 extension, our response could be that we needed this to be optional in our profile. I'm not keen on this route, as it feels like unnecessary duplication.

Can anyone else think of any other options when dealing with a mandatory common HL7 extension, that one wants to make optional for their profile? I'd be interested to know why this HL7 Common Extension: messageheader-response-request was made mandatory, in the first place, considering the majority of HL7 Common Extensions are optional. I'm sure there were good reasons, I'm just curious to understand the thinking behind this.

view this post on Zulip Lloyd McKenzie (Nov 30 2021 at 17:00):

Two possibilities:

  • it was done by accident (in which case, a change request can fix it and we might even be able to deal with it in R4B)
  • it was believed that if you're going to support the extension, then it needs to be present on everything

I'm not sure which is the case. @Grahame Grieve?

view this post on Zulip Vassil Peytchev (Nov 30 2021 at 17:48):

The language extension is also with cardinality of 1..1 - does it pose the same problem? What is the meaning of having an extension with cardinality 1..1?

view this post on Zulip Josh Mandel (Nov 30 2021 at 18:00):

And more generally: what does it mean for an extension to ever set its minimum cardinality higher than zero? (Obviously a profile can define slices where an extension is required...)

view this post on Zulip Grahame Grieve (Nov 30 2021 at 18:22):

definitely an oversight in this case

view this post on Zulip Josh Mandel (Nov 30 2021 at 18:32):

Should we have a general check that min cardinality on core extensions is always 0 @Grahame Grieve ?

view this post on Zulip John George (Nov 30 2021 at 18:41):

@Lloyd McKenzie @Vassil Peytchev @Josh Mandel and @Grahame Grieve thanks for your responses. I'd be in favour of the minimum cardinality on all core extensions always being zero.

view this post on Zulip Josh Mandel (Nov 30 2021 at 18:57):

Submitted FHIR-34399

view this post on Zulip Lloyd McKenzie (Nov 30 2021 at 19:18):

There are situations where it's actually legitimate to have it be 1, but they'd be rare. I'd make it a warning rather than an error.

view this post on Zulip Josh Mandel (Nov 30 2021 at 20:58):

I will update the issue if you can help me understand what the situations are?

view this post on Zulip Lloyd McKenzie (Nov 30 2021 at 21:51):

I don't know we've run across any examples where we wanted to. The gist is "if you're going to use this in a profile, then it always needs to be present".

view this post on Zulip Josh Mandel (Dec 01 2021 at 00:22):

But min cardinality doesn't say anything about "in a profile". It's context-free, other than the FHIRpath saying where the extension is applicable.


Last updated: Apr 12 2022 at 19:14 UTC