Stream: IG creation
Topic: Constraining an element in a profile but not MustSupport
Jean Duteau (May 05 2021 at 04:49):
In all of my profiles, for any element that I am constraining (or even not constraining but intending to use) I mark it as MustSupport. I've always wondered what does it mean in a non-abstract profile to constrain an element from the base resource (or from a dependent IG) and not mark it as MustSupport? Does it make sense to say "if you are going to use this element in the context of this guide, you must use this binding or it can't repeat, or xxx"? I'm not denying that it might make sense, but I can't think of a case where it would, so I'd love to hear from others that have a good case for doing this (constraining an element but not marking it as MS).
Lloyd McKenzie (May 05 2021 at 05:05):
It’d be super rare. You’d be saying “The value of this doesn’t matter for the use case, but it’d be erroneous if this tighter constraint weren’t met.
Sarah Gaunt (May 05 2021 at 07:12):
It's almost like we need an opt out rather than an opt in for Must Support because you basically just have to add it everywhere you constrain anything... (Kidding, kind of.)
Grahame Grieve (May 05 2021 at 07:58):
fixed value stuff - not relevant to the use case - that would be contrained but not must-support
Eric Haas (May 05 2021 at 14:31):
I think it is as meaningful as a preferred binding. You are signaling that it would be nice to have this element but a lot of implementers are going to ignore it.
Lloyd McKenzie (May 05 2021 at 15:48):
Most of the times you're not going to constrain stuff you don't care about. But in some cases you might. Simple example: constraining Patient.deceased[x] to be max=0 or have an optional fixed value of deceasedBoolean=false. It's not going to be mustSupport. You don't need systems to support deceased or store or display or do anything with it, but you DO want to say that it's non-conformant to send a patient that is deceased.
Jean Duteau (May 05 2021 at 15:49):
Grahame Grieve said:
fixed value stuff - not relevant to the use case - that would be contrained but not must-support
Hmm, that makes sense but I think I have still been setting those to must-support. Good to think about going forward.
Jean Duteau (May 05 2021 at 15:51):
Eric Haas said:
I think it is as meaningful as a preferred binding. You are signaling that it would be nice to have this element but a lot of implementers are going to ignore it.
I've never had a profile where I needed to say "it would be nice to send this element and if you do, send it like this" but I could potentially see that.
Jean Duteau (May 05 2021 at 15:51):
Lloyd McKenzie said:
Most of the times you're not going to constrain stuff you don't care about. But in some cases you might. Simple example: constraining Patient.deceased[x] to be max=0 or have an optional fixed value of deceasedBoolean=false. It's not going to be mustSupport. You don't need systems to support deceased or store or display or do anything with it, but you DO want to say that it's non-conformant to send a patient that is deceased.
Right, constraining something out would obviously not be must-support.
Lloyd McKenzie (May 05 2021 at 18:29):
Setting a fixed value can too. I have cases where I set Task.intent to a fixed value - and don't make it mustSupport - because mustSupport says "must display, allow data capture and allow storage" - and there's no expectation to do any of those things.
Last updated: Apr 12 2022 at 19:14 UTC
