Stream: hapi
Topic: isCodeSystemSupported
Kevin Mayfield (Nov 18 2019 at 16:42):
I have a class implementing IValidationSupport and have started to receive UUID's on the isCodeSystemSupported interface.
It's also failing to validate Codes, getting errors like:
The value provided ('official') is not in the value set https://fhir.hl7.org.uk/STU3/ValueSet/CareConnect-NameUse-1 (https://fhir.hl7.org.uk/STU3/ValueSet/CareConnect-NameUse-1, and a code is required from this value set) (error message = Unknown code[official] in system[(none)])
Suspect these are related (will investigate further)
Kevin Mayfield (Nov 18 2019 at 16:43):
believe this is also occurring on
public <T extends IBaseResource> T
fetchResource(FhirContext theContext, Class<T> theClass, String theUri) {
Kevin Mayfield (Nov 18 2019 at 16:46):
The GUID seems to be Constants.CODESYSTEM_VALIDATE_NOT_NEEDED
Kevin Mayfield (Nov 18 2019 at 16:51):
On 4.1.0
James Agnew (Nov 18 2019 at 17:25):
Yup, it would be that constant.
That GUID is used as a standin for the codesystem being validated when a field is being validated that doesn't have an explicit codeystem (i.e. a field that is of type code instead of coding). There will always be a VS URI in that case which scopes what the CS could be.
I don't know that I love the current design of that API- That GUID is confusing I would agree.
Michael Lawley (Nov 18 2019 at 20:55):
I can say that @Jim Steel and I really do not like these false system URIs - since the trigger for these is a code-typed field the system URI should be known and thus should be providable?
Kevin Mayfield (Nov 18 2019 at 22:11):
What I believe is happening:
My isCodeSystemSupported is called and responds false (as CodeSystem = c73c77eb-f4b9-49ae-a5c9-6eb727811615)
So the calling ValidationSupportChain class doesn't then call my validateCode
(line 220 public CodeValidationResult validateCode in ValidationSupportChain
Does IsCodeSystemSupported need changing to also pass over the ValueSetUrl
Kevin Mayfield (Nov 19 2019 at 06:33):
Think this is the issue. DefaultProfileValidation support is trying to Validate the Code but it doesn't understand the ValueSet.
Screenshot-2019-11-19-at-06.32.28.png
Kevin Mayfield (Nov 19 2019 at 06:34):
and so fails
Kevin Mayfield (Nov 19 2019 at 06:36):
My IsSystemSupported fails because the UUID in the image above is passed in as the CodeSystem url
James Agnew (Nov 19 2019 at 19:58):
I can say that @Jim Steel and I really do not like these false system URIs - since the trigger for these is a code-typed field the system URI should be known and thus should be providable?
Well, there is a bit of a chicken and egg thing. When the validator goes to validate Patient.gender all it knows is the code without a system, and the ValueSet that the code is bound to. Sure, the validator could figure out what the system is since there is a valueset binding, but it would have to expand the valueset to do that and then it's basically duplicating the term service's job.
FWIW: the UUID was a solution to a rather glaring bug in HAPI's validator: Prior to 4.1.0, you could omit the system entirely on a Coding field and it would validate correctly if the code was appropriate for the bound VS.
The intent with the UUID was to solve the problem of there being 3 possible states: Code+System provided, Code provided but no system because the field is a code, Code provided but system was left blank in the resource being validated.
Probably the right solution here is to either add a new overload to validateCode, or to create some kind of value type for the system that can distinguish between those 3 states...
Kevin Mayfield (Nov 19 2019 at 20:31):
I beginning to think the problem I'm seeing is an error in UK Profiles and has come to light because of this change.
Grahame Grieve (Nov 20 2019 at 04:44):
@James Agnew I'll do that, and start using it.
Kevin Mayfield (Nov 26 2019 at 09:00):
I think I've found what is causing my issue. In ValidationSupportChain line 213-221
```while(var6.hasNext()) {
next = (IValidationSupport)var6.next();
if (theCodeSystem != null && next.isCodeSystemSupported(theCtx, theCodeSystem)) {
result = next.validateCode(theCtx, theCodeSystem, theCode, theDisplay, theValueSetUrl);
continue label23;
}
ourLog.debug("Chain item {} does not support code system {}", next, theCodeSystem);
}```
The code checks to see if the CodeSystem is supported BUT doesn't check if the ValueSet is supported.
So the validateCode function of the first validator in the chain will always be called.
Kevin Mayfield (Nov 26 2019 at 12:01):
Have worked around this (and also worked the second problem @James Agnew mentions).
James Agnew (Nov 26 2019 at 12:51):
@Kevin Mayfield Interesting... This hasn't been an issue for any "normal" JPA server since there is only one implementation that handles custom codesystems and valuesets (the main term svc). I can see why this logic wouldn't work though if you have anything more fancy.
How did you work around it? Do we need an isValueSetSupported method?
Kevin Mayfield (Nov 26 2019 at 13:38):
It wasn't clean, I reordered my validation chain, moving DefaultProfileValidation support to last. (and then added core fhir support into my first validator).
I think ValidationSupportChain should only call a ValidationSupport class that supports the ValueSet.
Kevin Mayfield (Nov 26 2019 at 13:40):
I say I think - I've had to do some other workarounds with a number of UK profiles, codes and values. So I might have come to this incorrectly.
Last updated: Apr 12 2022 at 19:14 UTC
