Stream: IG creation
Topic: Slicing non-repeating elements
Lloyd McKenzie (Jul 23 2021 at 02:23):
My understanding was that slicing non-repeating elements was prohibited unless they were polymorphic (and then, slicing could only be by type). However, in the IPS implementation guide Allergy profile, I see this:
image.png
code is 1..1 and is being sliced by pattern. The validator seems perfectly happy according to the QA page.
@Grahame Grieve, @Mark Iantorno , have we finally relaxed the rule to allow slicing of any element?
Rob Hausam (Jul 23 2021 at 03:03):
I didn't think we had relaxed the rule - but maybe I'm wrong. This is what we were doing before, and we published it that way in the IPS STU while the validator was acting happy with it at the time - but then it became unhappy again later, after we published, and we have been planning to change it to slicing on the Codings in our upcoming STU update. But it's interesting that you bring this up, because I've been finding again that slicing at the Coding level probably isn't able to provide the normal CodeableConcept behavior, including the freedom to include whatever translation codes are desired, that we are looking for. So I was going to do a bit more testing on this and then was expecting to bring the issue up again myself. I really think that we probably should allow this - and if my testing goes as I expect I'm going to try to prove why we should do that. I haven't actually been building the older published version of the code recently with the later validator versions - so maybe the validator has gotten happy with this again? If so, that would be an interesting development - and another point in favor of moving forward with making this "legal".
Lloyd McKenzie (Jul 23 2021 at 03:05):
There are absolutely cases where slicing non-repeating elements would be useful. However, it adds complexity to an already ultra-complex set of code, and there's a cost to doing that.
Rob Hausam (Jul 23 2021 at 03:15):
Yes, I agree there is a cost, and we shouldn't take that lightly. But in this case, it seems likely, and we tried to argue, that the incremental cost to include this would be likely be rather small. As we all know, we already have slicing on the repeating elements. And there is no question that a non-repeating element is logically and can be treated the same as a repeating element with only a single repetition (the "wire format" is different, but that's not really the issue here). Assuming that I'm recalling it correctly, the .Net validator already was handling it that way and allowed slicing on the non-repeating elements with no problem - and they actually had to add code to disallow the slicing on the non-repeating elements (If I'm wrong in any of that I'm happy to be corrected, but that's how I recall the discussion).
Richard Townley-O'Neill (Jul 23 2021 at 04:55):
We have struggled with saying nicely that a non-repeating element must have a value from one of two very different value sets. This slicing is an elegant way of saying that.
I have no idea what the implementation costs are.
Rob Hausam (Jul 23 2021 at 12:18):
Yes, exactly, @Richard Townley-O'Neill.
Chris Moesel (Jul 23 2021 at 13:12):
As an implementor of profiling tools, I'd say that slicing is one of the most challenging aspects of profiling for most authors; and definitely one of the more challenging aspects for us implementing profiling tools as well. I think we should expand use of slicing with caution; understanding the cognitive load it puts on those who need to process and understand the profiles as well.
I see how slicing could be helpful in saying that a code could come from two value sets -- but you could also say that (pretty simply) by constructing a new value set that uses component rules to union the two value sets together. Where you would need slicing is if you wanted to apply further (different) constraints on child elements based on which of the two valuesets was bound. But at that point, you might also want to consider if you should just have a different profile per value set used (particularly if the value sets really are that different).
David Pyke (Jul 23 2021 at 13:14):
I completely agree, I see slicing used in places to create documentation (the slice name) instead of using it for utility. We need to give guidance on when not to use slicing.
Rob Hausam (Jul 23 2021 at 13:31):
I agree with all of these considerations, too. But they're really more about slicing and its uses (or not) in general - not about whether there is a good reason to explicity exclude slicing on non-repeating, non-polymorphic elements (and allow and support it everywhere else).
Last updated: Apr 12 2022 at 19:14 UTC
