Stream: conformance
Topic: Slicing by order
Simone Heckmann (Oct 27 2017 at 21:34):
Is it possible/allowed to assign meaning to slices according to their order?
e.g. I have an ordered, closed set of two slices, that are indistinguishable by their attributes.
The first slice is mandatory, the second is optional.
The reason for slicing is mostly to be able to add distinct documentation to each slice, the validation rules for both are the same.
Grahame Grieve (Oct 27 2017 at 22:59):
I don't think that's possible
Lloyd McKenzie (Oct 27 2017 at 23:40):
We've talked about being able to slice by order, but haven't implemented it. (It would only be meaningful if the element being sliced is defined as having a semantic order.)
Simone Heckmann (Oct 28 2017 at 10:18):
In our case, it's about the payor element in Coverage.
We always have a primary payor, in some cases, there's also a secondary. They're both references to Organizations conforming to the same profile.
I don't know how to convey that in my Coverage profile...
Simone Heckmann (Oct 28 2017 at 10:24):
I mean. There are ways to solve that. But all I could come up with so far (adding a "secondaryPayor"-Extension to Coverage or extending the Reference type to include a priority) seem kind of bulky compared to just simply saying: "The first payor is primary and the second payor is secondary."
Lloyd McKenzie (Oct 28 2017 at 15:02):
Primary vs. secondary can be claim specific. So I'd expect each to be a separate Coverage instance. The Claim would then list them in order of precedence.
Simone Heckmann (Oct 28 2017 at 15:51):
No, actually that's what's on the data on our statutory health insurance card. It's the same coverage, except that some insurances don't handle the claim stuff themselves but refer it to another insurance. That's why we sometimes have two payor references that have slightly different semantics:
the first is always the primary contact for everything whereas the secondary (if present) only handles the claims.
Simone Heckmann (Oct 28 2017 at 15:52):
The intention is to keep the mapping of the card data to the Coverage resource as straightforward as possible.
Lloyd McKenzie (Oct 28 2017 at 21:19):
Ah, so one is providing the coverage and one is doing the processing?
Simone Heckmann (Oct 29 2017 at 10:09):
Sort of, yes. I don't even know the details about it. The explanation I got from reading the card data spec wasn't very verbose.
On second thought, I think the best way to go forward is to simply set the payor cardinality to 1..2 and add some prose to the definition of what it means if there's a second payor in an instance. In terms of validation it doesn't make a difference since both slices adhere to the same rules.
Vadim Peretokin (Nov 01 2017 at 08:58):
Is tagging with an extension not an option?
Chris Grenz (Nov 02 2017 at 15:39):
When we discussed this in the past, here's how it was suggested (by Grahame). A simple use case was first name vs. middle name(s). I have no idea if any current infrastructure support this. A profile would:
1. Declare an ordered slicing for an element (slicing.ordered:true) and no discriminator.
2. Create the first slice with a max:1
3. Create a second (and, if you desire, many more) with an appropriate max.
The validator/parser would then "consume" the slices in order.
It's tricky and error prone since the intent is relatively hidden.
@Ewout Kramer @Grahame Grieve - would your validators handle this?
Lloyd McKenzie (Nov 02 2017 at 16:38):
If there's no discriminator, then there must be a slicing description - and the validators would presume that the slicing mechanism is non-computable. They certainly wouldn't presume that the slicing was based solely on order.
Simone Heckmann (Nov 02 2017 at 16:49):
Forge at least doesn't currently permit to create slicing as you describe. If the descriminator is empty, that's a hard error.
Chris Grenz (Nov 02 2017 at 18:40):
Yep. GF#9729 was to address this issue with the description I gave above given as the solution. And thus, the request was withdrawn. If we don't think that works and nobody supports it, then we need to re-open the issue.
Lloyd McKenzie (Nov 03 2017 at 03:08):
Probably best to raise a new issue and point to the old one and explain why it needs to be readdressed
Michel Rutten (Nov 03 2017 at 13:52):
@Simone Heckmann Forge simply tries enforce the standard invariants, including eld-1: "On ElementDefinition.slicing: If there are no discriminators, there must be a definition".
So if you define an ordered slicing according to Chris' approach and fill in the slicing.description field, then the eld-1 invariant will hold.
Simone Heckmann (Nov 03 2017 at 14:01):
Ah! That's where I went wrong... Thanks!
Ewout Kramer (Nov 28 2017 at 11:44):
When we discussed this in the past, here's how it was suggested (by Grahame). A simple use case was first name vs. middle name(s). I have no idea if any current infrastructure support this. A profile would:
1. Declare an ordered slicing for an element (slicing.ordered:true) and no discriminator.
2. Create the first slice with a max:1
3. Create a second (and, if you desire, many more) with an appropriate max.
The validator/parser would then "consume" the slices in order.
It's tricky and error prone since the intent is relatively hidden.
@Ewout Kramer @Grahame Grieve - would your validators handle this?
Sorry for the late reply, but no: as long as the repeats "validate" in the slice (since there's no discriminator, a repeat just needs to validate to the constraints of the slice), it will keep on "filling" that slice - disregarding the cardinality. You'll get an error saying that 1..1 was expected, but many were found...
Last updated: Apr 12 2022 at 19:14 UTC
