FHIR Chat · Removing defaults, meaning when missing

Stream: conformance

Topic: Removing defaults, meaning when missing

Josh Mandel (Feb 01 2018 at 18:45):

MOTION:
To remove the notion of "defaultValue[x]" and "meaningWhenMissing" from ElementDefinition. In the case where an item is optional (e.g. Period.end), the item documentation can explain the intended interpretation. Profiles must not create guidelines that change or assert interpretation of missing elements.
Motivation:
• We don't think the advantage of smaller size and "looks" arguments for leaving out defaults of the instance weighs up to the disadvantages of having an inconsistent or more complex processing of the data, opportunity of miscommunication ("sender did not know" vs. "have to assume the default")
• Since implementing special cases (which default behaviour is used) can introduce implementer mistakes, we would strongly suggest committees change any element with a default value to be mandatory.
The current list of such elements that would be made mandatory is relatively small.

Josh Mandel (Feb 01 2018 at 18:45):

(we will be voting on this at the beginning of the next quarter)

Josh Mandel (Feb 01 2018 at 19:14):

REVISED MOTION after discussion with Grahame over lunch:

Remove the notion of defaultValue[x] from ElementDefinition. Retain support for meaningWhenMissing, but specify that profiles must not create guidelines that change or assert interpretation of missing elements.

In most cases, default values can be eliminated by making elements required. In the case where an item needs to be optional, a meaningWhenMissing can be provided. We should discourage workgroups from populating meaningWhenMissing when the meaning is trivial (e.g. "the item is not known"). We should encourage workgroups to create data models where no special meaningWhenMissing is required.

Update 2.32.0.4.3 Missing Elements to indicate that "missing" should be synonymous with "has no value". This implies that "meaning when missing" applies to elements are not present and to elements that have no value. It also implies that searches for Patient?gender:missing=true should return all patients without a gender value (including patients that have extensions but no value on gender).

Update the examples in 2.32.0.4.3 Missing Elements to ensure they are up-to-date.

Motivation:

We don't think the advantage of smaller size and "looks" arguments for leaving out defaults of the instance weighs up to the disadvantages of having an inconsistent or more complex processing of the data, opportunity of miscommunication ("sender did not know" vs. "have to assume the default")
Since implementing special cases (which default behaviour is used) can introduce implementer mistakes, we would strongly suggest committees change any element with a default value to be mandatory.
The current list of such elements that would be made mandatory is relatively small.

This motion will require community consultation.

Michael Donnelly (Feb 01 2018 at 19:53):

Proposed rewording:
Motion:
1. Remove the notion of defaultValue[x] from ElementDefinition.
2. Retain support for meaningWhenMissing, but specify that profiles must not create guidelines that change or assert interpretation of missing elements.

Execution Details:

In most cases, the default value for an element can be eliminated by making that element required.
When an element needs to be optional, a meaningWhenMissing can be provided.
* Workgroups are discouraged from specifying a meaningWhenMissing when that meaning is trivial (e.g. "the item is not known").
Workgroups are encouraged to create data models in which meaningWhenMissing is not required.
Update 2.32.0.4.3 Missing Elements to indicate that "missing" should be synonymous with "has no value".
* This implies that "meaning when missing" applies to elements are not present and to elements that have no value. It also implies that searches for Patient?gender:missing=true should return all patients without a gender value (including patients that have extensions but no value on gender).
Update the examples in 2.32.0.4.3 Missing Elements.
Motivation:
We don't think the advantage of more concise resources is outweighed by the disadvantages of
* inconsistent or more complex processing of the data and
* opportunity for miscommunication ("sender did not know" vs. "have to assume the default")
Implementing special cases (in which default behavior is used) can introduce implementer mistakes. We strongly suggest committees change any element with a default value to be mandatory.
The current list of such elements likely to be made mandatory is relatively small.

This motion will require community consultation.

Josh Mandel (Feb 01 2018 at 20:04):

Thanks @Michael Donnelly !

Alexander Henket (Feb 05 2018 at 23:12):

Just caught this... I can see how eliminating defaultValue[x] could be beneficial for StructureDefinitions that define something FHIR, but when it comes to usage for V2/V3 defaults just exist, and if StructureDefinition doesn't do that then we cannot handle V2/V3 anymore. E.g. @negationInd has a default of 'false'. So unless I'm missing something, it seems like a bad idea to completely loose defaultValue. Maybe an invariant to scope it to V2/V3 is an option?

Grahame Grieve (Feb 05 2018 at 23:13):

that's a pretty good point - I agree with it. It would be very problematic to drop it from logical models

Alexander Henket (Feb 05 2018 at 23:14):

What if you profile a V3 logical model? Doesn't that constitute a profile? Or is every template on a logical model also a logical model?

Grahame Grieve (Feb 05 2018 at 23:15):

in the sense of my sentence, yes

Grahame Grieve (Feb 05 2018 at 23:15):

though v3 profiles don't introduce default values?

Alexander Henket (Feb 05 2018 at 23:18):

... had to check.. Template ITS does not offer that no. It would be a textual constraint if you would do it at all. Checking V2 Conformance Profile next .. hang on