Stream: hapi
Topic: Issue with JPA terminology validation for SNOMED
Morten Ernebjerg (Aug 20 2021 at 08:35):
I am working on a validation service that is based on the HAPI JPA starter and am seeing spurious validation errors. The problem arises when SNOMED codes are not available and I validate against a profile which has a required binding to a value set that contains SNOMED codes (e.g. this profile from the German GECCO IG). I have been going in debugging circles trying to find the best solution or workaround, so I'm hoping someone out there has experience with this.
In my service, the user can independently configure whether to load SNOMED and LOINC into a DB. Any loaded system is then available for validation through a validation support inheriting from ca.uhn.fhir.jpa.term.TermReadSvcR4. The validation behavior I want is this:
- If a code system X (SNOMED or LOINC) is loaded, the validator should (i) validate individual codes from X, and (ii) validate required binding to value sets containing codes from X.
- If X is not present, the validator should suppress both these checks (possibly issuing a warning ).
However, what I am seeing when SNOMED is not loaded and I validate a valid instance against a profile with a required bindings to value sets with SNOMED is the following:
- If I query right after the service starts and before the scheduled value set expansion jobs run, I only get warnings (OK, what I wanted)
- However, if I let the expansion job run and then query, I get validation errors from checks of type( ii): "The code provided [CODE] is not in the value set [VS URL], and a code from this value set is required: Unknown code [CODE]".
From my debugging, what seems to happen is this:
- The value set expansion module still expands value sets containing SNOMED codes, leading to ValueSets that are internally flagged as "expanded" but have empty expansions because the actual SNOMED codes are not available.
- The validation code now tries to check codes against these "pseudo-expanded" value sets when it encounters a required binding to them.
- Obviously not finding any matches in the empty expansions, it generates a validation error.
This might be specific to SNOMED: I was puzzled by the fact that the expander thinks it knows SNOMED even though it is not loaded. Debugging, I traced this down to the fact that the core spec contains a CodeSystem resource for SNOMED (albeit with no explicit concepts, of course). The expansion module find this resource and then continues instead of returning with an error. Indeed, with the expansion option isFailOnMissingCodeSystem set to "true" (default), and loading the GECCO 1.0.4 package, I get a bunch of "Unknown code system URI" errors (e.g. for LOINC) when expanding but none for SNOMED.
This behaviour, if correct, seems strange, but I am unsure whether this is a real bug or whether I am just setting up things wrong. Any tips on how get around this?
Oliver Egger (Aug 20 2021 at 13:02):
@Morten Ernebjerg We experienced the same behaviour. If the ValueSet is not expanded the InMemoryTerminologyServerValidationSupport is used which verifies the codes we provide with the IG and leaves the external codes systems out. To disable the expansion (because at the moment we want to be based on InMemoryTerminologyServerValidationSupport) we set the defer_indexing_for_codesystems_of_size property to 0 and overwrite the expand task.
Morten Ernebjerg (Aug 20 2021 at 13:50):
@Oliver Egger that seems to work in our case, too :confetti: Thank you so much! - saved me from heading into the weekend with my head stuck deep in some call stack :smile:. Was there any discussion of how to potentially modify HAPI to avoid this behavior in the first place?
Oliver Egger (Aug 20 2021 at 14:02):
not that i am ware off, i was also just debugging it like you to understand what was going on :-) and was not thinking of it as a wrong behaviour in the first place
Jens Villadsen (Aug 20 2021 at 14:04):
Wanna do a PR to the starter project that examplifies how SNOMED is 'best' used/explains behaviour?
Jens Villadsen (Aug 20 2021 at 14:05):
Would that make sense?
Patrick Werner (Aug 20 2021 at 14:25):
Hmm, wouldn't just skipping expansions/or don't persist them for VS with 0 concepts solve the issue?
Morten Ernebjerg (Aug 20 2021 at 14:31):
@Patrick Werner Yes, I was thinking about a possible solution along those lines but did not manage to figure out how it could be done (at least not without touching core HAPI code). If I understood my own debugging right, it seems the validator has some weird behavior:
- Trying to expand value sets in cases where it does not actually have access to the needed codes (e.g. in the case of SNOMED where it only has a "dummy" CodeSystem resource) - and not flagging the outcome as not suitable for validation
- Trying to validate codes in fields with a required binding against expanded value sets even if the expansion is actually empty.
I think a solution/fix that somehow gets to these deeper issues would be preferable. Having said that, though, I think it would be very valuable to have some guidance on how to deal with this while in the current state, cf. @Oliver Egger 's tip above.
Patrick Werner (Aug 20 2021 at 14:36):
Adding a check to the VS expansion code in hapi if the/one of the CodeSystem(s) is empty/ or not available and then skipping the expansion shouldn't be too hard. @James Agnew ?
Patrick Werner (Aug 20 2021 at 14:39):
ad 2.: if 1. is implemented, this shouldn't be needed anymore. But maybe also a good idea, as an empty VS more or less useless for validation (apart from checking CS.urls)
Last updated: Apr 12 2022 at 19:14 UTC
