Stream: implementers
Topic: Forge 'Must support' option
Brian Reinhold (Apr 11 2017 at 14:06):
Does anyone understand the purpose of the 'must support' option in Forge? How does this differ from setting the lower range of the cardinality different than 0?
John Moehrke (Apr 11 2017 at 14:13):
what has a 'must support' statement? I expect that must-support means that the data element must not be lost, query must be implemented, and any other functionality (isModifier) must be implemented. I don't like the word "support" as it is vague, surely it doesn't mean support as in how a rope supports something that is dangling... Cardionality of 0..* vs 1..* means that the element must have a value.
Brian Reinhold (Apr 11 2017 at 14:18):
John,
When using forge to create a profile one is presented with two check boxes when one starts profiling an element of a resource. One is 'must support' and the other is 'isModifier'. I do not know what the significance of those options is. If I check the box I get a blue symbol with the element indicating 'must support' but that doesn't help much. It seems to be independent of the cardinality setting so it must imply something different. I just don't know what!
John Moehrke (Apr 11 2017 at 14:23):
seconds after I posted I realized the context... you are using Forge to create a IG... so the question is about what affect the checkbox has in Forge... okay, sorry.
Brian Reinhold (Apr 11 2017 at 14:25):
Yes. I have not been able to find any description about the consequences of that setting; I would have assumed that specification of the cardinality was sufficient.
Michel Rutten (Apr 11 2017 at 14:26):
https://www.hl7.org/fhir/elementdefinition-definitions.html#ElementDefinition.mustSupport
Michel Rutten (Apr 11 2017 at 14:26):
"Allows a profile to set expectations for system capabilities beyond merely respecting cardinality constraints."
Michel Rutten (Apr 11 2017 at 14:27):
So if a profile defines mustSupport elements, then the profile author should provide an explanation of the intended meaning.
Brian Reinhold (Apr 11 2017 at 14:34):
Michel,
Thanks for that. Now I remember skimming by that comment and recalling its 'vagueness'. After re-reading it I am equally as unsure how to set it. I suppose (since I am specifying how Personal Health Device data is mapped to FHIR) that simply forcing the implementer of the upload to provide the field by specifying the minimum cardinality as > 0 accomplishes what I want. What the reader of the data does with it I leave up to the reader. If the reader wants to ignore the value of an Observation, well, that's the reader's prerogative (stupid perhaps but that's not my decision).
Michel Rutten (Apr 11 2017 at 14:54):
@Brian Reinhold right, then I don't think you need to constrain mustSupport. The mustSupport property indicates that a server SHALL support this aspect (and any implicit behavior as specified by the profile author) in order to process such a resource, and if it does not, then the server should not accept and/or try to process the resource instance alltogether.
Brian Reinhold (Apr 11 2017 at 14:57):
OKay thanks. This profile is not that complicated but is basically a mapping exercise; the 11073 data model of ASN1 byte sequences is being mapped to the FHIR data model. When it leaves the uploader there are no additional subtle behaviors that need to be invoked (besides storing the resources).
Lloyd McKenzie (Apr 11 2017 at 15:03):
mustSupport is primariliy relevant for situations where an element doens't have to be present in an instance but there's an expectation that the system must "support" it. For example, you wouldn't want to make Patient.deceasedDate have min=1. (Not the sort of thing we generally work towards in healthcare :>). But, in your IG, you might also want to set an expectation that systems will have the capability to store, display and otherwise make use of that element - because the default expectation is that systems are allowed to ignore and throw away whatever data they wish.
Lloyd McKenzie (Apr 11 2017 at 15:05):
mustSupport is left vague because what's relevant for "support" varies depending on the context of the implementation. We can't say "must display" or "must store" because a real-time decision support engine might not do either of those things - but might still need to take into account that the patient is deceased as part of the decision logic (e.g. not identify them as eligible for a screening test).
Lloyd McKenzie (Apr 11 2017 at 15:06):
mustSupport can even be relevant with items that have min>=1. Just because something must appear on the wire doesn't mean systems have to provide real support for it. Senders can send a fixed value. Receivers can receive and ignore. mustSupport sets the bar higher by identifying what the expectations are for systems to support the element.
Lloyd McKenzie (Apr 11 2017 at 15:07):
Each IG that makes use of mustSupport is responsible for defining what the expectations are for conformant systems when it comes to "supported" elements.
Lloyd McKenzie (Apr 11 2017 at 15:08):
Note that mustSupport is *not* generally something you can validate when looking at an instance - you actually have to examine system behavior - is the data stored, is it on the screen, is it taken into account in decision support language, is it taken into account when generating reports, etc.
Brian Reinhold (Apr 11 2017 at 15:15):
So what you are saying is something like, if the field it present, you have to deal with it. However, the field may not be present in all cases.
On the other hand, say I have a measurement value which has a cardinality of [1..1]. Now if I don't check the 'must support' I suppose that allows the reader to ignore it. Stupid for a measurement ... I wouldn't buy that implementation!
Lloyd McKenzie (Apr 11 2017 at 15:30):
It depends what the implementation is for. Maybe it's a decision support tool that's tracking when the last pap smear was done. It doesn't need to know the result, only the patient, type of test and the date.
Lloyd McKenzie (Apr 11 2017 at 15:32):
We can certainly rely on implementers to "support what's reasonable in the circumstance", but real life has shown that implementers can easily come to different conclusions - especially when they start out from different legacies. Part of getting the full benefit of interoperability is consistency of behavior - mustUnderstand allows implementation guides to take at least some steps towards defining that behavior.
Last updated: Apr 12 2022 at 19:14 UTC
