Stream: IG creation
Topic: Bug in Snapshot Generation of Type Slices?
Chris Moesel (Dec 16 2021 at 23:31):
Given this differential:
[
{
"id": "Observation.value[x]",
"path": "Observation.value[x]",
"slicing": {
"discriminator": [{ "type": "type", "path": "$this" }],
"ordered": false,
"rules": "open"
},
"type": [{ "code": "CodeableConcept" }]
},
{
"id": "Observation.value[x]:valueCodeableConcept",
"path": "Observation.value[x]",
"sliceName": "valueCodeableConcept",
"min": 0,
"max": "1",
"mustSupport": true
}
]
the IG publisher creates this:
image.png
Notice that the type slice has ALL the types in it. Since value[x] was already type constrained to only CodeableConcept, then shouldn't the slice also be type constrained to CodeableConcept (without having to put it in the differential)? It doesn't make sense for a type slice to support more types than its slice base, but this is what the snapshot generator is doing... That's not right, is it?
Lloyd McKenzie (Dec 17 2021 at 00:55):
It's not right, but the question is whether we expect the base information to be propagated into slices. I believe the answer is "no". @Grahame Grieve ?
Chris Moesel (Dec 17 2021 at 13:46):
Why shouldn't the snapshot generator use the base slice element as its starting point (rather than the unconstrained element from the core resource)? If authors have to manually duplicate all their constraints into each slice, then there will undoubtedly be mistakes -- and it can potentially introduce a lot of noise into the differential as well. Is this a technical limitation in the snapshot generator or an intentional design choice?
Lloyd McKenzie (Dec 17 2021 at 15:48):
I'll let @Grahame Grieve answer that. I think some of it has to do with constraints around constraining slices.
Last updated: Apr 12 2022 at 19:14 UTC
