FHIR Chat · docs / Issue #4 Strengthen documentation around app links · cds hooks

Stream: cds hooks

Topic: docs / Issue #4 Strengthen documentation around app links

Github Notifications (Apr 25 2017 at 18:54):

kpshek commented on Issue #4

@Josh Mandel - Sorry for coming in late on this:

The other requirement to highlight here, I think, is letting an app finish and return control back to the EHR...
...Right now we do this using a redirect URL: the app's job is to redirect to that URL if/when the user has finished working with the app...

To be clear, the discussion on this issue prior to Feb 21 been focused around links -- both absolute and SMART app links. We weren't discussing the decision workflow. I mention this because I did not see the redirect field being used just anytime a user follows a link in a card and wants to come back to the EHR. I saw redirect existing purely for the decision workflow.

If redirect is to be called when the user closes any link they follow on a card, how is the EHR supposed to know not to re-trigger decision support (since no decisions were made)?

Also, redirect would only need to be called if the link were capable of even following the redirect. I'm guessing in nearly every absolute link case, we cannot follow the redirect (since those likely aren't apps). Additionally, my assumption here is that EHRs aren't going to want to change navigation to a link in a card. Rather, I'm assuming that EHRs will likely want to open the link in a new window or component/tab within the EHR itself.

@Josh Mandel - Did you think we were using redirect when a user is done visiting any link on a card or did some wires get crossed here?

Github Notifications (Apr 25 2017 at 20:58):

jmandel commented on Issue #4

If redirect is to be called when the user closes any link they follow on a card, how is the EHR supposed to know not to re-trigger decision support (since no decisions were made)?

Under the current model, the EHR always re-triggers any time a site or app explicitly "returns control" via the redirect. That's part of handling a "return" operation. Of course, we could add on a parameter (&refetch=yes-please, or whatever) to save the extra work.

I'm assuming that EHRs will likely want to open the link in a new window or component/tab within the EHR itself.

Sure, this is up to the EHR to decide. But in the event that the EHR opens a new window and doesn't receive "return", the EHR is basically saying "You don't get to make decisions". That's okay...

@Josh Mandel - Did you think we were using redirect when a user is done visiting any link on a card or did some wires get crossed here?

I think redriect can apply any time a user clicks a link on a card. Now, there could always be _additional_ (out of band, from the CDS Hooks perspective) ways to "finish with an app" (e.g. the EHR might also display a big "X" next to the app view, or might just open it in a new window that's totally disconnected from the user session). But as an in-band way of "returning", the redirect works equally well for SMART apps and other linkable services.

Github Notifications (Apr 25 2017 at 21:09):

kpshek commented on Issue #4

So I went back through and re-read our documentation on redirect. I totally missed that it is intended to be used to return control back to the EHR after following any link. I always thought it was just for the decision workflow.

I'll log a new issue around redirect and we can move the discussion there.

Last updated: Apr 12 2022 at 19:14 UTC