Open isaacvetter opened 6 years ago
I thought I'd throw up a strawman proposal for consideration by better minds --
A CDS service indicates that a returned app link can be immediately opened and that the card needn't be shown the to user by populating an optional boolean field in the CDS Response of cards.links.auto-launch. If the app was immediately launched from the EHR, potentially without the user seeing the card, the SMART server would include an additional SMART launch parameter of cds-hooks-auto-launch: true. The presence of this SMART launch parameter (alongside the access token and any service provided appContext) would enable the app to re-iterate any important information that otherwise would have been presented in the card.
A CDS response should be limited to a single auto-launched app link.
This is a bit of a brute force approach, what's a more elegant way to do this?
One somewhat simple approach to this would be to autolaunch a SMART link if:
Hey @olbrich!
Currently the indicator /hard-stop value refers to a card, not necessarily a link, right?
Some of the additional considerations that I've been thinking about are:
What do you think?
Isaac
Could this feature be configured so that the local health system can decide whether or not to allow/enable auto-launching a SMART app? Ideally, this would be done at a service by service level, rather than for all CDS Hooks services. Also, if we auto-launch an app, I'm not sure it makes sense for the SMART app to look like the typical SMART app that takes up most of the screen. Instead, it may make more sense for it to open as a modal window along the lines of a CDS Hooks card. I think it could be quite jarring, for example, if you enter a high blood pressure, and instead of a card asking -- do you want to use the hypertension SMART app? -- as soon as you enter the blood pressure the hypertension SMART app automatically opens and hides what you were working on. I'm not aware of other instances where an EHR behaves like this, except for when you explicitly click on something (tab, link, etc.) that indicates you will be taken to a different screen.
From my perspective, the EMR owns the UI and therefore determines if it is reasonable to auto-launch. The service can provide a hint, but it does not control. As mentioned by @kensaku-kawamoto, that should probably be configured on the EMR for a particular service or perhaps even more discretely (like in which workflows, user preference, etc). The CDS service needs to assume that the auto launch does not happen and the card should represent something reasonable that might be displayed to the user if that is the case.
To further expand the scenarios, it is completely possible to have multiple cards returned, representing different issues, but referencing a single link/app which will manage all of them. You could also have an info card which (fairly obviously) shouldn't need an auto-launch and a hard stop card which would prefer an auto launch. I think it is also reasonable to have multiple cards providing different auto launch links - perhaps the EMR launches them in order - however in any case, such situations will occur in real-world CDS as a CDS service likely won't always be limited to a very narrow problem domain.
I don't like the idea of 'hard-stop' or such indicating you should auto-launch. The card may have both a link and suggestions, allowing the use of the app or pick a suggestion. The assumption in this case is that the app provides more detail, context, etc.
I think it is reasonable to include the cards.links.auto-launch: true as a hint that the CDS service would prefer that the link be auto launched (smart or not smart). The EMR can then look at all of the cards, the context (workflow, etc) and determine if it should auto launch the link (or potentially multiple links). If auto launched, the card(s) referencing the link auto-launched would not be displayed as that would generally be redundant.
My thoughts on this (a lot of which echos others as well):
Whether or not a SMART app link can be automatically opened depends upon:
summary
and source
doesn't need to be displayed, or, somehow this information is communicated via other meansBased upon these considerations, I feel like the scenarios in which these all align will be very narrow. As such, I don't think we need to look at changing anything with respect to the specification right now (eg, adding a new field). I'd prefer we take a wait and see approach with what real productions look like this year (and likely next) to see if there is sufficient demand to handle this in a first-class manner.
Until then, we always have extensions for those serious about implementing this particular behavior in their implementations.
Hey Kevin,
Thanks for the comments. The question is, how to do this:
Whether the CDS Service returns a card in which the card summary and source doesn't need to be displayed, or, somehow this information is communicated via other means
What are those other means?
Isaac
What are those other means?
It is hard to say without specific use cases. To speculate, perhaps:
When the EHR is automatically opening the SMART app, maybe that app is embedded within a frame/window within the EHR app such that the card summary and source is displayed alongside the SMART app.
OR
When the SMART app launches, perhaps it displays face up in its UI the summary and source indicating why the SMART app is relevant and was launched
While this is just conjecture, I am of the opinion that if an app wants to get launched automatically, it would run in place of the rest of the card. To put another way, the card would normally say something like 'your input is needed, please click the link' or perhaps a limited attempt to rehash the details that the app would show (along with please click the link). Would this always be the case? - probably not, but then it would probably catch 90% of the cases. As mentioned above, indicating auto launch likely directly impacts the user's workflow, so doing that for something that is not particularly important would be the sign of a bad CDS service.
Our service does provide such a card (please click the link) when we require user input because CDS Hooks has no facilities for Q&A.
I agree with Kevin's recommendation to hold off on making changes to support this at the moment and to get more experience on this area through some piloting work, perhaps at Connect-a-thons.
We often describe CDS Hooks as a way to precisely and intelligently insert a SMART app into a clinician's workflow -- saving them the time, clicks and mental energy of finding a SMART app.
In practice, this is done by inserting a card into the clinician's current activity in which a specific hook / workflow event is occurring. Displaying a card is valuable if it contains suggestions, multiple links, and/or information or there are multiple cards. Otherwise, immediately launching the SMART app would simply save the user a click.
How should an EHR determine if it's appropriate to immediately launch a SMART app link? If a card returns only a single SMART app link and no other content, perhaps that should signal to the EHR to auto-launch, if otherwise appropriate? In practice, even SMART apps that would make sense to be auto-launched (skipping the display of a card) will still be returned alongside explanatory information. CDS developers want to ensure that there's some justification to the clinician that the SMART app is worth opening!
If an auto-launch of a SMART app is reasonable within a workflow, should the EHR both display the card and also immediately launch the app?