Stream: conformance
Topic: ElementDefinition.MustSupport
Jose Costa Teixeira (Feb 28 2020 at 19:56):
Recalling some discussions in Atlanta:
Would it make sense to have ElementDefinition.MustSupport as a coding instead of boolean?
Jose Costa Teixeira (Feb 28 2020 at 19:59):
Currently we can only define the meaning of MustSupport at the level of an IG, and it's a boolean.
Any description or nuances about the meaning of MS are outside the StructDef,
Jose Costa Teixeira (Feb 28 2020 at 20:01):
(How, where) are others defining MustSupport?
Lloyd McKenzie (Feb 28 2020 at 20:13):
It can be defined at the IG or profile level and you can also provide usage notes on a per element level.
There's been some discussion about making it coded, though doing that creates some complexity and it's not sure it buys much:
- there's no way we could define codes that would cover all the possible meanings/nuances of mustSupport
- it would mean that applications would have to define custom codes to declare the meaning of must support rather than just providing text in their IG
- we can't change mustSupport from a boolean to a Coding at this point - ElementDefinition is normative, so this would have to supplement, not replace the existing flag
No one's yet indicated what they would computably do with a mustSupport code.
FHIR-I has agreed to define a number of common mustSupport statements that IG authors could look at and consider copying/using as a starting point when creating IGs.
John Moehrke (Feb 28 2020 at 20:17):
this is not true. I have provided some definitions of sub-definition of must-support. One that has been used for many years in DICOM, HL7, and IHE is "R2" (aka RE) -- Required to be populated if known, with no expectation on the recipient.
Grahame Grieve (Feb 28 2020 at 20:22):
is that an indication of what you'd do computably?
Lloyd McKenzie (Feb 28 2020 at 20:22):
Which of my statements is not true? I don't think your assertion disproves any of them...
John Moehrke (Feb 28 2020 at 21:27):
I assert that the "No one has yet..." You are just not agreeing with my proposal
Lloyd McKenzie (Feb 28 2020 at 21:40):
You haven't defined what you would computably do with a mustSupport code. You've just asserted that you have one. How do systems consume/compute on that code?
Lloyd McKenzie (Feb 28 2020 at 21:41):
And how would that scale if the set of codes were opened up to the 100+ codes that would likely be needed to represent the different combinations and permutations of behavior we might reasonably see across the set of possible IGs?
Jose Costa Teixeira (Feb 29 2020 at 05:16):
Perhaps we could enrich it with a coding, instead of replacing it.
Jose Costa Teixeira (Feb 29 2020 at 05:19):
How do we handle "shall be populated if known and if allowed for privacy etc reasons"?
Jose Costa Teixeira (Feb 29 2020 at 05:23):
it would mean that applications would have to define custom codes to declare the meaning of must support rather than just providing text in their IG
Is that a bad thing?
Currently we have to write some text in the IG (in an intro section.. while other IGs will possibly use another section, leading to inconsistency of how to use and read specs).
Besides, where to provide that text ? Not in .short - and if it is on .definition or .comment, then it will not be rendered in the structure diagram, only in the detailed descriptions page.
Frank Oemig (Feb 29 2020 at 09:41):
There is a proposal under way to define an extension. I need to find the other thread...
Lloyd McKenzie (Feb 29 2020 at 15:01):
My question is what's the point of defining a code? What is the difference in impact between a text in the IG narrative and text in the definition of a custom code? Are we expecting software to actually consume the code, given that anyone who wants to will be making up their own?
Jose Costa Teixeira (Feb 29 2020 at 16:18):
More than the code, it is about specifying the meaning of must support. Not buried in the text (which field? there is no guidance there, so I expect IGs to differ). So it's about making a different attribute or not make it boolean (from this discussion so far I think it is best to add a field - does this avoid breaking rules about normative resources?)
Lloyd McKenzie (Feb 29 2020 at 19:20):
We could introduce an optional element. Plan for now is an optional extension - because we don't have enough experience to demonstrate that it has value/will be widely used
Jose Costa Teixeira (Feb 29 2020 at 19:22):
sounds good. I will use an extension for now
Frank Oemig (Mar 02 2020 at 08:52):
please see https://chat.fhir.org/#narrow/stream/179177-conformance/topic/ElementDefinition.2EsupportType as well. (@Ioana Singureanu )
In IGs the use of mustSupport is highly varying. It would be good to start formalizing its use.
John Moehrke (Mar 02 2020 at 13:30):
Lloyd McKenzie said:
My question is what's the point of defining a code? What is the difference in impact between a text in the IG narrative and text in the definition of a custom code? Are we expecting software to actually consume the code, given that anyone who wants to will be making up their own?
The R2 has been used for a long time in healthcare. How can it be used programatically? It can be used very much like 1..* except there is a way to handle when there is no data to be sent. This rule seems very computable. It can, and is in IHE, further stressed by pre-condiditions that set the value so that the test tooling can see that it is indeed R2 being sent. These pre-condiditions often are part of the test procedure, but there are cases where the pre-conditions are part of a larger workflow.
Last updated: Apr 12 2022 at 19:14 UTC
