Stream: IG creation
Topic: Element matches more than one slice
David deRoode (Jul 29 2021 at 13:49):
I'm trying to add an entry slice to a profile based on CCDAonFHIR's Consult Note (@ Plan of Treatment.entry) to allow an entry conforming to the Dental ServiceRequest profile to be allowed as an optional entry reference. But I'm getting this error "Profile http://hl7.org/fhir/us/dental-data-exchange/StructureDefinition/dental-consult-note, Element matches more than one slice - sliceEntry, sliceEntry/dental_sliceEntry". Is my slicing definition incorrect, or is this an IG Publisher thing? CI Build is here: https://build.fhir.org/ig/HL7/dental-data-exchange/
Lloyd McKenzie (Jul 29 2021 at 16:45):
It's an error on your part. You've said that you're slicing entry by profile. slice_entry includes the profile ServiceRequest and slice_entry_dental includes DentalServiceRequest, which is a proper constraint on ServiceRequest. Therefore, you can have an instance that's valid in multiple slices - and that's not allowed. When you have slicing, your slicing rules much be such that every element in an instance is valid against exactly one (or if slicing is open, against zero) of the slices. Being valid against more than one isn't allowed.
David deRoode (Jul 29 2021 at 17:44):
Agreed, an instance should never be allowed to be valid against 2 profiles. That is not the intent here. In this case, instances must conform to DentalServiceRequest (and not base ServiceRequest). But disallowing reference to a base ServiceReqest when it is an allowable targetReference in the base profile is not allowed either. So, I'm stuck
Lloyd McKenzie (Jul 29 2021 at 18:13):
If it conforms to DentalServiceRequest, it automatically complies with ServiceRequest. If you allow ServiceRequest, then saying you also allow DentalServiceRequest is unnecessary and redundant.
Chris Moesel (Jul 29 2021 at 18:13):
Lloyd McKenzie said:
It's an error on your part. You've said that you're slicing entry by profile. slice_entry includes the profile ServiceRequest and slice_entry_dental includes DentalServiceRequest, which is a proper constraint on ServiceRequest. Therefore, you can have an instance that's valid in multiple slices - and that's not allowed...
@Lloyd McKenzie -- it's actually sliceEntry/dental_sliceEntry, so he is re-slicing the sliceEntry slice. Isn't it valid for a reslice to discriminate based on a tighter constraint of the parent slice? Or am I missing something here?
Chris Moesel (Jul 29 2021 at 18:14):
I'll admit that I don't see the utility of it (since the slice doesn't specify any additional constraints/rules) -- but it doesn't seem invalid to me.
Lloyd McKenzie (Jul 29 2021 at 18:15):
I'm not sure what's being attempted. But it's not accomplishing anything - the base spec allows a whole bunch of resources. The derived spec isn't constraining that. If you want to say "Hey, by the way, we'd like you to pay attention to this new profile in this context", you can do that in documentation, but you can't do that via slicing. Slicing is about constraining what's allowed. If you're not constraining, you can't use it.
David deRoode (Jul 29 2021 at 18:54):
The intent is to require references from plan_of_care.entry conform to DentalServiceRequest profile.
Lloyd McKenzie (Jul 29 2021 at 19:03):
Then you shouldn't be slicing, you should just be constraining the target type.
Lloyd McKenzie (Jul 29 2021 at 19:04):
That will prohibit any other resource or any ServiceRequest that doesn't comply with the DentalServiceRequest profile.
David deRoode (Jul 29 2021 at 20:01):
Thanks for explaining, constraining resolved the errors. I let my wishful thinking of not needing to reference targetProfiles that *are * the same as the base profile get the better of me here. All clear now.
Last updated: Apr 12 2022 at 19:14 UTC
