Stream: FHIR at Scale (FAST): Exchange with/without intermediaries
Topic: Hostname routing question
Mike Yackanich (Sep 10 2021 at 18:37):
Question re: the "Option 1" scenario that we want to test at next week's HL7 FHIR CAT28. I have our POC acting as intermediary working to extract out hostname and use it to identify the target responder (or next hop). But - I still require a specific port and app path. For example, the following works and gets routed to FHIR.Actor2.org FHIR Server:
http://FHIR.Actor2.org:52774/fhirproxy/fast/r4/Patient/123
but notice that I require a specific port, and also the /fhirproxy/fast/r4 app path - as that is the baseURL of our intermediary service.
Is the expectation that the Actor1 initiator would be sending request as follows?
http://FHIR.Actor2.org/Patient/123 or https://FHIR.Actor2.org/Patient/123
If that is the case - it will be more difficult. The intermediary would have to support default port (80 or 443), and have no app path for it's service. Not sure any intermediary would support that.
Thoughts?
Frank McKinney (Sep 13 2021 at 14:42):
Thanks @Mike Yackanich for digging in to the next level and identifying the challenge.
@Michael McCune , @Eric Heflin , @Patrick Murta , @Durwin Day , @Joe Lamy , others... what are your thoughts?
Mike Yackanich (Sep 13 2021 at 14:46):
I'm looking into using web server redirects to accept whatever comes in on port 80 and routing to our custom port 52774, along with modifying the app path to include our service's required "/fhirproxy/fast/r4" base URL. I can do this only because port 80 on this instance currently isn't being used for any other service.
Michael McCune (Sep 13 2021 at 16:03):
Yes, the path is tricky - as originally conceived, my assumption is the directory accessed by actor 1 (the initiator) to find actor 2 (the final destination) would have a hostname and app path that is appropriate for actor 2 but the hostname would direct the request to the intermediary. That approach would hopefully avoid URL rewriting as the app path would match the destination.
Michael McCune (Sep 13 2021 at 16:13):
The hostname string (which routes to the intermediary)could be standardized to convey port and/or path information for the intermediary but you would likely need to use dashes in the hostname. For example, FHIR-stdport-Rfour.actor2.org. With this approach, we would need to have a standard port available (like port 80) so that the hostname information could be interpreted by that listener.
Michael McCune (Sep 13 2021 at 16:15):
otherwise, actor 1 would need to convey information for the intermediary using headers or the app path (or something along those lines) which is what we were trying to avoid.
Mike Yackanich (Sep 13 2021 at 16:30):
This is getting really tricky.
If we want the fullURL values to NOT need to be re-written, then we'd need the original request from the initiator (Actor1) to look exactly like the ultimate responder wants it to look: hostname, port, apppath - all of it. But what if the ultimate responder uses something other than 80 or 443? Would an intermediary then effectively have to support any/all ports?
For example:
Actor2 endpoint is https://mikey.healthcare.org:59500/mikecare/fhir/r4.0.1
If we want the initiator Actor 1 to be able to use URL values returned by Actor2 through an intermediary, then the request would be sent by Actor1 to Intermediary1 as https://mikey.healthcare.org:59500/mikecare/fhir/r4.0.1/Patient/123 (for example). This means Intermediary 1 would have to be listening on port 59500 for requests.
Now extrapolate out the fact that target responders may all have different ports - and you can see that the Intermediary would be in a position of having to listen on ALL of those ports.
I don't see that being feasible.
Joe Lamy (Sep 13 2021 at 19:37):
For Mike's question, DNS alone wouldn't take care of the "no URL rewriting" need: https://webmasters.stackexchange.com/questions/55123/can-dns-point-to-specific-port. So yes, if any ultimate responders use specific ports in their FHIR base URL, then the intermediary would have to listen on those ports. But not all ports, just the ones needed by responders.
Have we nailed down what are actual requirements vs. nice to haves? Specifically the following:
- MUST use the same mechanism for all hops
- Mechanism MUST work without requiring rewriting of URLs
If neither 1 or 2 are real SHALLs, then each hop can be entirely independent, and something like the eHx idea of query strings should be ok for its A->B hop if their clients agree to it. The B->C hop can be converted to app path routing , X-Dest, etc. The only implied end-to-end requirement I see is that each ultimate responder has an address that is knowable/discoverable at each hop.
If #1 is nice to have and #2 is real, then I'm envisioning a situation A->B->C->D, where B claims conformance to this IG as an intermediary, but C only claims conformance as a server (with multiple endpoints). C could use unspecified mechanisms to route to D, as long as it rewrites URLs on the way out. A and B would be none the wiser. This might be appropriate for a vendor network.
Vassil Peytchev (Sep 13 2021 at 20:41):
Mechanism MUST work without requiring rewriting of URLs
That is most definitely not a MUST - I would rather say this is the price of admission as a FHIR intermediary.
I am not sure I understand the original question - if we are saying that the intermediary is providing a service for actor2.org, the way to use DNS to manage that would be to use a sub-domain, fhir1.actor2.org, to represent the endpoint. Rewriting this to further point to a URL with a specific port to properly process the requests is standard functionality for a reverse proxy. Am I missing the point?
Vassil Peytchev (Sep 13 2021 at 20:44):
I don't have a FHIR server for this track, but if there are questions and a need to experiment with DNS settings, I may be able to set up a web server that could be used to try things out.
Mike Yackanich (Sep 14 2021 at 13:59):
If goal is for the initiator (Actor1) to not know whether the request is routed through an intermediary chain or direct to the responder, their directory entry must contain the hostname, port, and app path of the target destination. If that then routes directly to the target responder - it would be successful (given appropriate security model is adhered to). If, though, that routes through an intermediary chain (1 or more), then the intermediary must be able to accept that hostname/port/app path combo, determine the next hop based on the hostname, and then route accordingly. The intermediary will use the hostname to lookup the next hop within the intermediary's directory.
I believe eHx as intermediary is prepared to support testing of a request such as http://FHIR.Actor2.org/Patient/123
We are NOT prepared to support http://FHIR.Actor2.org/Actor2AppPath/Patient/123. But I might be able to make that work by the time we are finished testing today.
Last updated: Apr 12 2022 at 19:14 UTC
