Stream: conformance
Topic: Must Support
Pranitha Sruthi (Nov 29 2017 at 11:48):
Hi all, what does it mean when an element is labelled as 'must support ' in a US core profile? I have read the content on http://hl7.org/fhir/us/core/guidance.html#must-support. But how can I know which one of the conclusions mentioned in the guide apply for that context? Thank you
Eric Haas (Nov 29 2017 at 14:31):
The particular use case that apples to sender for a given data element. It boils down to "send it if you have it" You won't know a priori.
John Moehrke (Nov 29 2017 at 15:00):
The definition of must-support is to be defined in the profile as it might be different. In this case it is defined much like R2 or RE is defined in other specifications... if you have it you MUST send it. But a recipient has no idea if the sender is indeed following that MUST clause, as a recipient must handle empty as well as filled... Testers hate this kind of quasi-requirement, only testable by forcing the sender to have a patient with that data so that their test can fail when they don't see the data. And that doesn't cover cases where the sender is an app that simply has no way of having that value... It thus is an indicator to the sending app writer that 'you really should implement support this element if at all possible, and if you have the data you should consider it a required element to populate'
Eric Haas (Nov 29 2017 at 15:45):
yes to enforce it you have to create a TestScript and grade the implementation...
Pranitha Sruthi (Nov 30 2017 at 11:17):
What are different categories (elements which are mandatory, elements labelled must-support etc) of elements in a generic US core profile?
Eric Haas (Nov 30 2017 at 16:14):
We took a lot from our HL7 V2 experience. for usages see Ch2 for a detailed discussion of sender and receiver requirements:
- R (SHALL)= Required where cardinality (1..) = MUST to be present or fails validation
- RE( Must Support) cardinality (0..) + Must Support flag= true = MUST be present if you have the data (need test scripts to validate)
- C(a/b) = there is some invariant that affects the usage of an element a based on element b
- O (MAY) cardinality (0..) : no guidelines but you won't fail vaildation either way formally not defined.
SHOULD is in between RE and O - more like a nice to have but you won't fail vaildation either way
Eric Haas (Nov 30 2017 at 16:17):
In us core we only document the R , and RE and C(a/b) cases. everything falls in to the O category or is defined by the base standard.
Pranitha Sruthi (Dec 06 2017 at 09:49):
@Eric Haas Thank you
Grahame Grieve (Jun 05 2018 at 04:29):
the java validator currently gives a hint:
Grahame Grieve (Jun 05 2018 at 04:30):
Information @ ClinicalDocument.realmCode[1] (line 4, col27) : Instance includes element that is not marked as 'mustSupport' in the corresponding profile and was validated against a profile containing mustSupport=true elements.
Grahame Grieve (Jun 05 2018 at 04:31):
I think that this concern is misplaced, @Lloyd McKenzie (who added this). If a profile has must-support things, and also leaves some things as optional, that's got nothing to do with the implementers. I think it should be a warning about the profile itself - that it has things labelled as must-support but also optional things that are not. We shouldn't bother the users with something so arcane
Grahame Grieve (Jun 05 2018 at 04:31):
or we should add an extension to the profile that turns this on - but even then, I'm troubled because we validate across a network of profiles...
Grahame Grieve (Jun 05 2018 at 04:35):
This is paticularly clear when you're dealing with CDA where some thigns are labelled as must support in base specification itself
Lloyd McKenzie (Jun 05 2018 at 04:52):
It's useful when validating example instances when creating implementation guides.
Lloyd McKenzie (Jun 05 2018 at 04:53):
You want to know if your examples are including things that implementers aren't expected to support. In some cases, the solution is to strip the content as unnecessary (and confusing to implementers). In many cases, the solution is to mark as "mustSupport" elements you had forgotten to mark as mustSupport. And in some cases, you'll just suppress the warning.
Lloyd McKenzie (Jun 05 2018 at 04:53):
If we want to have a flag to trigger the check, that's fine. But it's absolutely needed where it's used.
Grahame Grieve (Jun 05 2018 at 04:57):
is it appropriate anywhere else?
Lloyd McKenzie (Jun 05 2018 at 05:10):
When you're authoring a system, it can be useful to know if you're spitting out data that consuming systems aren't expected to support.
Lloyd McKenzie (Jun 05 2018 at 05:10):
So perhaps not at runtime, but certainly during testing.
Grahame Grieve (Jun 05 2018 at 05:11):
so I don't really think that this is something that is inferred because must-support is found somewhere in the profile.
Grahame Grieve (Jun 05 2018 at 05:12):
I think it's an actual setting outright. And I don't think that the message is very good
Lloyd McKenzie (Jun 05 2018 at 05:47):
If you want to trigger it with a configuration parameter, that could work. What do you think the message should say instead?
Grahame Grieve (Jun 05 2018 at 05:50):
The element %1 is not marked as 'mustSupport' in the profile %2. Consider not using the element, or marking the element as must-Support in the profile
Lloyd McKenzie (Jun 05 2018 at 05:57):
ok
Grahame Grieve (Jun 05 2018 at 06:18):
new validator parameter -hintAboutNonMustSupport. Lloyd, can you document it at the bottom of this page:
Grahame Grieve (Jun 05 2018 at 06:18):
http://wiki.hl7.org/index.php?title=Using_the_FHIR_Validator
Grahame Grieve (Jun 05 2018 at 06:22):
also now a boolean parameter in the ig json file by the name of hintAboutNonMustSupport
Lloyd McKenzie (Jun 05 2018 at 14:02):
Documented for the validator and the IGPublisher
Rob Hausam (Jun 05 2018 at 19:35):
@Lloyd McKenzie I noticed that you didn't include the commas following the value for the added parameters in IG Publisher Documentation:
"check-aggregation" : true // Warning if aggregation not declared on differential elements of type Reference
"check-mustSupport" : true // Warning if mustSupport not declared on elements appearing in differential
"hintAboutNonMustSupport" : true //Info validation if elements appear in examples when not marked as mustSupport=true in one of the corresponding profiles
Lloyd McKenzie (Jun 05 2018 at 20:07):
We were missing commas a few other places too. Now all fixed
Last updated: Apr 12 2022 at 19:14 UTC
