Stream: terminology
Topic: Validation for foreign language resources
Simone Heckmann (May 12 2018 at 15:01):
As discussed during the inoffical break-out-session at the WGM: GF#16586
When validating a resource/code validators currently match both code and - if present - display.
However, assuming that an english server has ValueSet expansions with english display values and a french server has ValueSet expansions with french display values, validation will fail as soon as resources are exchanged between english and french systems.
To resolve this, following a discussion with Rob Hausam, Ewout Kramer, Richard Ettema, Patrick Werner and me, the proposed solution is that any server should validate display values only if the value of Resource.meta.language matches it's own configuration. If not, the validator should only validate the codes and disregard the display values.
Open for discussion: what's the impact - if any - on $validate-code?
Grahame Grieve (May 12 2018 at 15:11):
I don't agree with that particular solution
Grahame Grieve (May 12 2018 at 15:12):
the validate-code operation can take a display language parameter - that should take priority
Grahame Grieve (May 12 2018 at 15:12):
if there is none, and no expansion profile (which can also specify this)
Grahame Grieve (May 12 2018 at 15:12):
then ok, which Resource.meta.language?
Yunwei Wang (May 12 2018 at 15:31):
"If not, the validator should only validate the codes and disregard the display values." I don't agree with that because if server return true in such situation, the client would assume the display text in the request is correct. If the server cannot validate the correctness of display text, the server should return false with error message that display text could not be validated.
Grahame Grieve (May 12 2018 at 16:08):
so, the server is validating in a language from this cascade:
- specified language parameter
- language specified in expansion profile
- language specified in value set
Grahame Grieve (May 12 2018 at 16:09):
but what's the relationship between that and specified language displays in the value set itself?
Grahame Grieve (May 12 2018 at 16:09):
note that ValueSet.compose.concept.display is a designation in ValueSet.language
Grahame Grieve (May 12 2018 at 16:10):
it's a harder question when the server can't validate the display
Rob Hausam (May 12 2018 at 16:18):
Yes, I think the genesis of the original issue is that in a particular instance Coding.display is a German description that is valid in the code system, but the validator is rejecting it because by default it expects that Coding.display is an English term.
Grahame Grieve (May 12 2018 at 16:20):
it was gold that it's in german? is it my validator?
Simone Heckmann (May 12 2018 at 16:20):
I don't think that we can expect servers to have ValueSet designations in all possible languages, just in case they receive a foreign resource. So how should a spanish server decide wether a chinese display code is correct? Isn't it the purpose of having codes in the first place, that we can have the same understanding of concept, regardless of language?
Grahame Grieve (May 12 2018 at 16:25):
yes that's why I don't make it an error, just a warning
Simone Heckmann (May 12 2018 at 16:39):
so, the server is validating in a language from this cascade:
- specified language parameter
- language specified in expansion profile
- language specified in value set
How does the language of the instance (meta.language) influence the behaviour of the validator?
Simone Heckmann (May 12 2018 at 16:53):
Sorry, it's Resource.language, not Resource.meta.language....
Simone Heckmann (May 12 2018 at 17:52):
pasted image
Here's our problem
Simone Heckmann (May 12 2018 at 18:00):
I think a validator should only enforce matching display values, if the resource is in a language it supports (= has the appropriate expansions for). Or should mismatching display values alway be warnings regardless of language?
Grahame Grieve (May 12 2018 at 20:44):
ok so the language here is a bit confusing between the validation engine and the terminology server. I was talking about the terminology server where the resource.language is not known. The validation engine should pass the language of the resource as a parameter to the $validate-code operation
Simone Heckmann (May 12 2018 at 20:46):
In the light of this: Does it make sense to enforce language in national profiles ?
Grahame Grieve (May 12 2018 at 20:47):
that's a difficult question indeed. Enforcing language is problematic, I think.
Grahame Grieve (May 12 2018 at 20:47):
(as is also not enforcing it)
Simone Heckmann (May 12 2018 at 20:56):
where do you see problems?
Grahame Grieve (May 13 2018 at 05:42):
well, if you enforce language in the national profile - all resources must be in de-DE - is that really something you can enforce? that all use of FHIR in DE must be in de-DE? what about cross-border stuff? I think that would just create a giant administrative headache for everyone
Grahame Grieve (May 13 2018 at 05:42):
further, are all code systems available in german language? what happens if they're not?
Michael Lawley (May 17 2018 at 00:49):
As we've interpreted the $validate-code specification, a display value that is not any of the designations for the code results in result=false
There is no clear guidance on this in the spec (AFAICT) beyond "result = true if the concept details supplied are valid"; ie no details on what "valid" means
Grahame Grieve (May 17 2018 at 04:26):
guess we should settle on this - can you create a task?
Michael Lawley (May 17 2018 at 05:08):
Rob Hausam (May 17 2018 at 05:09):
Thanks, Michael.
Yunwei Wang (May 17 2018 at 22:50):
I used to think that if display is provided, it must be validated. But after reading the spec again, no where says so.
Grahame Grieve (May 18 2018 at 03:28):
yes. doesn't say you can't. because in practice, it's tricky. In the spec validation, it has to be correct. In other contexts, I let the user specify
Last updated: Apr 12 2022 at 19:14 UTC
