Stream: smart
Topic: prefetch
Tejay Cardon (Sep 09 2020 at 17:50):
So, I'm a big fan of the pre-fetch capability in the CDS-hooks spec. Does anyone know if a pre-fetch has been considered for the SMART launch protocol? we have an app that would really benefit from being able to launch with the data it needs already available. In our case, it wouldn't need to reach back to the SMART server at all, which would provide a simplified launch method for host systems that may not actually have a FHIR server
Josh Mandel (Sep 09 2020 at 17:55):
This is an interesting suggestion and I don't think it has come up before. One of the challenges with prefetch in CDS hooks has been server support -- we have seen pretty limited support for client prefetch which means that clients sometimes get what they want and sometimes don't.
Josh Mandel (Sep 09 2020 at 17:56):
when you think about adding prefetch to smart, are you thinking that you would get the prefetch responses back as part of the access token response? It's a neat idea.
Tejay Cardon (Sep 09 2020 at 17:56):
Yup, that's fair. Similar to the lack of support for write back, it's a bit disappointing.
.
Tejay Cardon (Sep 09 2020 at 17:57):
To be honest, I'm not as familiar with the SMART protocol as I'd like to be.
My thinking was it could be part of the initial launch request. Along side the launch context.
Tejay Cardon (Sep 09 2020 at 17:58):
Thinking more deeply, I'm curious how often the FHIR server and the "host" application are independent. Would the launching context even have the data on hand, or would it just have to call to the FHIR server itself?
Josh Mandel (Sep 09 2020 at 17:58):
That has a few issues -- the launch as currently specified is just opening the browser to a certain url. The amount of data you can pass in a URL is pragmatically limited and the EHR is not authenticated to the app at this point.
Tejay Cardon (Sep 09 2020 at 17:59):
Right. So the EHR needs to do the handshake first to ensure that the URL is still trustworthy, etc.
Josh Mandel (Sep 09 2020 at 17:59):
And yes, what you just described is a real challenge: in many architectures the authorization server or app container is not in a direct position to have all the data an app might want.
Tejay Cardon (Sep 09 2020 at 18:00):
yup. so including it with the token response is likely not reasonable because the server providing the token response is almost certain to not have access to the data requested in the pre-fetch
Matt Varghese (Sep 09 2020 at 18:01):
The App is not authenticated to the EHR at the point of launch. So the SMART flow needs to happen. At that point, what is one additional web service request to get the same data? So would the value add obtained from this really justify the amount of effort and coordination on the part of the EHR to do this?
Tejay Cardon (Sep 09 2020 at 18:01):
so, what makes the context of a CDS hook different? Why can we trust the hook enough to send the pre-fetch data on initial call, but not the SMART app? I'm assuming it's related to the auth mechanism for each?
Jenni Syed (Sep 09 2020 at 18:02):
CDS hooks needs very very quick responses
Jenni Syed (Sep 09 2020 at 18:03):
and I think the idea was that if you were about to trigger 10 different CDS services that all needed the same data, it would make sense to put that in a common place (and CDS isn't coming from the auth server - it's coming from something typically more embedded in the system that has to speak FHIR)
Josh Mandel (Sep 09 2020 at 18:03):
The trust model in CDS hooks includes a signed token as a header in the request period this works nicely because the request is not hitting a web browser, so there is a way to pass headers and hook + prefetch content in a post body.
Tejay Cardon (Sep 09 2020 at 18:04):
Got it. that makes sense Josh.
Josh Mandel (Sep 09 2020 at 18:04):
Matt is exactly correct that the opportunity to actually save time in a smart launch is quite limited. It's basically one round trip on a protocol that already requires at least three.
Josh Mandel (Sep 09 2020 at 18:05):
Still I think this is a neat idea, especially for classes of apps that only ever need one set of data, like a simple calculator. these apps could get by without even needing an access token, if they had the right prefetch data. That said, I don't think this is a high-value target for standardization at this point.
Tejay Cardon (Sep 09 2020 at 18:08):
OK, so now let me go to the why, and see if you have a better way to solve my challenge.
We're finding that support for SMART is growing fast, but it's still pretty low. As we go to partners and customers, few are there. While SMART is pretty simple, it's not as easy as an authenticated web call. Given that our app needs certain data up front, but then doesn't call back to the FHIR server after that initial data, we're trying to find a way to simplify things.
In effect, we want to setup a REST endpoint where you can POST a FHIR bundle, sign the request, and effectively launch a smart on fhir app. This way, the host system doesn't have to support the full SMART or FHIR protocol. Just the FHIR shape for the POST payload.
An easy button, so to speak.
Anyone do anything similar?
Josh Mandel (Sep 09 2020 at 18:11):
The ude case makes sense. We have mostly been focused on standardizing core capabilities where standardizing will unlock a larger set of data and broader set of use cases -- and in the US anyway (because SMART is required by this year's onc regulations), we expect to see near universal support. We have avoided doing a lot of special case stuff.
Josh Mandel (Sep 09 2020 at 18:12):
I haven't heard of any particularly clever approaches to this problem, but one thing you could consider would be building a bridge interface -- I believe your assumption is that you want to connect to a clinical data system that does not support smart but can create arbitrary correct fhir payloads matching data requests. In this case, you could build a generic bridge from the inputs you described into a smart API provider, and then just run a generic smart app that is launched by the bridge.
Tejay Cardon (Sep 09 2020 at 18:18):
makes sense. That's been our approach so far, and may continue to be. In our case, we're integrating with pharmacy systems, and in other contexts where the ONC rules don't always apply.
Tejay Cardon (Sep 09 2020 at 18:19):
nonetheless, it is comforting to hear other people suggest the same approach we're taking.
Tejay Cardon (Sep 09 2020 at 18:19):
thank you all for your time
Josh Mandel (Sep 09 2020 at 18:22):
Sure thing! By the way, if you have implemented some specific capabilities in this space, have you considered whether it might make sense to open source this kind of bridge component?
Tejay Cardon (Sep 09 2020 at 20:29):
It was discussed, but I'll bring it up again. I'm an engineer turned architect turned product person. So I have influence, but not control over that sort of thing. What we developed is a cache of sorts. Internally we call it the FHIR cache, but we'd need approval to use that name publically.
In effect, you POST a FHIR bundle to it, get back a token, and then you can launch a SMART app and point the app back at the FHIR cache as your FHIR server. It retains the bundle for a period of time, and scopes access to the token provided in the return from the original POST.
As a result, you don't need a FHIR server, capability statements, OATH handshakes, etc. You basically just need to be able to provide syntactically correct FHIR objects (not sure we do much validation either), and only for those object types you know your SMART app will need.
Tejay Cardon (Sep 09 2020 at 20:29):
My guess is we'd be willing to give it to the community, but our use is limited enough that we probably can't commit to being good stewards of it.
Bas van den Heuvel (Oct 09 2020 at 06:55):
We have been playing with this topic on and off over the last year. The advantages of this approach is that launching an app in this way is much quicker than SmartOnFhir. Because of security concerns, we restrict it to static content only. Is this something we may want to take further? If so what would be appropriate landing spot for it? CDShooks, Smart launch, or a separate (new) IG?
Josh Mandel (Oct 09 2020 at 13:02):
Very interesting!
Josh Mandel (Oct 09 2020 at 13:03):
Do you have a write-up or any details you can share? If this can be described as a set of techniques for making smart apps launch faster, I think it would make sense to take up under the banner of the smart app launch implementation guide. I think that would make the most sense for developers reading about it anyway.
Last updated: Apr 12 2022 at 19:14 UTC
