Stream: terminology
Topic: Change to validator use of terminology server
Grahame Grieve (Jan 10 2020 at 07:12):
I've had to introduce a new parameter to $validate-code when the java validator uses the terminology server. The problem relates to CodeableConcepts with multiple codes, one of which is valid and one of which is unknown. The validator now adds a valueSetMode parameter with possible values of CHECK_MEMERSHIP_ONLY and NO_MEMBERSHIP_CHECK
- CHECK_MEMERSHIP_ONLY - only called with a CodeableConcept, and indicates not to validated each coding, simply to check that one of them is in the value set
- NO_MEMBERSHIP_CHECK - only called with a Coding, and indicates that value set membership has already been tested, and just to check the coding details. Note that the value set is still provided, so that version / display etc can be checked if possible
@Michael Lawley. I don't know if anyone else needs to respond to this. Note that this change is immediate (including with the IG publisher). The consequence of not making this change is that any users using an alternate to tx.fhir.org will find that alternate codings are considered invalid
Yunwei Wang (Jan 10 2020 at 14:50):
@Grahame Grieve Are you proposing adding a new parameter to $validate-code operation?
Grahame Grieve (Jan 10 2020 at 17:52):
I'm not sure. I just know what I had to do in the validator
Yunwei Wang (Jan 10 2020 at 18:10):
According to $validate-code operation, only one coding in a CodeableConcept need to be valid. The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present. So what is point to add that CHECK_MEMBERSHIP_ONLY ?
Rob Hausam (Jan 10 2020 at 19:09):
I had the same question. It seems like we just want to be sure that is the behavior, and then CHECK_MEMERSHIP_ONLY wouldn't be needed? I think I can see why the NO_MEMBERSHIP_CHECK (or equivalent to it) still may be needed to be able to turn on and off the value set membership check for a Coding.
Grahame Grieve (Jan 10 2020 at 19:37):
so there's a couple of issues. Say you have a CodeableConcept that contains 2 codings. One is valid and is in the required value set. The other is invalid - it contains a code that does not exist in the specified code system
Grahame Grieve (Jan 10 2020 at 19:37):
$validate-code will fail. As it should.
Grahame Grieve (Jan 10 2020 at 19:37):
but the problem isn't that the value set requirement hasn't been met.
Grahame Grieve (Jan 10 2020 at 19:38):
for the validator, which is validating both the CodeableConcept, and also each Coding, it needs to tell the terminology service what to do, so that the errors are reported in the correct place
Rob Hausam (Jan 10 2020 at 19:39):
Fair point. Makes sense.
Reece Adamson (Jan 10 2020 at 20:22):
Will the Validator Documentation be updated to reflect this? This documentation also doesn't mention TerminologyCapabilities which appears to be required. I'd be happy to contribute to the documentation, but not sure if I'm allowed to edit it directly or if I'm informed of everything that needs to be there. If I can though let me know!
Much appreciation for your work on this!
Grahame Grieve (Jan 10 2020 at 20:32):
well, i was wondering about that last night. This is not part of the 'how to use the validator documentation', so it doesn't belong there. But it does need documenting, along with a couple of other things
Yunwei Wang (Jan 10 2020 at 20:48):
$validate-code will fail. As it should.
@Grahame Grieve Why the $validate-code should fail?
Grahame Grieve (Jan 10 2020 at 20:56):
because one of the codes is invalid
Jim Steel (Jan 30 2020 at 01:59):
I hope that typo is only in this thread, not in the implementation :wink:
Jim Steel (Jan 30 2020 at 02:04):
I don't quite follow why its important that these calls to $validate-code, with an invalid (presumably non-existent) code somewhere in the CodeableConcept, should return true
Jim Steel (Jan 30 2020 at 02:05):
For NO_MEMBERSHIP_CHECK on Codings, could this not be done with CodeSystem.$validate-code?
Jim Steel (Jan 30 2020 at 02:07):
The possibility of the display being overridden in the ValueSet seems to be discounted for use in a Coding by the ValueSet descriptive text that says Any display name for a concept provided in the value set is for display to a human user. The display in the Coding that results from a user selecting a concept from the expansion must be taken from the underlying code system definition, even if a value set is referenced explicitly in the Coding (e.g. by an extension).
Grahame Grieve (Jan 30 2020 at 02:08):
hmm well we are not conforming to that in practice
Grahame Grieve (Jan 30 2020 at 02:19):
in particular affiliates are using value sets to do language translations in versions prior to supplements being avialable
Jim Steel (Jan 30 2020 at 02:29):
Could the CodeableConcept case not be handled by the client (in this case the validator) sending separate validate-code requests for each of the codings inside the CodeableConcept?
Michael Lawley (Jan 30 2020 at 02:33):
I agree -- this really seems like pushing special-case client side semantics into the server rather than using the existing API semantics in a more explicit manner.
Grahame Grieve (Jan 30 2020 at 02:38):
it does to validate-code for each of the codings, yes.
Grahame Grieve (Jan 30 2020 at 02:38):
initially I didn't pass the value set in for those requests. but then there's the pesky translation issue, so you still need the value set - hence the 'don't validate the value set membership' flag
Grahame Grieve (Jan 30 2020 at 02:39):
also, the terminology server gets to validate the whole codeable concept as well, so it can say, for instance, 'these translations are invalid' and also so it can validate the binding as a whole. But I don't want it to validate the codings individually since I'm going to call validate-code on each of them as well
Michael Lawley (Jan 30 2020 at 03:16):
I'm still trying to understand the drivers here. I get why you need the ValueSet to check the display, but why, in that case, do you want to prevent a membership test?
Michael Lawley (Jan 30 2020 at 03:30):
For CHECK_MEMERSHIP_ONLY (sic) semantics, why not just strip the display text from the CodeableConcept before doing the $validate-code call? Then the Tx won't have anything other than the codes to validate.
Jim Steel (Jan 30 2020 at 03:31):
I guess it may still do some "are these multiple codings valid translations of each other" checks
Michael Lawley (Jan 30 2020 at 03:34):
but valid translations based on what criteria?
Jim Steel (Jan 30 2020 at 03:34):
That's up to the tx server
Jim Steel (Jan 30 2020 at 03:35):
From the spec for ValueSet.$validate-code.codeableConcept: The server returns true if one of the coding values is in the value set, and may also validate that the codings are not in conflict with each other if more than one is present
Grahame Grieve (Jan 30 2020 at 04:38):
yes
Grahame Grieve (Jan 30 2020 at 04:39):
why, in that case, do you want to prevent a membership test
because there may be multiple codings, and only one of them needs to be in the value set. the validator doesn't know which one
Jim Steel (Jan 30 2020 at 04:40):
Wait, isn't NO_MEMBERSHIP_CHECK for a Coding
Grahame Grieve (Jan 30 2020 at 04:48):
yes.
Yunwei Wang (Jan 30 2020 at 19:03):
I am still confused. I think that by default, the validator and/or tx server should check membership only. According to the CodeableConcept data type A typical use of CodeableConcept is to send the local code that the concept was coded with, and also one or more translations to publicly defined code systems such as LOINC or SNOMED CT. In such "typical" use, the server does not know the local code (very possible).
Grahame Grieve (Jan 30 2020 at 19:08):
of course. but it may know some of the codes and be confident that they are not equivalent.
Grahame Grieve (Jan 30 2020 at 19:14):
at present tx.fhir.org does not do anything like this anywhere
Grahame Grieve (Feb 03 2020 at 04:19):
is this closed, or do we need to some face to face on this?
Grahame Grieve (Feb 03 2020 at 04:19):
mainly that's a question for @Jim Steel and @Michael Lawley
Jim Steel (Feb 03 2020 at 04:19):
I think we might need some face to face
Jim Steel (Feb 03 2020 at 04:21):
I think I got talking with @Michael Lawley was that I was comfortable that there was some need, but I still needed some clarity on whether one or other case might not already be doable by other means, and it not then just getting comfortable that the proposed approach was the right fix. I can't speak for @Michael Lawley 's opinion :)
Grahame Grieve (Feb 03 2020 at 04:24):
break out room at 4pm?
Lloyd McKenzie (Feb 03 2020 at 04:30):
Presentations start at 4...
Grahame Grieve (Feb 03 2020 at 04:30):
I know
Reece Adamson (Sep 09 2020 at 22:04):
@Grahame Grieve what was the outcome of this? Primarily curious if the validator is expecting support for this behavior (CHECK_MEMBERSHIP_ONLY) and, if so, where it is documented.
Grahame Grieve (Sep 09 2020 at 22:19):
it presently is, yes, and is only documented here.
Grahame Grieve (Sep 09 2020 at 22:20):
It's on my to do list to rework this after corridoor discussion back in Sydney
Michael Lawley (Sep 10 2020 at 01:31):
Attempting to summarise the gist how to avoid the need for these (reiterating some of the above comments):
- NO_MEMBERSHIP_CHECK says to validate code in context of a ValueSet (picking up code system version, if any, from the valueset, and also any alternate display text). My understanding is that this is only every called when membership is known to be true, so it is only an optimisation and doesn't affect the actual response.
- CHECK_MEMBERSHIP_ONLY behaviour is identical to the normal behaviour iff the contained Codings have no display text.
Note, the behaviour documented for validating codeableConcept does not say it should also fail if any of the included Codings is invalid, only that at least one (valid?) Coding is in the ValueSet. Optionally also that the Codings do not conflict.
Grahame Grieve (Sep 14 2020 at 05:50):
the solution we discussed in Sydney is to change the output of the validate-code operation so that the validator knows what path in the CodeableConcept that the errors come from. It's still on my list to prototype that
Grahame Grieve (Sep 14 2020 at 05:50):
this would avoid the rather curly need to partially ignore the value set
Last updated: Apr 12 2022 at 19:14 UTC
