Stream: FHIR at Scale (FAST): Exchange with/without intermediaries
Topic: May 2021 Connectathon
Vassil Peytchev (May 14 2021 at 18:33):
Hello all! I watched the recording of the kick-off meeting with great interest - it was a very good discussions, and I hope to contribute during the Connectathon.
Vassil Peytchev (May 14 2021 at 19:09):
One of the points brought up at the kick-off was regarding the use of the FHIR base path vs. a URL parameter, i.e.
https://www.example-int.com/fhir/xdest1/...
vs.
https://www.exmple-int.com/fhir/....&target=xdest1
I think there is an answer to that based on two things:
- Expectations of the originator - I think one of the goals of this IG is to let the originators and responders in all cases remain blissfully unaware whether they are communicating via an intermediary or directly point-to-point. Having an extra URL parameter contradicts that goal. Besides, the meaning of
GET https://www.example-int.com/fhir/xdest1/Patient/123is precisely defined in FHIR, whileGET https://www.example-int.com/fhir/Patient/123?target=xdest1differs from the FHIR specification. - We are talking about the public URL - I think the presentation and the posted diagram did a great job by bringing up that we are talking about the URL as seen by the outside world, which is not necessarily what is seen by the servicing application in the intermediary. It is not necessary for the intermediary to parse out the URL to find the destination. Instead, the intermediary needs to map the base URL (as defined by the FHIR specification) as a whole to the destination that base URL serves.
One practical approach is to set up a reverse proxy at the intermediary that will convert all FHIR URLs with base URL of https://www.example-int.com/fhir/xdest1/ to URLs like https://www.example-int.com/fhir/....?target=xdest1. From what I understand, it is up to the intermediary to decide how they are going to represent the destination within the base URL, and therefore they control the mapping.
@Patrick Murta @Durwin Day
Cooper Thompson (May 14 2021 at 19:50):
References and fullUrls in Bundles seem like they'd push the solution to app path components rather than query strings. Since the reference data type is defined in the FHIR spec and I don't think that really allows for a query parameter in a literal reference (i.e. it doesn't match the regex in Literal References
Cooper Thompson (May 14 2021 at 19:51):
Also, for references, you can go relative, for Bundle fullUrls need to be absolute URLs (or UUIDs, but there was a whole discussion about that).
Josh Mandel (May 14 2021 at 19:55):
Yes please make this kind of routing transparent for clients ;-)
Last updated: Apr 12 2022 at 19:14 UTC
