How to use a remote terminology server for validation

[Xander]

We have downloaded and set up the hapi-fhir-jpaserver-starter project locally. Our goal is to validate files against the remote terminology server https://tx.fhir.org/r4. 

We've been informed by someone more knowledgeable about hapi fhir that this will require changing something in the Java code, but they did not say what that was.

I'd assume we need to change something in the RepositoryValidationInterceptorFactoryR4 class.

P.S. This may be a stupid question, but we will ultimately need to validate our files against the SNOMED CT Belgium codeset. The homepage of the above remote server says it "supports" this system. Does this mean the remote server already includes the codeset and will validate against it, or will we also need to upload the terminology to the local JPA server via the CLI tool?

[Xander]

Update: I found this class concerning remote terminology validation. Could this be what I need? And if so, where should it be instantiated and used?

Op donderdag 10 augustus 2023 om 11:14:31 UTC+2 schreef Xander:

[Patrick Werner]

Yes this would be the class to consume/use an external terminology service.

The default ValidationSupport ist created here: https://github.com/hapifhir/hapi-fhir-jpaserver-starter/blob/8ef50832d3459d4eb35ecb4f116c580475acb59d/src/main/java/ca/uhn/fhir/jpa/starter/common/StarterJpaConfig.java#L106

For testing tx.fhir.org is ok, for productive use I would always go with your own terminology server.

Cheers

Patrick

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/ac7562b2-c46f-4f75-90e8-4c096ffa2349n%40googlegroups.com.

[Xander]

Thank you for the reply, Patrick.

How should I change the code so that the CachingValidationSupport Bean will use RemoteTerminologyServiceValidationSupport? My first thought was something like this:

@Primary
@Bean
public CachingValidationSupport validationSupportChain(JpaValidationSupportChain theJpaValidationSupportChain) {
  theJpaValidationSupportChain.addValidationSupport(new RemoteTerminologyServiceValidationSupport(fhirContext, "https://tx.fhir.org/r4/"));
  return ValidationSupportConfigUtil.newCachingValidationSupport(theJpaValidationSupportChain);
}

Adding it in the validationSupportChain() method itself is impossible since it requires the FhirContext in RepositoryValidationInterceptorFactoryR4.

Should I call the validationSupportChain() method directly in the build() method?

My apologies, I am a novice to hapi fhir (and Spring Boot, for that matter).

Op donderdag 10 augustus 2023 om 14:49:14 UTC+2 schreef Patrick Werner:

[Xander]

I tried to apply this example with the following in StarterJpaConfig.java:

@Primary
@Bean
public CachingValidationSupport validationSupportChain(JpaValidationSupportChain theJpaValidationSupportChain) {

  var ctx = FhirContext.forR4();

  var defaultSupport = new DefaultProfileValidationSupport(ctx);
  theJpaValidationSupportChain.addValidationSupport(defaultSupport);

  var remoteTermSvc = new RemoteTerminologyServiceValidationSupport(ctx, "https://tx.fhir.org/r4");
  theJpaValidationSupportChain.addValidationSupport(remoteTermSvc);

  return ValidationSupportConfigUtil.newCachingValidationSupport(theJpaValidationSupportChain);
}

I did not get any errors, but how can I know if this code works and the validation actually calls the remote server?

I also saw that in the RepositoryValidationInterceptorFactoryR4 class, the FhirContext is retrieved through a DaoRegistry dependency. Is this the proper way rather than calling FhirContext.forR4()? Should I add a DaoRegistry dependency to the validationSupportChain method?

Op donderdag 10 augustus 2023 om 15:35:27 UTC+2 schreef Xander:

[Xander]

After further research, I now realize the RepositoryValidationInterceptorFactoryR4  class has nothing to do with my use case. The CachingValidationSupport is simply added to the RestfulServer in the restfulServer method. Continuing with the validationSupportChain method from my previous post, I found out through logging that the method is called once near the beginning of the run. Also through logging, I found that, in the restfulServer method, a call to "theValidationSupport.isRemoteTerminologyServerConfigured()" returns false. So the above method does not seem to be working properly. Is there something missing here?

