Stream: FHIR at Scale (FAST): Exchange with/without intermediaries
Topic: Connectathon track scenarios
Frank McKinney (Dec 21 2021 at 00:16):
Draft test scenarios to discuss at tomorrow's Hybrid / Intermediary Exchange call. (1:00 ET, https://global.gotomeeting.com/join/262996117)
FAST-Exchange-Connectathon-Scenarios-draft-20211220.docx
Mike Yackanich (Jan 05 2022 at 21:26):
FYI - I was able to get async working on the eHx Hub POC, using our POC HAPI FHIR server as the target responder, application path routing, and I disabled URL rewriting. Tested multiple times today and it looks good. So we should be good to go for testing the (new) async workflow next week.
Mike Yackanich (Jan 11 2022 at 19:47):
I reconfigured the eHx POC Intermediary to use hostname-based routing (versus AppPath) - and I recreated all of the Postman request tests. I'll share the new Postman with @Frank McKinney and @Patrick Murta via email. Note that all of these tests use the public HAPI server at hapi.fhir.org as the target responder.
Vassil Peytchev (Jan 11 2022 at 20:11):
Is there a scenario where the destination uses two intermediaries in parallel?
Mike Yackanich (Jan 11 2022 at 20:54):
@Vassil Peytchev - not that I know of, so I defer to Frank and Patrick. The current multi-hop scenario with 2 intermediaries is sequential. Not sure I understand a multi-intermediary, parallel scenario. Would this represent a fan-out of sorts by the intermediaries?
Vassil Peytchev (Jan 11 2022 at 21:06):
I am imagining different intermediaries providing a different entry points - for example, one for claims/billing type queries, another for clinical data queries. Or is the current assumption that a destination can only get queries from a single intermediary?
David Pyke (Jan 11 2022 at 21:07):
TEFCA has one intermediary for all requests for one client
Vassil Peytchev (Jan 11 2022 at 21:11):
Not client, destination. Or did you mean from the destination's point of view, a client can only reach it via only one intermediary? If that is the case, I am thinking multiple clients, some use int1 (and always int1) and others use int2 (and always int2). destination needs to respond to both int1 and int2.
David Pyke (Jan 11 2022 at 21:24):
YEs, both. A client -> int1 -> int 2 -> destination. There may be more than 2 intermediaries involved
David Pyke (Jan 11 2022 at 21:24):
more than one client may use int1, more than one destination may use int2
David Pyke (Jan 11 2022 at 21:25):
but a destination will only be connected to one QHIN/intermediary
David Pyke (Jan 11 2022 at 21:25):
So it may be client2 -> int3 -> int2 -> destination
David Pyke (Jan 11 2022 at 21:26):
But client 1 will only connect though int1
Vassil Peytchev (Jan 11 2022 at 21:53):
That example will work. My concern is that in the above example from Dave, the existence of int1 and int3 has not been considered by the IG. It requires that the destination is aware of the existence of int1 and int3, and which one was the entry point for the query that is coming from int2.
David Pyke (Jan 11 2022 at 21:56):
This solution needs to be flexible enough for there to be a ring of 10+ intermediaries that may need to connect via int2 to destination
David Pyke (Jan 11 2022 at 21:59):
int2 would be one of the intermediaries in the ring
Vassil Peytchev (Jan 11 2022 at 22:06):
Exactly, and the way to do this is not by making the destination magically slap a different FHIR base on any full URLs it has depending on which of the 10+ intermediaries the initial request comes from, but by accepting the inevitability that any FHIR intermediary must handle URL re-writes (and re-sign and re-encrypt content if necessary).
David Pyke (Jan 11 2022 at 22:08):
Yeah, although I'm not a fan of re-sign/re-encrypt as that would have issues with provenance
Gino Canessa (Jan 12 2022 at 16:25):
In fairness, I assume that production intermediaries will need to support re-sign/re-encrypt anyway, since that needs to happen if the MIME type changes... :-/
(note: I do not like this story, just reading it as I see it written)
Mike Yackanich (Jan 12 2022 at 17:27):
@Bas van den Heuvel - the multi-hop requests are now flowing to your intermediary successfully. I had to restart my service. The following example actually routes through 3 intermediaries (2 of mine, and then yours), and then arrives at the target destination of hapi.fhir.org. Note that public.hapi.fhir.org.multihop must resolve to 52.10.37.229.
wget --no-check-certificate --quiet \
--method GET \
--timeout=0 \
--header '' \
'http://public.hapi.fhir.org.multihop:52774/fhirproxy/fast/r4/Patient?_id=2696380' -SO-
Bas van den Heuvel (Jan 12 2022 at 17:37):
It also worked from my PC - good work.
Last updated: Apr 12 2022 at 19:14 UTC
