Stream: IG creation
Topic: Revamping the 'mustSupport' view
Lloyd McKenzie (May 22 2021 at 01:17):
The mustSupport view doesn't really cover what most of us want. What we really want is a view that shows "What elements to implementers who only care about compliance with this specification have to worry about?". Obviously that includes the mustSupport elements, but it also includes:
- mandatory elements
- elements that have been constrained in some way from the base resource (e.g. constrained cardinality, constrained data types, invariants, etc.-) -because it may impact interoperability with other profiles
- elements that are 'modifiers' because implementers must check for the existence of values they don't recognize that might invalidate their understanding of the instance.
The proposal is to define a new 'view' of StructureDefinitions that reflects this set of constraints. The intention is to replace the 'mustSupport' view in the standard template with the new rendering, though we can retain the old "only mustSupport" elements if there is interest.
Feedback here or in Git: https://github.com/HL7/fhir-ig-publisher/issues/147
David Hay (May 23 2021 at 08:22):
@Brian Postlethwaite did some work on this a little while back I recall...
Brian Postlethwaite (May 23 2021 at 08:24):
That's what the must support view is.
Brian Postlethwaite (May 23 2021 at 08:27):
For my consumers I'm happy with must support. Most of my consumers are new implementers, and just want to see what they have to code against.
If they want to see that other detail, the other views are there.
Some who review might use the other views, but that's very few of the users for a small part of its life cycle.
Lloyd McKenzie (May 23 2021 at 11:33):
But your customers have to code against mandatories that aren't mustSupport. They also have to code against modifiers that aren't mustSupport (at least to check if they're valued with something unrecognizable). Finally, they need to code against targets of invariants that aren't mustSupport . If we split into senders vs. receivers, senders care about mandatories and invariants, receivers care about modifiers.
Lloyd McKenzie (May 23 2021 at 11:35):
If mandatories and modifiers and targets of invariants are already mustSupport, then obviously the views won't be different - and that's often the case for most well-designed IGs, but there are situations where you don't want to make something must support, but still need to provide a value as a sender (just no expectation to capture, store or display). And sometimes designers miss things - particularly modifier extensions and things like Resource.implicitRules that a whole lot of implementers don't check because they forget it's even there (and IG designers forget to constrain it away).
Brian Postlethwaite (May 25 2021 at 17:39):
If they need to know about them, I'll be marking them as must support.
Lloyd McKenzie (May 25 2021 at 18:38):
@Brian Postlethwaite Can you give an example where they wouldn't need to know about them? There are certainly use-cases where something will be mandatory and need to be known about, but will have a fixed value and not need to be mustSupport. Would you object to those being in your view? Obviously if you don't have that situation, nothing extra will show up...
Richard Townley-O'Neill (May 26 2021 at 03:08):
There is an example of a profile that uses a fixed value on a mandatory element that is not must support in Task.intent in https://sra.digitalhealth.gov.au/fhir/currentdraft/StructureDefinition-sra-match-record.html
Last updated: Apr 12 2022 at 19:14 UTC
