Demonstrate RemoteTerminologyServiceValidationSupport

[chrisroederucdenver]

AFAIK, it's possible to have a HAPI FHIR server used for content to use a second HAPI FHIR server acting as a terminology server. https://hapifhir.io/hapi-fhir/docs/validation/validation_support_modules.html#remoteterminologyservicevalidationsupport Figure out if we need this HAPI module, and regardless, set up a pair of servers and demonstrate this capability.

Script the setup and script a test run and validation. That is, a single script should be set this up, run it, get results and have simple output that declares success or failure.

[joeflack4]

From the page:

This module validates codes using a remote FHIR-based terminology server. This module will invoke the following operations on the remote terminology server:

GET [base]/CodeSystem?url=[url] – Tests whether a given CodeSystem is supported on the server GET [base]/ValueSet?url=[url] – Tests whether a given ValueSet is supported on the server POST [base]/CodeSystem/$validate-code – Validate codes in fields where no specific ValueSet is bound POST [base]/ValueSet/$validate-code – Validate codes in fields where a specific ValueSet is bound

I wonder why HAPI has appeared to allow for remote validation but not remote proxy calls in general? Or maybe they have and it's in the docs somewhere?

[joeflack4]

http://fhir.org/guides/stats/ - Terminology IG / server index. Good source of IGs and content that we might want to load into TIMS server. We could also potentially proxy to some of these servers, if we want to do federation like that.

[chrisroederucdenver]

Can. you more clearly explain by what you mean by "proxy"? Is this where a data-server offloads terminology to a second server, or where a terminology passes requests it can't fulfill to a 3rd server?

To one way of thinking the first isn't quite proxying because the requests are different.....

[joeflack4]

I would call both of those proxy calls! Maybe you're right about semantic nuance, because the requests may be different. Probably not worth going too much into the weeds on this, but I would consider both of your examples to be passing the same request (in terms of FHIR resource endpoint and URL query params) from one server to the next. In your first case, it's a matter of intention, and in the second case, sounds like a matter of exception handling.

[chrisroederucdenver]

It's all in the weeds.

Proxy comes from voting where one person votes in place of another person. When nginx is set up as a proxy server, instead of a user/web-client getting served directly by the web server, the proxy, nginx, stands in the middle. It accepts an http request and passes the same to the web server.

A terminology server getting a request for a terminology resource that it can't fulfill might send the same request to the next server and then just pass the result back up stream.

When a FHIR server setup as a clinical data server w/out local terminologies gets a request, it will involve posting or putting a non-terminology resource that then requires a terminology resource. So it makes a request to the terminology server. They are different servers, and different requests.

The distinction is important because we've talked about doing proxying (as I've outlined here) between layers of terminology servers to avoid having to load all of THO onto a server...and passing the requests down the line. I've caught a glimpse of how to separate clinicial and terminology servers, but how to do this kind of proxying. I'm not saying it doesn't exist, just that it seems different from the first and I haven't seen how to do it. I genuinely hope we find out how and can demonstrate it. Washing to two together would make it easy to assume they are the same and that they both work.

[chrisroederucdenver]

For the immediate future (Jan '23) we should restrict our focus to the remote validation support module and table proxying or federation. I don't want to discourage exploratory reading etc., just focus execution.

Speculating about the limited interface from clinical data server to terminology server to just the $validate operations, I'd point out, you can still hit the terminology server directly for the other operations. The interface above probably remotes only what the main server's validation operations require.

Having the main server route all terminology requests over is really flexible, but could be a performance burden. Not routing forces the outside world to know about the two servers and use them independently, reducing the run-time burden, while adding a configuration burden.