Stream: IG creation
Topic: Re-vamping 'mustSupport' view
Lloyd McKenzie (Apr 29 2021 at 16:35):
Soon (hopefully this weekend), I plan to start working on revamping the 'mustSupport' view so that it actually shows what elements an implementer actually needs to worry about - which is more than just stuff flagged as mustSupport. This change will also cause the mustSupport flag to start showing up on that view again because not all elements displayed will be mustSupport. The proposed algorithm is here: https://github.com/HL7/fhir-ig-publisher/issues/147#issuecomment-829391194. Rationale for the changes are as follows:
- If an element is mandatory (min >=1), implementers have to populate it and if it's not mustSupport on receipt, should at least be familiar with what it is (it wouldn't be mandatory if it wasn't important to the semantics)
- if an element is a modifier element, implementers are required to confirm they understand the meaning of the element in order to process the instance. Also, this will call attention to the existence of modifiers that IG authors might want to prohibit
- if an element has been constrained to not repeat or be prohibited entirely, implementers need to know that. They also need to be aware of new invariants beyond the base spec that impact what elements they send, even if those elements aren't mustSupport.
If you have concerns or want to suggest changes to the proposed algorithm, this is a good time to raise them.
Grahame Grieve (Apr 29 2021 at 20:22):
It sounds to me like a different view to 'must-support'. It's more like you're trying to create a view for 'must-know'. And it sounds problematic to me because everything is something you must know at some stage
Lloyd McKenzie (Apr 29 2021 at 20:43):
As an implementer, of an IG, you can totally ignore the non-mustSupport elements - so long as they aren't modifiers and they're not mandatory. The point of the mustSupport view was to expose those things that an implementer needs to worry about. It would make no sense for the templates to expose both views. I can certainly define a distinct widget so the old one is still available if someone wants it, but the 'standard' HL7 profile wouldn't reference it.
John Moehrke (Apr 29 2021 at 21:17):
this is not the same thing as mustSupport... What happened to the efforts to create some flavors of similar things to MustSupport like this?
John Moehrke (Apr 29 2021 at 21:18):
I would like to have a "noNeedToSupportButOthersMight"
Lloyd McKenzie (Apr 29 2021 at 21:38):
I don't understand how that wouldn't simply be "everything that isn't mustSupport"?
Lloyd McKenzie (Apr 29 2021 at 21:39):
And that the full snapshot view shows you everything.
Lloyd McKenzie (Apr 29 2021 at 21:39):
We could go a bit farther and say we'll show an element if the definition or comments for the element have changed from the base resource.
Eric Haas (Apr 29 2021 at 23:53):
I agree with Lloyd it is the view of what implementers want - and Must support is part of that, I don't care what it is called, but a pure must support view should be replace by it IMO
Josh Mandel (Apr 29 2021 at 23:57):
I'd rather see IG-specific flags instead of a single "Must Support" flag with unspecified semantics that every IG overrides differently. For example, an IG might define and use three distinct flags, marking some elements as Must-Produce, some overlapping set as Must-Display and a special few as Good-With-Mustard.
Lloyd McKenzie (Apr 30 2021 at 00:17):
Changes to how mustSupport works should be discussed in a separate thread. Agree there are some changes needed there. However, it's what we have now. The key piece of this thread is that a mustSupport only view isn't sufficient. There are certain other elements that implementers need to be aware of and pay attention to even if they're not mustSupport - and the view needs to expose that.
Richard Townley-O'Neill (Apr 30 2021 at 05:49):
Should the algorithm include elements referenced by invariants?
Lloyd McKenzie (Apr 30 2021 at 13:23):
If the invariant appears on an element that falls into the above algorithm, then I guess so. (That'll also encourage designers to make sure they get the 'constraint' references right.)
Last updated: Apr 12 2022 at 19:14 UTC
