Stream: fhir/infrastructure-wg
Topic: FAST/FHIR intermediaries
John Moehrke (Jan 27 2021 at 15:04):
I have heard the presentation on this project to create a FAST/FHIR intermediary implementation guide, and I can't help but think we are re-inventing the wheel, where we should be using the wheels (the internet) we have to use. HL7 should be focused on the "Health" specific needs, not general IT infrastructure. We certainly should be presented with the Use-Case to solve, not presented with the solution someone has already created.
Lloyd McKenzie (Jan 27 2021 at 15:06):
@Patrick Murta
John Moehrke (Jan 27 2021 at 15:06):
Why does the long-standing use of http-proxy, or api-gateway not sufficient? These have been used for years to support simplifying routing/management, and provide for content policy inspection. Where http-proxy are commonly used by corporations to inspect all outbound http browser sessions by the company users; and api-gateways are used by cloud service to support inbund to the cloud API requests that are potentially bound to various services (micro-services) within the cloud (or beyond).
Paul Church (Jan 27 2021 at 15:12):
I went to the connectathon track on this and my impression was similar, it sounds like adding another layer of FHIR-specific routing to solve problems that the internet has already solved.
Josh Mandel (Jan 27 2021 at 15:42):
I had to miss the call yesterday, but this was my concern when it came up in FMG, too.
Gino Canessa (Jan 27 2021 at 16:34):
Zeroth: apologies for the novel. It's been a little while since I posted one, but it's how I think the best (and I'm sure you have all missed them ;-).
First, @Patrick Murta, I hope I didn't offend last night. These sessions at the WGM are a chance for people that can't pay attention "always to everything" to focus in and ask difficult questions. And yes, I've been on the receiving side of that a few times =). It's hard, but it's also necessary (and useful).
Getting to the FAST IG itself... I still don't have a clear picture of the use cases, but I can see a few areas that definitely need exploration.
For example, the idea of a standardizing a 'FHIR directory' server. I like it, and I think building an IG for this is a great idea. I would argue it should use FHIR resources (e.g., Organization and Endpoint) so to, as John said, avoid re-inventing the wheel*, but having a reusable specification for a directory of FHIR servers sounds useful.
*e.g., how do you assign multiple names to an organization ("Insurance Provider of State" + "INPxx", etc.), search semantics (clients don't want to download 500 records, index them, and figure out their own search algorithms to do the above name matching), etc.
Similarly, the idea of a standard token exchange mechanism for trusted networks of servers seems useful. I am curious how implementers "at large" feel (e.g., would it actually be implemented?), and work on a foundational component probably needs a broad core group and a large time investment*. Again, I would love to see an IG/project for this, and hope it can align with the SMART specs already present (e.g., app launch and backend services authorization).
*as a datapoint, updating the SMART App Launch Framework to v2 has been a public project for a year with bi-weekly calls and multiple Connectathons. The changes are just now in the process of moving to the necessary WGs for additional review/work.
On the other hand, it feels like some decisions have already been made and aren't open to discussion.
An example here is the 'header vs. path component' issue. This was brought up during PSS application, and apparently at FMG review as well. So far, I haven't heard any reasoning as to why headers were chosen, simply that they were. Doing something contrary to what's in place isn't going to be approved without some justification.
Similar on this front is the decision not to "depend" (if I have my wording correct from last night) on FHIR for certain parts of the work. If I'm sending a request for a FHIR resource to a network, I would expect an OperationOutcome for errors. Here again, defining something different will set the bar much higher because there's already a way defined and in use.
Overall, I think my biggest concern is about expectations. Bringing a specification for publication as a part of FHIR means that it needs to align with FHIR. This can be challenging (what I wouldn't give to change the JSON serialization format =), but it is a requirement of the process.
Vassil Peytchev (Feb 09 2021 at 20:20):
Would it be helpful to step through an example of how things are expected to work?
A common pattern of accessing FHIR resources is to establish patient identity, and then request additional resources related to that patient. If we assume to have the following actors:
- Originator
A - Responder
B1 - Responder
B2 - Intermediary
I1 - Intermediary
I2
and the following routing rules:
A->I1->B1A->I1->I2->B2
If the goal of A is to do a search on a patient, and then retrieve the PCP, what would be the steps for A to do that, given the two patients, P1, and P2, which are both found on B1, but with the following difference:
P1.generalPractitionerreferences theGP1Practitioner resource onB1P2.generalPractitionerreferences theGP2Practitioner resource onB2
The last assumption here is that there is a Directory/Locator service that can be queried by A to learn the URL and destination to search for P1 and P2.
Paul Church (Feb 12 2021 at 18:26):
My first question here is how these practitioner references are represented. Are they full URLs? An identifier that has to be looked up in a directory? Is the reference from a patient on B1 to a practitioner on B1 different from the reference to the practitioner on B2?
Vassil Peytchev (Feb 12 2021 at 18:36):
The references to GP1 and GP2 are "vanilla" RESTful references; in this example, P1 to GP1 can be a relative reference, or a full URL, the reference from P2 to GP2 must be a full URL.
Paul Church (Feb 12 2021 at 18:39):
Is the full URL reference from P2 to GP2 using the base URL of B2 or I1?
Vassil Peytchev (Feb 12 2021 at 18:42):
B1 and B2 consider I1 and I2 to be just another client. The reference from P2 to GP2 uses the base URL of B2.
Paul Church (Feb 12 2021 at 18:45):
How does the client know that I1 is the first hop in trying to obtain a resource from B2? If I understand correctly, in the proposed FAST intermediaries design the client would call I1 with an X-Destination of B2. But why would it know that it can't just resolve the REST URL to B2 directly?
Vassil Peytchev (Feb 12 2021 at 18:55):
That is one of the questions I am trying to raise and get answers to.
If there is a business reason for queries from A to always go through I1, no matter the destination, I think that implies either a requirement for I1 to appropriately rewrite links in any responses it gets, or a requirement for the client to use mapping functionality that maps non-I1 URLs to I1 URLs.
If the goal is for the client to be agnostic whether it is communicating through an intermediary or directly, then the rewriting requirement becomes the only viable solution.
Paul Church (Feb 12 2021 at 19:36):
I think we're on the same page about a very fundamental question - if we are talking about REST URLs, there is already a way for a client to get requests routed to the ultimate destination: the internet. So if I have a REST URL and an X-Destination header, I don't understand what layer we are routing at.
The FAST group has talked about things like clearinghouses or technology providers as intermediaries, but in those cases I would expect the full URL to be the intermediary rather than the ultimate responder.
Paul Church (Feb 12 2021 at 19:42):
We have this problem in GCP, where the actual full URL is a cloud service that the implementer likely does not want to expose and may migrate behind the scenes from time to time. So the next layer of proxy does full URL rewriting between incoming and outgoing resources to expose a consistent URL to clients.
John Moehrke (Feb 15 2021 at 12:54):
GCP?
Vassil Peytchev (Feb 15 2021 at 12:55):
GCP = Google Cloud Platform
John Moehrke (Feb 15 2021 at 12:56):
re-writing returned URLs means re-writing all internal references too... which means changing medical records... This is a big burden to keep re-written URLs consistent longitudinally for the life of the patient plus; and consistent regardless of the consuming system. This solution is very expensive and puts into question the integrity of the data.
John Moehrke (Feb 15 2021 at 12:58):
We can see the solution they are proposing... but I can't yet understand the problem we think we are solving. Thus no idea if the solution actually solves the problem, and no idea if the solution is economical solution to the problem.
Cooper Thompson (Feb 22 2021 at 19:01):
There are intermediary solutions being proposed in the Netherlands that are likely going to re-write fullUrls and re-map FHIR IDs (since if you re-host to a new URL, and that intermediary does that for multiple parties, you may not have unique FHIR IDs anymore). Just an FYI on some projects I know are happening in real life.
Marc Sandberg (Apr 09 2021 at 14:01):
@Cooper Thompson Are you referring to Twiin or other initiatives? I'm working on Twiin myself, and would love to be in contact with anyone else working on a solution for this complex problem.
Cooper Thompson (Apr 09 2021 at 14:31):
Twiin is not something I've heard of. I was referring to various DVZA entities for MedMij. If Twiin is a DVZA, it isn't one of the specific DVZAs I'd heard of.
Marc Sandberg (Apr 09 2021 at 14:59):
Twiin isn't a DVZA, it's working to specify something similar to MedMij but for Health Organization to Health Organization instead of Patient to Health Organization.
Patrick Murta (Jun 24 2021 at 17:18):
All, we have made a few updates to the draft IG framework in response to feedback here an in meetings. I have also attached a PDF which distills down the options considered to a matrix with sequence diagrams. An option that has been reviewed with several of you during connectathons and such is the DNS model in which the URL for actor B (the receiver of the API call) has been set up to resolve to the intermediary. This one seems to be the most popular at this point (options 1/2 in the PDF and shell IG).
Patrick Murta (Jun 24 2021 at 17:19):
http://build.fhir.org/ig/HL7/fhir-exchange-routing-ig/branches/main/specification.html
Patrick Murta (Jun 24 2021 at 17:19):
Hybrid-Intermediary-Exchange-IG-options-20210618.pdf
Last updated: Apr 12 2022 at 19:14 UTC
