Stream: IG creation
Topic: Bug Fix in IG Publisher
Grahame Grieve (Jul 30 2019 at 06:35):
@all if you are producing an IG for publication this cycle, take note: in the next few hours I will release a new version of the IG publisher than includes a rather significant bug fix for the validator. The change is this:
If you specified a fixed value in your profile, and it had a null for any element in the fixed value (in the profile), then the validator would ignore any provided value in any instances that were supposed to conform to the profile.
It's not valid, if you have a fixed value, and it has a null, for the instance not to have null, but this wasn't being checked.
If you are balloting this cycle, please rebuild your IG with the latest publisher, and hunt down and fix any new errors that arise.
Eric Haas (Jul 30 2019 at 16:55):
If you specified a fixed value in your profile, and it had a null for any element in the fixed value (in the profile), then the validator would ignore any provided value in any instances that were supposed to conform to the profile.
It's not valid, if you have a fixed value, and it has a null, for the instance not to have null, but this wasn't being checked.
I don't know what this means, can you provide an example?
Lloyd McKenzie (Jul 30 2019 at 17:32):
My understanding: If you provided a fixed value for a Coding that had just a code and a system and your instance was missing a system, it would match for the fixed value anyhow.
Eric Haas (Jul 30 2019 at 17:54):
still not clear. you have mins for code and system too so the validation is based on that as well.
Grahame Grieve (Jul 30 2019 at 19:28):
no. if you provided a fix value for Coding that did not include a version , then the validator would completely ignore the version in the instance - it could be present or not
Eric Haas (Jul 30 2019 at 19:49):
when you say " a fix value for Coding " what do you mean exactly? because I think of ...
Coding
Coding.value, fixed value = 'foo' , min =1, max =1
Coding.system, fixed value = 'http://foo.bar.com', min =1, max =1
so here Coding.version could be present or not and still validate correctly.
Grahame Grieve (Jul 30 2019 at 19:52):
no. if you specify a fixed value for a coding of
{ "system" : "http://foo.bar.com", "code" : "foo" }
Eric Haas (Jul 30 2019 at 20:23):
I did not know that was even allowed. :-)
Grahame Grieve (Jul 30 2019 at 20:25):
no and it would be better to use it - say in US core. I had not noticed
Grahame Grieve (Jul 30 2019 at 20:26):
though there are 3 CodeableConcept patterns in US core
Lloyd McKenzie (Jul 30 2019 at 21:10):
In general, fixed values for complex structures is not a great idea - it means that you're non-conformant if you send a display or primary or extension or anything 'extra'. And treating extra stuff as an error essentially means imposing a site-specific interface on all clients, which is not good interoperability practice.
Shovan Roy (Jul 31 2019 at 00:20):
@Grahame Grieve with the new publisher, I'm getting "The FHIRPath expression 'Observation.value[x].code' is not valid" Error but not able to trace down which Observation is causing this error. Is there a way to trace the respective Observation.. For your reference, here is the build log: http://build.fhir.org/ig/hl7au/au-fhir-childhealth/branches/master/build.log
Grahame Grieve (Jul 31 2019 at 02:04):
fixed next release (sometime today)
Last updated: Apr 12 2022 at 19:14 UTC
