Stream: conformance
Topic: Validator messages and preferred bindings
Grahame Grieve (Jan 20 2020 at 21:40):
The DocumentReference resource has a preferred binding for DocumentReference.content.format. If you validate a resource that has some other code not in the preferred binding, you get this:
The Coding provided is not in the value set http://hl7.org/fhir/ValueSet/formatcodes, and a code is recommended to come from this value set
An IG can redefine that, and define another binding. All good.
However: Whenever you validate, the validation validates not only against the profile you ask to validate against, but also against the base specification. That has the consequence that irrespective of the validity of the code in the profile, you're always going to get the message from the base spec.
I have a consumer who is confused by the message, and asking what they can do to conform the specification
Grahame Grieve (Jan 20 2020 at 21:40):
I
Grahame Grieve (Jan 20 2020 at 21:40):
m not sure how to handle this
Rob Hausam (Jan 20 2020 at 21:48):
My first take on it is that if it's an example or preferred binding in the base that is being bound differently in the profile, that the validation message against the base spec shouldn't be generated (or if generated, not shown). The base message won't add anything except confusion (as seems to be the case here).
Grahame Grieve (Jan 20 2020 at 21:55):
the validator doesn't know, when validating against the base spec, what other validations are in it's future...
John Moehrke (Jan 20 2020 at 22:05):
I would be happy with a IG specific override to hide the message. This would be an explicit act to hide the message based on doing the analysis that it is indeed working as expected. Note that the info message should indicate that the value was found within the IG specified valueset... right?
However the message being thrown isn't a warning, so I can't hide it... right?
Lloyd McKenzie (Jan 20 2020 at 22:06):
I've been suffering from this for a few years. My ideal is that if we validate against a profile of the resource, we don't validate against the resource itself (on the grounds that the profile will inherit all of the rules from the resource except for those it's allowed to override, in which case, we shouldn't be checking against those rules.
Patrick Werner (Jan 20 2020 at 22:24):
However the message being thrown isn't a warning, so I can't hide it... right?
its only an information in the java validator. But i agree a misleading one.
Patrick Werner (Jan 20 2020 at 22:26):
I've been suffering from this for a few years. My ideal is that if we validate against a profile of the resource, we don't validate against the resource itself (on the grounds that the profile will inherit all of the rules from the resource except for those it's allowed to override, in which case, we shouldn't be checking against those rules.
+1
If a snapshot of the profile is provided this is easy to do (if none is provided, we create one). But i think the problem starts when we chain validators like hapi does.
Grahame Grieve (Jan 20 2020 at 22:26):
given the nature of 'preferred' it seems like it would be better to make it a warning against a profile that differs, rather than an instance. But I don't really know how to do that - checking a value set against a value set and deciding whether they are meaningfully different is harder
Patrick Werner (Jan 20 2020 at 22:26):
one validator checks against base, one against the profile(s)
Grahame Grieve (Jan 20 2020 at 22:27):
the java validator does both internally. Partly because I am not fully confident in the snapshot generator enforcing the logical rules correctly. not all of them are in it's perview to resolve
Patrick Werner (Jan 20 2020 at 22:29):
Hmmm then we would some logic to look at all terminology bindings, and create a list of bindings which the validation against core should skip
Patrick Werner (Jan 20 2020 at 22:31):
skip: example->"*," preferred-> required/extensible
Grahame Grieve (Jan 20 2020 at 22:32):
already skips example
Patrick Werner (Jan 20 2020 at 22:32):
preferred only should produce an error if the derived profile is binding it to example. Which is a check on the profile, not the instance.
Grahame Grieve (Jan 20 2020 at 22:33):
preferred only should produce an error if the derived profile is binding it to example
?
Patrick Werner (Jan 20 2020 at 22:35):
the core resource has a preferred binding, a profile on this resource type binds to example. But that's an error which should be thrown when validating the profile, not a instance.
Patrick Werner (Jan 20 2020 at 22:36):
Could also be thrown when an instance is validated, to be safe.
Patrick Werner (Jan 20 2020 at 22:37):
required should be always checked, extensible as well
Patrick Werner (Jan 20 2020 at 22:39):
so the only new check would be to have a look at the same ValueSet binding in the base and the derived profile an add it to a skipIt List for the Validator validating against the base StructureDefinition
Lloyd McKenzie (Jan 20 2020 at 22:46):
The warning should be thrown if you're validating against the core resource. The issue is if you're validating against a profile, you shouldn't be spitting out issues related to validating against the resource
Grahame Grieve (Jan 20 2020 at 23:03):
it's almost like you didn't read what I wrote
Lloyd McKenzie (Jan 20 2020 at 23:51):
I don't know what you mean by "meaningfully different". If the new value set expansion contains codes that aren't in the original preferred value set expansion, that's a meaningful difference. If you can't expand either (or it's two expensive to check), you can spit out an info message saying that when checking the profile.
Patrick Werner (Mar 15 2020 at 13:00):
@Grahame Grieve i also now have a customer which really dislikes these validation messages as they are confusing users. I gave the issue another thought and came up with a very basic solution:
Adding a mode to the Validator which allows you to:
- validate everything and report all messages as it is now
- when validating against a base spec profile, suppress infos
- when validating against a base spec profile, suppress infos & warnings
Lloyd McKenzie (Mar 15 2020 at 15:13):
We have an ability now to suppress specific infos and warnings present in a text file - and those can be generic messages or messages tied to a specific location.
Patrick Werner (Mar 15 2020 at 15:52):
This is only possible in the IG creator, i'm talking about the Validator.
Patrick Werner (Mar 15 2020 at 16:01):
Also this is based on a String comparison, which works in an stable IG but would be hard to implement for Validations where we don't know the Instance which a user will be validating.
Lloyd McKenzie (Mar 15 2020 at 20:55):
I believe the validator lets you pass in a file too. Agree that if you don't know the instance, the best you could do is suppress an error independently of where it appears, but that's still better than suppressing all of them
Grahame Grieve (Mar 15 2020 at 21:05):
what specifically is it that they dislike?
Patrick Werner (Mar 16 2020 at 12:35):
They dislike that they get infos and warnings for preferred and extensible bindings against the base profile.
Patrick Werner (Mar 16 2020 at 12:36):
Even if their specific profile has a required binding
Lloyd McKenzie (Mar 16 2020 at 13:19):
I think there's universal dislike for that. When there's a child profile, we shouldn't be validating the constraints of the parent resource. But that's not so straight-forward to do.
Patrick Werner (Mar 16 2020 at 13:28):
thats why i proposed my simple approach above.
Patrick Werner (Mar 16 2020 at 13:28):
Adding a mode to the Validator which allows you to:
validate everything and report all messages as it is now
when validating against a base spec profile, suppress infos
when validating against a base spec profile, suppress infos & warnings
Patrick Werner (Mar 16 2020 at 13:30):
so there can be an option to skip the adding of a info/warning created when validating against a base profile
Patrick Werner (Mar 16 2020 at 16:44):
Ideally the validator should be rewritten with layers knowing of each other. But that would be a lot! of of work. So i'm searching for a quick and a little dirty solution.
Patrick Werner (Mar 30 2020 at 20:16):
Patrick Werner said:
Adding a mode to the Validator which allows you to:
validate everything and report all messages as it is now
when validating against a base spec profile, suppress infos
when validating against a base spec profile, suppress infos & warnings
would this make sense to add to the Validatorcode (as an optional mode) ?
Last updated: Apr 12 2022 at 19:14 UTC