Op maandag 14 augustus 2023 om 17:00:14 UTC+2 schreef Xander:

[Xander]

After continuing to investigate this, I'm in a bind. I don't know what else to do.

As mentioned above, I have altered the validationSupportChain() method in StarterJpaConfig:

@Primary
@Bean
public CachingValidationSupport validationSupportChain(JpaValidationSupportChain theJpaValidationSupportChain, IFhirSystemDao<?, ?> fhirSystemDao) {
FhirContext ctx = fhirSystemDao.getContext();

DefaultProfileValidationSupport defaultSupport = new DefaultProfileValidationSupport(ctx);
theJpaValidationSupportChain.addValidationSupport(defaultSupport);

RemoteTerminologyServiceValidationSupport remoteTermSvc = new RemoteTerminologyServiceValidationSupport(ctx, "https://tx.fhir.org/r4");
theJpaValidationSupportChain.addValidationSupport(remoteTermSvc);

return ValidationSupportConfigUtil.newCachingValidationSupport(theJpaValidationSupportChain);
}

I have also added a new method to create a FhirInstanceModule:

@Primary
@Bean
public IValidatorModule validatorModule(CachingValidationSupport validationSupport) {
return new FhirInstanceValidator(validationSupport);
}

Logging confirms that this method uses the CachingValidationSupport created by the first method. In AppProperties.Validation, I set requests_enabled and responses_enabled to true, so in the restfulServer method, the FhirInstanceValidator above is injected in a RequestValidatingInterceptor, which is injected in the RestfulServer.

if (validatorModule != null) {
if (appProperties.getValidation().getRequests_enabled()) {
RequestValidatingInterceptor interceptor = new RequestValidatingInterceptor();
interceptor.setFailOnSeverity(ResultSeverityEnum.ERROR);
interceptor.setValidatorModules(Collections.singletonList(validatorModule));
fhirServer.registerInterceptor(interceptor);
}
if (appProperties.getValidation().getResponses_enabled()) {
ResponseValidatingInterceptor interceptor = new ResponseValidatingInterceptor();
interceptor.setFailOnSeverity(ResultSeverityEnum.ERROR);
interceptor.setValidatorModules(Collections.singletonList(validatorModule));
fhirServer.registerInterceptor(interceptor);
}
}

But when testing this with a test file which should be validated by the https://tx.fhir.org/r4 server, it returns the same error as when using a DefaultProfileValidationSupport, except with a 422 http code.

Op woensdag 16 augustus 2023 om 14:49:01 UTC+2 schreef Xander:

[Xander]

After adding a Logging interceptor, I found that the RemoteTerminologyServiceValidationSupport does work and sends requests. The 422 error is unrelated. So to add Remote server validation to your starter project, do the following in StarterJpaConfig:

@Primary
@Bean
public CachingValidationSupport validationSupportChain(JpaValidationSupportChain theJpaValidationSupportChain, IFhirSystemDao<?, ?> fhirSystemDao) {
FhirContext ctx = fhirSystemDao.getContext();

DefaultProfileValidationSupport defaultSupport = new DefaultProfileValidationSupport(ctx);
theJpaValidationSupportChain.addValidationSupport(defaultSupport);

RemoteTerminologyServiceValidationSupport remoteTermSvc = new RemoteTerminologyServiceValidationSupport(ctx, "https://tx.fhir.org/r4");
theJpaValidationSupportChain.addValidationSupport(remoteTermSvc);

return ValidationSupportConfigUtil.newCachingValidationSupport(theJpaValidationSupportChain);

}

Perhaps add the following:

@Primary
@Bean
public IValidatorModule validatorModule(CachingValidationSupport validationSupport) {
return new FhirInstanceValidator(validationSupport);
}

And in your application.yaml, add:

tester:
  home:
   name: Local Tester
   server_address: 'http://localhost:8080/fhir'
   refuse_to_fetch_third_party_urls: false
   fhir_version: R4
   validation:
    requests_enabled: true

This should do it.

Op maandag 21 augustus 2023 om 12:10:10 UTC+2 schreef Xander: