R4 New Cardinality Requirements and Conversion from STU3 - ExplanationOfBenefit

1

With R4, we are noticing that the cardinality changed from 0…1 or 0…* to 1…1 or 1…* for several elements of an ExplanationOfBenefit resource from STU3:

-Created
-Insurer
-Provider
-Outcome
-Insurance

We would like to think these would always be found in an STU3 resource of the same but since they are not required, how would we handle with a conversion to R4, when not present?

2

Elements, such as created etc., can have extensions. See http://hl7.org/fhir/R4/extensibility.html
In your R4 instances elements like ExplanationOfBenefit.created do not get a value, but do an extension. The explanation could explain that no ordinary value is available. Maybe use http://hl7.org/fhir/R4/extension-data-absent-reason.html with a value of “unknown”

3

What is the correct standard to handle fields that are required and cannot use an extension.

EG: ExplanationOfBenefit.outcome in STU3 is not required but is required in R4. However, this is a field that requires a binding and cannot use an extension to say it is an unknown value.

In the R4 FHIR spec, it does mention that unless the profile requires a value, we can use the extension to say it is unknown, but the spec does not explain what to do in the case the profile DOES require a value and we do not have a value.

4

The first step is to submit a change request that complains about the cardinalities and indicate that they’re problematic (so they get fixed in future versions). Just click on the “propose a change” link at any place in the spec. There’s a one-time (free) registration, after which you can provide feedback at will.

If you have a 1…1 element that has a ‘required’ binding, you have a choice:

  • pick one of the codes from the value set - whatever is ‘closest’ or ‘good enough’ - something that might not be exactly what you want, but is at least ‘true’
  • use Basic as a replacement for the resource
  • be non conformant

One of the challenges with an STU specification is that sometimes when implementers try to use it in production, they’ll find that the specification is fatally broken in a particular space. That’s part of the reason why we have a “Standard for Trial Use” period where we get a variety of implementers to actually use the specification to make sure we fix those before we lock the specification down as “normative”. Obviously when it breaks for you, that really sucks.

Something else that can help is to have a wider set of perspectives at the work groups that are doing the designs. Typically if content is over-constrained, it’s because the group of individuals doing the design doesn’t have a wide enough perspective. FHIR is driven by the volunteers who show up to help drive the work. We always welcome more people and more perspectives to participate.