FHIR Chat · Invalid validation error at binding · implementers

Stream: implementers

Topic: Invalid validation error at binding

Maximilian Reith (Sep 12 2019 at 12:57):

Hey,

i got a validation error while validating this resoure: Practioner.xml

<issue>
<severity value="error"/>
<code value="processing"/>
<diagnostics value="provide either a reference or a description (or both) [valueSet.exists() or description.exists()]"/>
<location value="StructureDefinition.differential.element[28].binding"/>
</issue>

element[28]:

<element id="Practitioner.qualification.code">
  <path value="Practitioner.qualification.code" />
  <binding>
    <strength value="required" />
  </binding>
</element>
<element id="Practitioner.qualification.code.coding">
  <path value="Practitioner.qualification.code.coding" />
  <min value="1" />
  <max value="1" />
</element>

I think this error is invalid, since the required valueset is defined in the snapshot:

  <binding>
    <strength value="required" />
    <description value="Specific qualification the practitioner has to provide a service" />
    <valueSetUri value="http://fhir.de/ValueSet/kbv/s-bar2-arztnrfachgruppe" />
  </binding>

is this correct? could somebody confirm this?

greetings Max

Patrick Werner (Sep 12 2019 at 13:30):

i just tried validating with the java validator:

*FAILURE* validating Practioner.xml:  error:2 warn:0 info:0
  Error @ StructureDefinition.snapshot.element[30].example[0].value.ofType(uri) (line 1333, col135) : URI values cannot have whitespace
  Error @ StructureDefinition.differential.element[27].binding (line 4296, col16) : provide either a reference or a description (or both) [valueSet.exists() or description.exists()]

This binding just has the binding strength an no ValueSet to bind to

Grahame Grieve (Sep 12 2019 at 13:39):

yes you can't do what that is trying to do. It's probably a mistake, but the spec says that if you specify anything about the binding in a diff, you need to specify a value set

Stefan Lang (Sep 12 2019 at 13:39):

That would be a bug in Forge then?

Stefan Lang (Sep 12 2019 at 13:40):

Or a bug in the spec?

Grahame Grieve (Sep 12 2019 at 13:41):

well.. that depends on your perspective.

Stefan Lang (Sep 12 2019 at 13:43):

It depends on whether your name is Grahame or Michel :joy:
Any way, currently Forge creates differentials that will not validate against the spec whenever you just change the binding strength of a VS binding.

Michel Rutten (Sep 12 2019 at 13:44):

the spec says that if you specify anything about the binding in a diff, you need to specify a value set

Where is this defined? Do you think this is something that Forge should verify?

Stefan Lang (Sep 12 2019 at 13:44):

Well, at least there is a validation in the spec that acts this way

Michel Rutten (Sep 12 2019 at 13:45):

Apparently, but where can I find this on the FHIR spec website?

Grahame Grieve (Sep 12 2019 at 13:46):

it's one of the formal constraints on ElementDefinition

Michel Rutten (Sep 12 2019 at 13:46):

Which one?

Michel Rutten (Sep 12 2019 at 13:47):

I've tried to cover all relevant FHIRPath invariants in Forge. Did I miss one?

Michel Rutten (Sep 12 2019 at 13:47):

eld-11 and eld-12 seem to verify something else

Grahame Grieve (Sep 12 2019 at 13:47):

eld-10 in STU3

Stefan Lang (Sep 12 2019 at 13:50):

I think there's a reason eld-10 got removed from R4?

Patrick Werner (Sep 12 2019 at 13:50):

so this invariant is DSTU3 only, in R4 you could just change the binding strenght in a diff, right?

Michel Rutten (Sep 12 2019 at 13:50):

Yes, I see, in R4 this is now sdf-10

Stefan Lang (Sep 12 2019 at 13:51):

Right, as probably originally intended sdf-10 does not cover differential

Michel Rutten (Sep 12 2019 at 13:51):

Forge indeed verifies this invariant. However the current implementation checks if the values are empty in the generated snapshot, so taking into effect any values inherited from the base.

Michel Rutten (Sep 12 2019 at 13:52):

So if the base profile introduces a valueset for a binding, then the invariant currently always succeeds.

Stefan Lang (Sep 12 2019 at 13:55):

So Forge/STU3 apparently acts as intended in R4, but does not follow eld-10/STU3

Stefan Lang (Sep 12 2019 at 13:56):

To follow eld-10, you definitely need to fill valueSet or description in the differential

Stefan Lang (Sep 12 2019 at 13:59):

It's basically not something that Forge should verify, but it's an exception to the rule that you only have changed elements within the differential

Stefan Lang (Sep 12 2019 at 14:03):

So Forge/STU3 probably should add valueSet/description to the element in the diff when binding is present.
This would keep eld-10 silent without hurting anything else.

Michel Rutten (Sep 12 2019 at 14:48):

Forge STU3 verifies eld-10 from STU3 spec.
Forge R4 verifies sdf-10 from R4 spec.
Looks like no change required.

Stefan Lang (Sep 12 2019 at 14:50):

As I understand, the error @Maximilian Reith mentions is triggered by a STU3 profile created by Forge STU3

Stefan Lang (Sep 12 2019 at 14:54):

STU3 eld-10 expects valueSet and/or description to be in the SD.differential, even though neither of these are changed against the baseDefinition.
It does so when strength has changed and therefor exists in the diff.
So Forge needs to add valueSet/description (whichever is filled in the snapshot) to the differential

Michel Rutten (Sep 12 2019 at 14:58):

Indeed, I can confirm that Forge STU3 does not warn about eld-10 when opening the practitioner profile above. I'm reluctant with making changes to user profiles. However I could update eld-10 logic in STU3 to actually check the diff instead of the snapshot, as is currently the case.

Stefan Lang (Sep 12 2019 at 15:02):

I think this is more about the way Forge creates the actual diff.
If Forge doesn't fill binding.valueSet/binding.description whenever binding.strength exists in the diffferential, eld-10 will always complain

Michel Rutten (Sep 12 2019 at 15:02):

I'd have to check the commit history. Possibly the validation logic has been slightly relaxed after community feedback that eld-10 was too strict...

Stefan Lang (Sep 12 2019 at 15:04):

Makes sense, but apparently didn't get through to at least the Java implementation ;-)

Maximilian Reith (Sep 13 2019 at 06:36):

yes i created this profile by Forge STU 3 22.0

I think this is more about the way Forge creates the actual diff.
If Forge doesn't fill binding.valueSet/binding.description whenever binding.strength exists in the diffferential, eld-10 will always complain

i would support Stefan...that is something Forge could do for you.

Michel Rutten (Sep 13 2019 at 08:26):

It's not completely trivial. Forge contains a diffing engine that automatically strips all redundant constraints, i.e. constraints that are already defined by the base profile, to generate the differential. Forge would need to dynamically override this behavior and force the binding.valueSet property to the output in some circumstances, even if seemingly redundant.

Stefan Lang (Sep 13 2019 at 08:53):

The alternatives to changing Forge would be:
- technical correction in STU3 (may be reasonable, since probably hundreds or thousands of STU3 profiles are out there that do not conform to eld-10, and eld-10 is broken anyway)
- just change the validators to ignore eld-10 (bad)
- tell everybody to just ignore the error (worse)

Stefan Lang (Sep 13 2019 at 08:55):

Oh, and:
- just don't validate StructureDefinitions ;-)

Last updated: Apr 12 2022 at 19:14 UTC