Stream: social
Topic: Multi-hop FHIR
Nick Radov (Aug 04 2021 at 17:53):
During the QHIN Technical Framework webinar today the presenters stated that FHIR isn't really ready for use in that environment due to lack of support for multi-hop networks. There may be multiple intermediate nodes between an interaction initiator and the final recipient. What does everyone thing of that? Are there best practices defined for FHIR interactions that go beyond point to point? Or is this a real gap that we ought to address in a future release?
https://sequoiaproject.org/onc-and-the-sequoia-project-publish-draft-technical-framework-for-network-to-network-health-information-exchange/
David Pyke (Aug 04 2021 at 18:02):
This probably should be in #social
John Moehrke (Aug 04 2021 at 18:21):
It is unfortunate that this was presented as a reason to not use FHIR, vs an opportunity to work toward. FHIR is an Interoperability Standard, not a systems-design. The issues with Multi-Hop are systems-design problems. There are plenty of good systems-design, and some really bad ones. This is a fact not unique to FHIR, or unique to standards in general (e.g. USA electrical lightbulb socket).
David Pyke (Aug 04 2021 at 18:22):
It was presented as a challenge to be solved for the next version of the QTF
John Moehrke (Aug 04 2021 at 18:23):
Good to hear @David Pyke , I trusted you had said the right things.
Nick Radov (Aug 04 2021 at 18:26):
Is there a way to change the stream to #social? I tried to edit but didn't see an option to do that.
Notification Bot (Aug 04 2021 at 21:53):
This topic was moved here from #implementers > Multi-hop FHIR by Lloyd McKenzie
Lloyd McKenzie (Aug 04 2021 at 21:54):
Admins have the power :) I think the need for this is trying to be addressed by the FAST initiative - @Patrick Murta?
Vassil Peytchev (Aug 05 2021 at 15:50):
The Internet is by definition a multi-hop network, and FHIR is built on top of the fundamental internet protocols and technologies.
It is not so much "support for multi-hop networks" as a FHIR capability, it is rather support for FHIR by intermediaries that is lacking.
Just like X12 intermediaries provide services for X12 communications, and interface engines provide services for HL7v2 communications, this is system functionality that doesn't need anything from the FHIR specification itself, just guidance on how to be this new thing, called "FHIR intermediary".
David Pyke (Aug 05 2021 at 15:54):
That's a better way to put it. FHIR with intermediaries is the challenge, especially intermediaries that may be aggregating results
John Moehrke (Aug 05 2021 at 16:18):
right. so the solution is to "Not use Intermediaries."
John Moehrke (Aug 05 2021 at 16:19):
if one stops enabling these intermediaries to have some business reason to exist... then we use the Internet for what it is good at (networking), and use FHIR for what it is good at (healthcare information model and REST access method)
David Pyke (Aug 05 2021 at 16:19):
Right! Why didn't I see that as the obvious fix. Hold on while I call ONC and have them restart the entire thing
John Moehrke (Aug 05 2021 at 16:21):
my point, and I think others, is to characterize the problem properly. It is not a "Multi-hop FHIR" problem. It is a "intermediaries want to exist" problem.
David Pyke (Aug 05 2021 at 16:22):
It's an "ONC Designed a system with intermediaries, we don't get to say 'change it' just because it doesn't work for FHIR" problem
John Moehrke (Aug 05 2021 at 16:23):
once the problem is characterized properly... "Intermediaries want to exist"... then it becomes obvious that "intermediaries should solve the problem that they are creating". Rather than tell the rest of the world (USA) that FHIR is not possible to be used at scale or with multi-hop.
David Pyke (Aug 05 2021 at 16:26):
While we may want the intermediaries to go away because it makes our technology better, that's not the problem we can solve. We can either adapt our technology to work in the system provided or not use that system. ONC created this design. Saying "but Intermediaries are bad" doesn't help
Lloyd McKenzie (Aug 05 2021 at 16:29):
There are legitimate uses for intermediaries. And we're working on technical guidance to allow them to work more seamlessly in the FHIR space when doing pure REST. (FHIR works seamlessly for multihop already if you want to do messaging.) That said, adding multiple hops creates challenges for real-time processing as each layer injects delay, so you really want to ensure that intermediaries are really necessary. And if the systems involved are only going to be able to handle asynchronous processing, then you're stuck with FHIR messaging until the architecture is refactored to allow synchronous exchange.
Vassil Peytchev (Aug 05 2021 at 16:44):
Saying "but Intermediaries are bad" doesn't help
No one is saying "intermediaries are bad" - far from it. in many cases intermediaries are useful and necessary. The Internet is full of intermediaries. All I am saying is that intermediaries have to be (re?)designed to work with FHIR, and that is where the effort needs to be. You could call them "FHIR Content Delivery Networks", if that helps clarify how they are supposed to work.
David Pyke (Aug 05 2021 at 16:46):
Great! Can you put in feedback to the QTF on how to reshape the intermediaries to allow for synchronous FHIR over multiple intermediaries?
Vassil Peytchev (Aug 05 2021 at 16:47):
https://www.cloudflare.com/learning/cdn/what-is-a-cdn/
David Pyke (Aug 05 2021 at 16:51):
I know what a cdn is. Now apply that to the TEFCA model.
Vassil Peytchev (Aug 05 2021 at 16:56):
I think there is some misalignment of purpose and intention in this conversation. To bring it back to basics, my first question is:
Does TEFCA apply to FHIR or not?
David Pyke (Aug 05 2021 at 16:59):
No, TEFCA does not yet have FHIR. The discussion here was how to address the issues that FHIR has to allow it to work with TEFCA. That is, how to have FHIR work with a system based on multiple intermediaries that may be aggregating data
Vassil Peytchev (Aug 05 2021 at 17:07):
If you are trying to "address the issues that FHIR has", you are likely to break FHIR.
Trying to address the issues that intermediaries which aggregate data have with FHIR is probably a better approach.
One place to start could be, what does it mean for an intermediary to be aggregating data and using FHIR?
David Pyke (Aug 05 2021 at 17:12):
Okay, we can't erase the work done to create the TEFCA framework and design. We have to work with what we have and find a way to make FHIR work within the paradigm. Aggregating data means taking responses from many sources and placing them in a single response for the requestor. So, FHIR has to have a way to be aggregated into one response (perhaps a bundle of bundles) that can be processed by a receiver that will be behind 4+ intermediaries
David Pyke (Aug 05 2021 at 17:14):
We also have to have all queries routed through the intermediaries
John Moehrke (Aug 05 2021 at 17:14):
there are documented standards for how to use FHIR with the existing networks. Multiple kinds of solutions. Easier API (MHD), Easier content (FHIR-Document), and easier discovery (FHIR directories and patient registries).
John Moehrke (Aug 05 2021 at 17:15):
https://profiles.ihe.net/ITI/HIE-Whitepaper/index.html
David Pyke (Aug 05 2021 at 17:15):
FHIR DOcuments are one way for content. Now we need a security model
David Pyke (Aug 05 2021 at 17:16):
Where the query responder will not necessarily have any way to authenticate the query originator user
John Moehrke (Aug 05 2021 at 17:17):
if the query responder can't authenticate the originator... DENY
John Moehrke (Aug 05 2021 at 17:17):
use the federated authorization methods already in place as part of the USA nation wide networks.
David Pyke (Aug 05 2021 at 17:17):
Sorry, no. The originating user will be multiple intermediaries away. We can't just deny all. That breaks the TEFCA model
David Pyke (Aug 05 2021 at 17:18):
There are no national networks with multiple intermediaries
John Moehrke (Aug 05 2021 at 17:18):
then maybe the TEFCA model... as you interpret it... is wrong
David Pyke (Aug 05 2021 at 17:18):
Well, then put in feedback to fix it
John Moehrke (Aug 05 2021 at 17:18):
security and privacy have a fundimental principle -- DENY unless proven reason to PERMIT
David Pyke (Aug 05 2021 at 17:19):
The proven reason is that it's a TEFCA query in a trust framework
John Moehrke (Aug 05 2021 at 17:19):
break that principle and we might have zero security and zero privacy
John Moehrke (Aug 05 2021 at 17:20):
David Pyke said:
The proven reason is that it's a TEFCA query in a trust framework
there are already at least two models in nationwide use today. You are wanting to throw them out just to build a new one? That WILL BE EXPENSIVE and not any better.
David Pyke (Aug 05 2021 at 17:21):
I don't want to do anything. Talk to ONC
David Pyke (Aug 05 2021 at 17:21):
IF you can find a fix, please put in feedback to the RCE
John Moehrke (Aug 05 2021 at 17:21):
I talk to ONC. I also talk to little birdies.
Vassil Peytchev (Aug 05 2021 at 17:22):
So, FHIR has to have a way to be aggregated into one response (perhaps a bundle of bundles) that can be processed by a receiver that will be behind 4+ intermediaries
It is the job of the aggregating intermediary to make sure the receiver is completely unaware of how many or what intermediaries are involved. Just like CDNs do it.
We also have to have all queries routed through the intermediaries
Again, the FHIR client doesn't need to know anything about intermediaries.
In case it is not clear, I am not trivializing the problem. It requires effort to be solved, an effort by the intermediaries to adapt, but it is not a technological or a FHIR specification problem.
David Pyke (Aug 05 2021 at 17:22):
https://rce.sequoiaproject.org/qhin-technical-framework-feedback/
John Moehrke (Aug 05 2021 at 17:25):
agreed. aggregating intermediaries need to do systems design. It is not easy work, but it is not rocket-science. That systems design should result in no external difference, should be FHIR compliant. Them complaining that they have to do systems design, and expecting free consulting is aggravating.
David Pyke (Aug 05 2021 at 17:27):
Realize that ONC only can mandate what the QHINs do, not the systems between the QHINs and the querier and responders. So, this needs to be more than just systems design.
David Pyke (Aug 05 2021 at 17:28):
And this is only that specification. Lots of money on the table to help the HIEs and others do their systems design to support the models that are adopted
John Moehrke (Aug 05 2021 at 17:30):
they should not be involved in systems design. They should only define the Interface behaviors -- aka, what we all refer to as Interoperability Standards. Systems designs will change multiple times over the lifespan of any Interoperability Standard.
Lloyd McKenzie (Aug 05 2021 at 17:34):
It is definitely in HL7's interest to help ensure that TEFCA will work for exchanges of data in forms other than documents - i.e. proper RESTful query that brings back desired resources. It would be a shame if the only way systems could share FHIR data is wrapped in documents.
John Moehrke (Aug 05 2021 at 18:09):
if it is not clear. I agree. However I do also encourage expansion of existing solutions that are working, vs throwing them away.
John Moehrke (Aug 05 2021 at 18:11):
I will also defend documents for cross-organizational communication, as the principles behind document design are important for cross-organizational communication. FHIR-Documents (like IPS) are easy step, have the benefits of the FHIR model, and have the benefit of fitting perfectly within the existing nationwide networks.
Lloyd McKenzie (Aug 05 2021 at 18:35):
Documents suck in terms of data integration. When I want a list of a patient's allergies, I really don't want 50 C-CDA equivalents that each contain a list of allergies.
Lloyd McKenzie (Aug 05 2021 at 18:36):
For data that's naturally a document (discharge summary, pathology report, etc.), then managing the data as documents makes sense. But for other data, we should avoid solutions that require packaging content into documents because that's the way we're used to sharing across systems. It's pretty painful to build a SMART app or CDS Hook service on top of a document repository.
John Moehrke (Aug 05 2021 at 18:41):
I said FHIR-Document... and I think there needs to be documents defined for more useful purposes. Such as "current allergies"
John Moehrke (Aug 05 2021 at 18:42):
I don't think that this is a mutually exclusive world. I believe that each solution has its place.
John Moehrke (Aug 05 2021 at 18:43):
C-CDA has tarnished the concept of a document. However C-CDA has delivered many positive
John Moehrke (Aug 05 2021 at 18:45):
I am not against a nationwide http RESTful FHIR at the resource level. Geek excitement. Medical-Records concerned. Patient Safety worried.
John Moehrke (Aug 05 2021 at 18:48):
especially if the only way it will work is with intermediaries.... intermediaries that are there explicitly for the purposes of intermediating security, privacy, and data integrity. What was in the medical record will not be what is received. This breaks integrity, provenance, authentication, authorization, wholeness, and context.
Lloyd McKenzie (Aug 05 2021 at 19:33):
A 'current allergies' document is nonsensical. Anything that is 'current x' as a document is unnecessary overhead, and it puts the work of trying to resolve duplication and redundancy on the client when it should, as much as possible, be done by the intermediary
Lloyd McKenzie (Aug 05 2021 at 19:35):
The concept of 'wholeness' is essential when context flows from one data structure to another. It becomes less critical when context flow is prohibited and all context is required to be explicit in each structure.
Lloyd McKenzie (Aug 05 2021 at 19:36):
When an allergy record is updated - that's the only context. There's no overarching admission, discharge or other event to provide context. It's just one allergy sitting in a database - that's free to be passed around all on its lonesome.
Cooper Thompson (Aug 05 2021 at 19:49):
Lloyd McKenzie said:
... and it puts the work of trying to resolve duplication and redundancy on the client when it should, as much as possible, be done by the intermediary
On the bright side, if clients are aggregating REST API data from multiple sources, they may already be really good at doing deduplication...
John Moehrke (Aug 05 2021 at 20:49):
@Lloyd McKenzie I don't think you were clear. Your example was against a centralized CDR (which you did not state), while you presumed mine was not. Both transports could support a CDR. I will add that IHE did define a fhir resource level api to a CDR with mechanism to interact with the existing nationwide health network. mXDE + QEDm . This could be centralized, regionalized, or organization deployed. Privacy by Design is also a principled design.
Lloyd McKenzie (Aug 05 2021 at 22:29):
I'm not arguing against Privacy by Design, or minimizing privacy concerns about TEFCA. I'm saying that if all we get out of TEFCA is document exchange, we've lost a tremendous opportunity.
John Moehrke (Aug 06 2021 at 14:08):
I agree,
but trying to twist a Document Exchange into a Resource Exchange is not the right approach. (The highway and railroad are similar but very different.). Architecting a http RESTful FHIR nationwide network should re-use some parts of the existing network, but should NOT be the same architecture.
- the QHIN and HISP models of the past should not be needed in a RESTful FHIR environment.
- I am not saying that some new system like a CDR is not needed, but a CDR is not at all the same thing as a QHIN or HISP. And a CDR should not be a national level service for many political and privacy reasons. Thus it is a service offering (read business opportunity) not something baked into the architecture.
What parts should we keep? I think there is very little that spans these two architectures.
- Likely Certificate Authority trust fabric, but even that needs adjustment for the different needs of the participants in that trust fabric.
- I think Patient Identity must be kept simply because we can't do patient identity properly and thus one hack is as good as another.
- possibly Services Directory. but this will only look similar at the organization level.
- I would like to say Audit Logging, but this doesn't exist at all today, and likely won't exist properly ever
all of these are unclear. Not because they are bad, but because the architecture difference brings different systems design needs. All of these could/should be used to begin with with the expectation that they WILL be re-architected once the http REST fabric is functional (I still have hope that patient identity will be taken seriously eventually).
Lloyd McKenzie (Aug 06 2021 at 17:12):
My understanding (could be wrong) is that TEFCA wasn't intended to be limited to just document exchanges?
David Pyke (Aug 06 2021 at 17:21):
It has two aspects, Document query and retrieve plus messaging. So, you can fetch documents or send a "message" to a remote provider.
Lloyd McKenzie (Aug 06 2021 at 18:01):
Ok, so no support for RESTful query at all? Then I guess you're stuck with FHIR documents or FHIR messages. I hope that HL7 as an organization will be providing feedback that suggests that that's not the foundation we should be aiming for. I know that at least some of the networks already support FHIR query, so it seems odd to not address that in this spec.
David Pyke (Aug 06 2021 at 18:32):
No RESTful query or operations at the QHIN level, people below the QHINs can send info differently but the QHINs are purely XCA/XCDR operations using CCDAs except for special requests or special purpose data (e.g., public health)
John Moehrke (Aug 06 2021 at 21:35):
This said... this is not a restriction on a new proposal for a proper FHIR REST nationwide network.
John Moehrke (Aug 10 2021 at 12:56):
I wrote up my stepping stone https://healthcaresecprivacy.blogspot.com/2021/08/fhir-data-in-existing-nationwide-health.html
I have no intention that this be a destination. I fully agree with more native http RESTful FHIR. Just alot of capabilities need to be created for that to work. Things that the nation already has with documents. So both pathways.
Last updated: Apr 12 2022 at 19:14 UTC
