Stream: IG creation
Topic: Verification of VS Constraints in Closed Slicing
Saul Kravitz (Jan 29 2021 at 19:35):
I think we've hit upon an IG Publisher error involving the verification of VS constraints in closed slicing. The error is the failure to emit an error message. A high level explanation is:
- the base element that is sliced is bound to a VS
- slicing is closed
- one of the child slices requires a code that is outside of the base element's bound VS
Here is the actual example, from the carin-bb IG (the CI build illustrates the problem, I'll excerpt it here).
The example is from the ProfessionalEOB profile. https://build.fhir.org/ig/HL7/carin-bb/StructureDefinition-C4BB-ExplanationOfBenefit-Professional-NonClinician.html
Let's look at the slicing of item.adjudication
* item.adjudication ^slicing.rules = #closed
* item.adjudication ^slicing.ordered = false // can be omitted, since false is the default
* item.adjudication ^slicing.description = "Slice based on value pattern"
* item.adjudication ^slicing.discriminator.type = #pattern
* item.adjudication ^slicing.discriminator.path = "category"
* item.adjudication.category from C4BBAdjudicationCategoryDiscriminator (required)
* item.adjudication MS
* item.adjudication contains
adjudicationamounttype 1..* MS and
denialreason 0..1 MS and
inoutnetwork 1..1 MS and
allowedunits 0..1 MS
* item.adjudication[allowedunits] ^short = "The quantity of units, times, days, visits, services, or treatments for the service described by the HCPCS code, revenue code or procedure code, submitted by the provider. (149)"
* item.adjudication[allowedunits].category = C4BBAdjudicationDiscriminator#allowedunits
* item.adjudication[allowedunits].value only decimal
* item.adjudication[denialreason].category = C4BBAdjudicationDiscriminator#denialreason
* item.adjudication[denialreason].reason from X12ClaimAdjustmentReasonCodesCMSRemittanceAdviceRemarkCodes
* item.adjudication[denialreason].reason 1..1 MS
* item.adjudication[denialreason] ^short = "Reason codes used to interpret the Non-Covered Amount (92)"
* item.adjudication[adjudicationamounttype].category from C4BBAdjudication
* item.adjudication[adjudicationamounttype] ^short = "Amounts"
* item.adjudication[adjudicationamounttype].amount MS
* item.adjudication[adjudicationamounttype].amount 1..1
* item.adjudication[inoutnetwork] ^short = "Indicates the in network or out of network payment status of the claim. (142)"
* item.adjudication[inoutnetwork].category from C4BBPayerBenefitPaymentStatus (required)
Note:
- slicing is closed, and is on item.adjuidcation.category
- item.adjudication.category is bound to C4BBAdjudicationCategoryDiscriminator
-
There are four slices:
** allowedUnits -- category is C4BBAdjudicationDiscriminator#allowedunits
** denialReason -- category is C4BBAdjudicationDiscriminator#denialreason
** adjudicationamounttype - category is from VS C4BBAdjudication
** inoutnetwork - category is from VS C4BBPayerBenefitPaymentStatus -
C4BBAdjudicationCategoryDiscriminator is comprised of:
** adjudicationAmountType covered by -- codes from C4BBAdjudication
** denialRerason and allowedUnits covered by -- codes from C4BBAdjudicationDiscriminator
** inoutnetwork isn't covered --- it's codes are in C4BBPayerBenefitPaymentStatus
So, we have a closed slicing. One of the slices requires codes that are outside of the range of the VS of the discriminator. Should be an error.
Sushi doesn't check this, and neither does IG publisher.
Chris Moesel (Jan 29 2021 at 20:02):
I think the main issue here is that we have the base w/ an element that is bound to a valueset w/ required strength:
* item.adjudication.category from C4BBAdjudicationCategoryDiscriminator (required)
And then we have a slice that binds that same element path to a different valueset that is not a subset of the originally required value set:
* item.adjudication[inoutnetwork].category from C4BBPayerBenefitPaymentStatus (required)
Those bindings are technically incompatible since the slice VS does not constrain the base VS; it all out replaces it.
SUSHI doesn't catch this because SUSHI does not do terminology-based validation. Since it is possible to override a required binding in a valid way (if the new VS is a subset of the original VS), SUSHI doesn't complain. But since the IG Publisher does do terminology-based validation, I would expect it to catch things like this.
Lloyd McKenzie (Jan 29 2021 at 21:53):
If you have a binding on a repeating element, it applies to all repetitions. We have a number of places (particularly category) where there's a binding for a repeating element that isn't obviously intended to apply to all repetitions, but more likely "at least one of the repetitions". The only way to enforce such a binding in a resource definition is an invariant. I've actually raised a change request for us to try to address this issue (and clean up the places where we're doing it wrong).
Saul Kravitz (Jan 29 2021 at 22:02):
With the current definition (that the IG Publisher is happy with) it is impossible to create an instance of the profiled resource that includes the defined slice, since it violates the binding constraint. The VS binding for the discriminating element is NOT a superset of the VS for the slice, but rather they are disjoint.
Chris Moesel (Jan 29 2021 at 22:15):
Lloyd McKenzie said:
We have a number of places (particularly category) where there's a binding for a repeating element that isn't obviously intended to apply to all repetitions, but more likely "at least one of the repetitions". The only way to enforce such a binding in a resource definition is an invariant.
I don't want to go on too much of a side tangent, but can't you also say that via slicing? E.g., do an open slicing on category, discriminating by pattern on this(), and apply the VS binding in a 1..* slice? Wouldn't that effectively say at least one category must be a member of this VS, but other categories are allowed?
Chris Moesel (Jan 29 2021 at 22:16):
Oh... I missed the in a resource definition part. I guess we don't use slicing in resources, do we?
Lloyd McKenzie (Jan 30 2021 at 14:42):
Bingo.
Grahame Grieve (Feb 01 2021 at 20:53):
so I agree that the IG publisher doesn't validate slice fixed codes against against general bindings. I've not been motivated to prioritize this because as you say, there can be no valid instances against a profile like this
Chris Moesel (Feb 02 2021 at 16:09):
Grahame Grieve said:
so I agree that the IG publisher doesn't validate slice fixed codes against against general bindings. I've not been motivated to prioritize this because as you say, there can be no valid instances against a profile like this
I would think that detecting a profile that cannot have any valid instances would be something we would want to do, as the whole profile is useless at that point. Or are you thinking that if the author includes examples (as is best case), then the examples would prove out the validity or invalidity of the profile?
That said, not to be too contrarian, but if a CodeableConcept is fixed in a slice using pattern[x], then I think it still is possible to have a valid instance -- since a patternCodeableConcept does not prohibit you from having a coding that matches the general binding (e.g., an instance could have a CodeableConcept with coding[0] meeting the pattern[x] requirement and coding[1] meeting the binding requirement).
Chris Moesel (Feb 02 2021 at 16:11):
But much of that is beside the point here, because we're not talking about fixed codes. In the specific case Saul mentioned, the sliced element has a required binding to one value set and one of the slices overrides that binding with a required binding to a different (and disjoint) value set. So it's a matter of required value sets clashing.
Grahame Grieve (Feb 02 2021 at 20:34):
I agree it would be nice, but yes, the example validation should manifest the problem, which is why I have not prioritised it against all the other things I get asked to do
Lloyd McKenzie (Feb 02 2021 at 20:35):
Example validation will only manifest it if the element in question appears in the example - which isn't guaranteed if it's not mandatory
Last updated: Apr 12 2022 at 19:14 UTC
