Stream: shorthand
Topic: Slicing cardinalits validation Error
Patrick Werner (Sep 17 2021 at 12:28):
I think i found a bug in the slicing valdidation:
If you set a sliced element to 0..0 and the element contains slices sushi reports an error:
error No individual slice may have max > max of sliced element, but max of slice valueQuantity (1) > max of sliced element (0).
https://www.hl7.org/fhir/profiling.html#slice-cardinality enforces this rule for the min card.. but not the max cardinality.
Created an issue:
https://github.com/FHIR/sushi/issues/918
Chris Moesel (Sep 17 2021 at 12:49):
Thanks for reporting... I think the main thing SUSHI is trying to enforce is that if an array can only have x elements, then it's wrong to say that any slice within it can have x+1 elements. For example, it doesn't make sense to say "no components allowed" but also say "up to one systolic component is allowed and up to one diastolic component is allowed".
This error is most helpful when an author is adding slices to an array whose cardinality has already been constrained -- because their new slice constraint is obviously incorrect. But I agree that it's a bit more confusing when it happens because you card-constrain an array that is already sliced (and the new array constraint allows fewer elements than some of the slices do). I guess the questions are (a) would the author still want to know that (in case it is unintentional)? (b) Should we force the other to also reconstrain the slices to fit within the overall array max? (c) Should SUSHI reconstrain those slices for them? Or (d) should we just let it go as-is even though it introduces inconsistency between the slices and container?
Morten Ernebjerg (Sep 19 2021 at 12:25):
Would it be possible for SUSHI to distinguish between (a) the case where there is a contradiction in the slice/element cardinalities defined within a single profile, and (b) the case where the contradiction is between constraints in a base and a derived profile? If I read the example from @Patrick Werner correctly, he is talking about case (b) where my feeling is that a warning would do. However, I also think that an error is still appropriate in case (a) since I cannot imagine a case where a cardinality-contradiction is on purpose in that scenario.
Patrick Werner (Sep 20 2021 at 08:09):
+1 to all what @Morten Ernebjerg said.
Patrick Werner (Sep 20 2021 at 08:10):
I only would make it a warning in either way as this isn't forbidden by the FHIR spec.
Patrick Werner (Sep 23 2021 at 12:39):
i assume there is no workaround, and we have to wait for the next version?
Chris Moesel (Sep 23 2021 at 13:37):
Well... the workaround is to add rules to restrict the card of the slices so they fit within the overall card of the container. But if you're asking for a workaround to remove the error... no, I don't think we have one at this point. We haven't started working on a solution for this yet, but we start a new development sprint today, so we'll try to fit it into the list for the next two weeks.
Patrick Werner (Sep 23 2021 at 13:55):
that would be wonderful.
Unfortunately i'm deriving from another Profile, defining these slices, but i need to set the whole element to 0..0
Patrick Werner (Sep 23 2021 at 13:56):
I think this is a very common use-case, will provide structured comments in the issue
Patrick Werner (Sep 23 2021 at 14:56):
Updated the Issue with expected behaviour
Chris Moesel (Sep 23 2021 at 15:20):
Unfortunately i'm deriving from another Profile, defining these slices, but i need to set the whole element to 0..0
Yeah, but just to be clear, you should still be able to zero out the inherited slices via something like:
* component[inheritedSliceName] 0..0
You might have to do that before setting the sliced element to 0..0. But that should get you around the error for now.
Patrick Werner (Sep 24 2021 at 08:41):
thanks for the workaround, so obvious
Chris Moesel (Oct 05 2021 at 12:14):
@Patrick Werner - I re-read that part of the spec you linked to and realized that it seemed like it does say that the slice max cannot be greater than the element max. It just doesn't say it very clearly. So I asked about it separately and Grahame confirmed the intent: "slice max can't be greater than element max". So SUSHI is, in fact, enforcing FHIR spec here... So now I'm wondering if we run into this situation if we should just issue a warning and automatically reduce all maxes to be no greater than the element max.
Patrick Werner (Oct 05 2021 at 14:02):
Thanks for your effort @Chris Moesel
Patrick Werner (Oct 05 2021 at 14:03):
I agree , if the outcome of the other thread is: you have to set each slice to 0..0 manually.
Patrick Werner (Oct 05 2021 at 14:04):
Sushi issuing a warning and automatically setting all slices to 0..0 would be very convinient
Last updated: Apr 12 2022 at 19:14 UTC
