Resource validation does not respond with error when a code is not found in a Remote Terminology system

[codeforgreen]

[dotasek]

Could you provide an example?

If this involves validating a resource, it will likely be possible to replicate via a fhir-test-cases entry: https://github.com/FHIR/fhir-test-cases/blob/master/validator/manifest.json

I can help with this process if provided with example resources, code systems, etc.

[dotasek]

After a discussion with @codeforgreen, the problem is that some terminology servers do not return issues for code validations.

{
    "resourceType": "Parameters",
    "parameter": [
        {
            "name": "result",
            "valueBoolean": false
        },
        {
            "name": "code",
            "valueCode": "10xxxxx"
        },
        {
            "name": "system",
            "valueUri": "http://terminology.hl7.org/CodeSystem/icd9cm"
        },
        {
            "name": "message",
            "valueString": "Unknown code '10xxxxx' in the CodeSystem 'http://terminology.hl7.org/CodeSystem/icd9cm' version '1.0.0'; The provided code 'http://terminology.hl7.org/CodeSystem/icd9cm#10xxxxx' was not found in the value set 'http://fhir.infoway-inforoute.ca/io/psca/ValueSet/ICD9CM%7C1.0.0'"
        }
    ]
}

In this case, the InstanceValidator has no issues to process from the server, and will not report any problems for the validation.

Making a unit test for this can't be done in fhir-test-cases, because all of the tests hit a conformant server, which will always return the expected issues. I will try to code something that simulates this via mocks.

[grahamegrieve]

That doesn't make sense - the code validation still returned false, so there should be an resulting ValidationMessage

But on the other hand, we do not support non-compliant terminology servers so this issue should be closed

[codeforgreen]

According to the FHIR spec, issues can be missing from the output for versions prior to R5. e.g. https://hl7.org/fhir/R4/valueset-operation-validate-code.html I am not sure what you mean where by "non-compliant". Can you explain?

[dotasek]

I'm reading the spec the same way. R4 doesn't specify an issues property.

http://tx.fhir.org/r4/CodeSystem/$validate-code? returns issues though, which seems contradictory.

[codeforgreen]

There is a test in hapi-fhir testValidateResourceContainingLoincCode which will fail if in the issues are not populated in the mocked validator in addMockedValueSets. A similar test can be added to the org.hl7.fhir.validator library. This would ensure backward compatibility for validators (Remote Terminology) which don't have issues populated in the response.

[grahamegrieve]

Terminology services that support the validator must conform to the requirements (and test cases) documented here: https://github.com/FHIR/fhir-test-cases/tree/master/tx. And yes, that includes some things that are not defined in R4, only later.

I'm happy to look at this case, because in this case, the lack of an issues shouldn't be a factor. However in general, some things we might just say, not a compliant server, not going to be fixed/supported

[codeforgreen]

Sorry for the late response on this thread. At the moment the Remote Terminology server we were using (Ontoserver) does return issues in the response of the validate-code call for version R4.

We've performed a backport of this part of the R5 spec (populate issues in the response) into the R4 translation layer that we have. It seems to fix the issue.

However if there are usages of any other remote terminology servers that will not return issues for versions earlier than R5, this bug will still be present. Unfortunately I did not have a chance to test and see if this is the case.

I leave it up to you if you'd like to add this test case and restore the behaviour back. Feel free to close this issue otherwise. Thank you for the prompt response.

[codeforgreen]

One more thing I wanted to add. I see that the validation module runs on R5. It's possible to canonicalize prior versions to R5 using hapi-fhir-converter. I'd like to make a point that when we do rely on R5 only features or changes (in this case issues in the validate-code response), we need to ensure that the (client/calling) library that performs the version translation is also updated to be in sync with that assumption. Please consider this in the future to help prevent issues. cc: @dotasek

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 5 days if no further activity occurs. Thank you for your contributions.