Stream: IPS
Topic: Status of slicings of non-repeating elements in IPS
Morten Ernebjerg (Aug 13 2021 at 07:19):
I just read this extended Zulip discussion of slicing of nom-repeating elements and if I read it right, the conclusion there is that slicing of non-repeating, non-polymorphic elements will not be supported. Indeed, I just had the Java validator throw an error at me for slicing a non-repeating field in a profile of my own. However, IPS 1.0.0 _does_ have such slicing - the one I know is on Condition.code, where the slices indicate how to use specific types of codes. That makes me a little worried that the tooling will come back to bite us when using or building on IPS (though I actually haven't see any issues yet). Hence these questions:
- Are there known issues with validation arising from the slicing of non-repeating elements in IPS?
- Are there any plans for how to deal with such sliced element future versions (i.e. will they be replaced by smt. else)?
Rob Hausam (Aug 13 2021 at 13:43):
@Morten Ernebjerg Yes, your conclusion is correct (at least at the present time) - slicing of non-repeating, non-polymorphic elements is not supported. And you are also correct that the published IPS IG includes profiles that use that type of slicing. The three basic options to deal with that (besides ignoring it and running the risk of problems with the tooling, as you suggest) are: (1) Move the slicing from the non-repeating CodeableConcept element to the CodeableConcept.coding level (which does, of course, repeat); (2) Remove the slicing and instead use an element binding to a "combined" value set that contains all of the codes (with the different choices of code systems and contributing value sets being visible in the "combined" value set definition, rather than as separate slices); and (3) making an argument (again!) that slicing on non-repeating, non-polymorphic elements should be supported - as (a) slicing is just applying an identified set of constraints, which should be applicable for any element; and (b) a non-repeating, non-polymorphic element is logically equivalent to either a repeating element with only a single repetition or a polymorphic element (which is always non-repeating) with only a single choice of type, so there is no logical reason to exclude the non-repeating, non-polymorphic case. In the IPS connectathon branch (and my local build) I'm testing and working through which approach we will want to take to resolve this for the STU update. Any and all feedback and assistance with moving forward and making this decision is certainly welcome!
Rob Hausam (Aug 13 2021 at 13:49):
In the discussion on the IPS call last week we did re-affirm the prior conclusion that presenting these choices as separate slices is preferable to having that visible in only the value set definition - so (assuming no one presents a very persuasive argument otherwise) that narrows it to a choice of either #1 or #3 above.
Morten Ernebjerg (Aug 13 2021 at 14:52):
Thanks a lot for the thorough summary, @Rob Hausam! I also much prefer the visible slicing (most user-friendly). Slicing at the level of the non-repeating element (#3) seems somewhat clearer to me since we are really listing distinct ways of filling this element. But I could live with #1 - and would certainly prefer it in practice unless all validators support #3! E.g. we use validation as a "gatekeeper" so spurious validation errors can be a major headache.
Last updated: Apr 12 2022 at 19:14 UTC
