Stream: implementers
Topic: How to specify a target endpoint via a RELAY
Tim Berezny (Jul 26 2018 at 15:26):
I need to send FHIR resources to a target endpoint that first travels VIA an intermediary endpoint (which is an integration engine). In otherwords, the endpoint in my POST message is always the intermediary relay endpoint, and i have to tell it where the final intended destination of the bundle is.
What is the most FHIR-y & universal way to do this?
Some ideas I've had:
1) Include an endpoint in the bundle that specifies the final target destination
2) Include a subscription in the bundle that specifies the final target destination
3) Create an extension for the bundle called .relayTarget that specifies a endpoint or subscription with the final target destination
4) Do something with bundle identifiers where the intermediary endpoint builds in routing rules according to the bundle identifiers.
5) others?
Michele Mottini (Jul 26 2018 at 15:55):
5) Add a 'route-to' query parameter to the POST URL
Tim Berezny (Jul 26 2018 at 16:13):
That's a clever idea, have you tried that before?
Michele Mottini (Jul 26 2018 at 16:15):
No, never had to do routing like that...but it is maybe easier to read (and faster?) and use a URL parameter instead of having to parse the bundle
Lloyd McKenzie (Jul 26 2018 at 18:40):
I'd definitely recommend using either something in the URL (e.g. query parameter) or a custom HTTP header.
Alfred Wong (Jul 26 2018 at 19:23):
I do like the custom header approach or query param as I feel that it help extract that relay concept out of the FHIR resource.
Brian Postlethwaite (Jul 26 2018 at 21:25):
This is a messaging routing problem, rather than an endpoint problem.
Grahame Grieve (Jul 26 2018 at 21:28):
did make me wonder about messaging...
Grahame Grieve (Jul 26 2018 at 21:29):
I don't see any other HTTP take on this problem... not sure why that is, but does it call the framing of the problem into question?
Lloyd McKenzie (Jul 26 2018 at 22:07):
Typically you want the endpoint to either be a black box (you have no clue whether there are multiple systems on the back end, or how functionality is divided/organized) or you have multiple endpoints that all happen to resolve to the same front-end box which services as your access point/security barrier and routes things accordingly. The approach of single endpoint, but still knowledge of back-end systems is unusual.
Tim Berezny (Jul 27 2018 at 12:58):
@Lloyd McKenzie yes, the endpoint being a black box is a philosophy we are trying to shoot for.
More specifically, the overall flow we're trying to figure out is a ServiceRequest process where the relay system is the Ontario HIAL:
1. Send ReferralRequest: Requester > HIAL > Provider
2. Send Appointment update back to sender: Provider > HIAL > Requester
In process 1, the requester always sends to the HIAL endpoint, and the HIAL looks up the endpoint of the requested HealthcareService in a registry, so that part is solved.
In process 2, we're trying to figure out how to get updates (like appointments) back to the Requester. The provider always sends to the HIAL endpoint and then we need to figure out how to get the HIAL to route to the correct initial requester.
Having the provider system tell the HIAL where to send the update is one of the methods being discussed. The way that the provider system would know where to send the update to (that we've discussed so far) is either because the requester is registered with the provider system, OR the requester includes the updateEndpoint in the initial ServiceRequest payload. The HIAL wouldn't be storing where the original ServiceRequest came from, so the receiving system would need to store that endpoint and inform the HIAL.
@Brian Postlethwaite mentioned that another method is to lookup the endpoint of the requester's organization in a registry for updates.
There are a few scenarios where ReferralRequests could go to different sources than the original request, particularly when updates are to be sent to MULTIPLE destinations, such as the requester + family doctor + referral registry + patient portal. These destinations should for the most part be known by the provider system (as you say "explicitly configured") ... and so the question is how to tell the single relay point (HIAL) to re-route to all of these spots.
It sounds like the options mentioned so far are:
1) put final relay destinations into URL parameter
2) create an extension (in the /bundle resource?) for re-routing
3) lookup the organization of the request (although this doesn't solve when we want to also send to destinations other than the requester via the relay point)
4) Another method we've talked about internally is having the sending system include an identifier in the initial request, which would be returned with any later updates and the HIAL would somehow be able to lookup registered endpoints based on that identifier.
Lloyd McKenzie (Jul 27 2018 at 13:32):
If you're doing REST, then you'd have a synchronous session from Requester to HIAL and HIAL to provider, so it should just "happen", no? The call from HIAL to provider is invoked in the context of the synchronous session the HIAL starts up when responding to the requester.
Tim Berezny (Jul 27 2018 at 14:08):
For immediate responses yes it would by synchronous. However, sending updates such as adding an appointment or setting an outcome might not happen until weeks later, which would not be synchronous.
Lloyd McKenzie (Jul 27 2018 at 14:11):
But in that case, are you expecting to push the results? If so, how? If you're doing polling, that'll still by synchronous. If you're doing subscriptions, the subscriber will be identifying their endpoint. If you're doing messaging, you should have the information...
Paul Knapp (Dec 04 2020 at 17:47):
FHIR Messaging would match your requirements.
Last updated: Apr 12 2022 at 19:14 UTC
