FHIR Chat · Examples of re-slicing matches more than one slice · IG creation

Stream: IG creation

Topic: Examples of re-slicing matches more than one slice


view this post on Zulip David deRoode (Aug 03 2020 at 14:51):

The Dental Consult Note (Composition) is dependent on CCDAonFHIR Consult Note. CCDAonFHIR's Plan of Treatment section entry has a targetProfile of (base) ServiceRequest. Dental Consult has resliced entry (Composition.section:plan_of_treatment_section.entry:sliceEntry/dental_sliceEntry) and adds a a targetProfile of Dental-ServiceRequest; Dental-ServiceRequest profile is based on ServiceRequest.

The IG Publisher should recognize Dental-ServiceRequest entry targetProfile references as valid (and not *also *as base ServiceRequest targetProfiles). Yet, Dental-ServiceRequest entry references are getting this error in the Dental Consult example, "Profile http://hl7.org/fhir/us/dentalreferral/StructureDefinition/dental-consult, Element matches more than one slice - sliceEntry, sliceEntry/dental_sliceEntry"

view this post on Zulip Grahame Grieve (Aug 04 2020 at 00:58):

how to reproduce this?

view this post on Zulip David deRoode (Aug 04 2020 at 15:22):

These errors persist in the Dental Data Exchange CI build, so rebuilding the Dental IG in the CI build would be simplest. If you're trying to recreate outside of the Dental and CCDAonFHIR IGs, I'm at a loss for any quicker way than recreating in a new IG following the dependency structure above.

view this post on Zulip David deRoode (Aug 05 2020 at 16:12):

@Grahame Grieve to clarify, the error is on the example, as it contains an entry with a targetProfile (dental-serviceRequest) that ittself is based on base ServiceRequest. I think the issue is related to the fact that base ServiceRequest is also a targetProfile of CCDAonFHIR Plan of Treatment section.entry. The sliced and resliced profiles use the same profile/resolve() discriminator (which doesn't seem to be forbidden as long as the same discriminator uniquely identifies all allowable data); the IG publisher should be able to distinguish that Dental-SericeRequest is a more specific profile based on the base resource ServiceRequest.

view this post on Zulip Sarah Gaunt (Aug 16 2020 at 09:03):

I am getting the same error on my IG. Mine isn't to do with re-slicing though, I don't think.

I'm getting it on Composition.section.entry slices.
image.png

I can make all the errors above disappear If I remove from the Composition, all slices whose referenced profiles do not have a hard coded code (i.e. Procedure.code, Observation.code, Condition.code are bound to a value set rather than being patternCodeableConcept). That is the common denominator of all the profiles that are creating the multiple matches.

The other thing about all the offending profiles is that the value sets they are bound to all live either in VSAC or PhinVADS so there is no way for the publisher to check the values. They all have warnings like ValueSet https://phinvads.cdc.gov/vads/ViewValueSet.action?oid=2.16.840.1.114222.4.11.7113 not found by validator

So I feel like what is happening is that the publisher is trying to check the code to make the differentiation but it can't so it matches to multiple slices. Or something.

This is the Composition: http://build.fhir.org/ig/HL7/fhir-bfdr/branches/master/StructureDefinition-Composition-jurisdiction-live-birth-report.html
This is one of the profiles that I think is causing the issue: http://build.fhir.org/ig/HL7/fhir-bfdr/branches/master/StructureDefinition-Observation-cigarette-smoking-before-during-pregnancy.html
And this one: http://build.fhir.org/ig/HL7/fhir-bfdr/branches/master/StructureDefinition-Procedure-obstetric.html

view this post on Zulip Sarah Gaunt (Aug 16 2020 at 09:16):

It also counts multiples where there is very clearly only a single matching slice:
image.png

view this post on Zulip Sarah Gaunt (Aug 19 2020 at 05:50):

Any chance of looking at this @Grahame Grieve ? I'm at a loss as to how to fix it. It is happening on all my Compositions. Or any suggestions on further debugging on my part?

I've created a test Composition profile and test Composition example to try to get to the bottom of it.

https://github.com/HL7/fhir-bfdr/blob/master/input/resources/structuredefinition/Composition-test.xml
https://github.com/HL7/fhir-bfdr/blob/master/input/resources/composition/composition-test.xml

This errors with: Profile http://hl7.org/fhir/us/bfdr/StructureDefinition/Composition-test, Element matches more than one slice - testEntrySliceHC1, testEntrySliceVS1

If I comment out one of the two slices that have .code bound to a value set (testEntrySliceVS1 or testEntrySliceVS2) rather than a patternCodeableConcept, all the errors go away.

Then I get a warning: This element does not match any known slice defined in the profile http://hl7.org/fhir/us/bfdr/StructureDefinition/Composition-test for the entries that match the slice I commented out - GOOD.
I also get a warning This element does not match any known slice defined in the profile http://hl7.org/fhir/us/bfdr/StructureDefinition/Composition-test for an entry that matches a slice I didn't comment out (but is also a value set binding on code) - BAD - because it definitely does match.

view this post on Zulip Jean Duteau (Aug 19 2020 at 15:07):

+1 on getting this error as well

view this post on Zulip Grahame Grieve (Aug 20 2020 at 00:20):

@Sarah Gaunt these are all extensible bindings?

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 00:48):

Correct

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 00:49):

But I'm not specifically slicing on an extensible binding. Just on a profile that contains an extensible binding.

view this post on Zulip Grahame Grieve (Aug 20 2020 at 00:49):

you can't

view this post on Zulip Grahame Grieve (Aug 20 2020 at 00:50):

because the infrastructure can never determine whether a resource doesn't conform to a profile if the determination is based on an extensible binding

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 00:50):

So the infrastructure doesn't take into account at all what meta.profile is pointing to?

view this post on Zulip Grahame Grieve (Aug 20 2020 at 00:51):

no. that's just a claim. It's not an assertion of fact that the validator can accept

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 00:52):

Like I just want to say you have to have one of these types of profiles in this entry. And that is impossible to say unless the bindings contained in that profile are required?

view this post on Zulip Grahame Grieve (Aug 20 2020 at 00:52):

you can say that, you just can't discriminate on it

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 00:53):

How do I say it without discriminating on it?

view this post on Zulip Grahame Grieve (Aug 20 2020 at 00:57):

just don't have a discriminator. I think the implementers will complain, but they can ballot about this, right?

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 00:57):

TBH, I can probably change most of them to required bindings.

view this post on Zulip Grahame Grieve (Aug 20 2020 at 00:57):

that would be much better for everyone

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 00:57):

Ok, will play around with it.

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 00:57):

Thanks!

view this post on Zulip Sarah Gaunt (Aug 20 2020 at 01:31):

Still getting the same errors. No extensible bindings left in the IG. I'm going to guess it's because the bindings are to VSAC and PhinVADS value sets?

view this post on Zulip Grahame Grieve (Aug 20 2020 at 01:50):

maybe. I'm working on that now

view this post on Zulip Rob Hausam (Aug 20 2020 at 21:21):

I think we can come up with a better policy for how to validate this situation (with extensible bindings, etc.). I'm working on submitting a tracker.

view this post on Zulip Grahame Grieve (Aug 23 2020 at 21:28):

@Sarah Gaunt does changing to the new PHINVads value sets sort this issue out?

view this post on Zulip Sarah Gaunt (Aug 23 2020 at 21:30):

Haven't had a chance to try yet, will check a bit later today and let you know


Last updated: Apr 12 2022 at 19:14 UTC