Stream: cds hooks
Topic: Launching a 'native' app instead of a SMART app
Lloyd McKenzie (Sep 08 2021 at 15:31):
@Isaac Vetter, you had submitted FHIR#24614 against DTR indicating that instead of a SMART app, the DTR functionality should be able to be a local EHR function. How did you envision a CRD CDS Hook coming back that would allow the launching of the functionality? There are two questions here:
- How can a CDS Hook card allow invocation of a set of local EHR functionality rather than a SMART app
- How should the CDS Service know whether to (and how to) point to a set of local functionality rather than a specified SMART app, or for that matter allow a choice of what app to actually use or have an EHR choose what app to use
Josh Mandel (Sep 08 2021 at 15:54):
SMART Web Messaging takes a crack at this, modeling a "please launch a specific local EHR functionality" as a ui.launchActivity message (basically: an activity type and params, where activity types are an open set, with a small catalog as a starting point).
Lloyd McKenzie (Sep 08 2021 at 16:08):
Ok, but that would be a "launch this functionality from a SMART app", not "launch this functionality from a card", correct?
Josh Mandel (Sep 08 2021 at 16:22):
In the case of SMART Web Messaging, yes. I'm just calling out a place where shared modeling of the problem (i.e., what does it mean to "launch an activity", what activities exist, what parameters do they support/require) could serve needs of multiple projects. The use case sounds the same.
Lloyd McKenzie (Sep 08 2021 at 16:24):
Fair enough. Thanks. Thoughts from others about exposing this in CDS Hooks?
Isaac Vetter (Sep 22 2021 at 16:57):
Hey Lloyd, no doubt you've put more though into this than I have, but I was expecting the local EHR function to interact with the payer in the same way the DTR app is prescribed to work. My intent with that jira was to not arbitrarily limit the DTR functionality to only a 3rd party system, if the EHR could perform it.
Isaac Vetter (Sep 22 2021 at 16:58):
In DTR, the mechanism by which the app receives the location and technical ability to access the CQL is defined here: http://hl7.org/fhir/us/davinci-dtr/2019Sep/specification__behaviors__retrieval_of_payer_resources.html. It's a profiled appContext field.
Isaac Vetter (Sep 22 2021 at 16:59):
To attempt to specifically answer your questions ...
How can a CDS Hook card allow invocation of a set of local EHR functionality rather than a SMART app
maybe a canonical url in the card?
Isaac Vetter (Sep 22 2021 at 17:00):
How should the CDS Service know whether to (and how to) point to a set of local functionality rather than a specified SMART app, or for that matter allow a choice of what app to actually use or have an EHR choose what app to use
This is just my opinion -- personally, I think that CDS Services, including payers, should have the technical ability to customize their CRD functionality per provider organization to ensure appropriate clinical user experience.
Isaac Vetter (Sep 22 2021 at 17:05):
Largely unrelated -- Re-reading DTR's "Retreival of Payer Resources" (and I think I'd submitted a comment as well), it really seems like a bad idea to bounce the access_token to the payer's FHIR server through the EHR. Wouldn't it be better for the app to use backend SMART / client_credentials to authenticate to the payer's server?
Lloyd McKenzie (Sep 22 2021 at 19:23):
@Isaac Vetter, I'm not opposed to providing a mechanism for the EHR to launch local functionality rather than a SMART app. But that need would presumably not be CRD-specific. It's just as realistic for an EHR to have its own Opioid prescribing solution or growth chart tool and want to give the user the ability to launch those instead of the SMART app version. And in those cases, it's possible that the CDS service might have information that would be relevant to 'initiate' the starting point for the EHR's functionality.
There's also the question of how the CDS service is to know that there's EHR functionality that should be launched. It might be feasible for a payer to adjust for an overall EHR product, but we definitely don't want to customize on a per-hospital basis. That's definitely not the outcome we'd want for a "standard". However, whether a feature is enabled by the EHR might well be hospital-specific. If we're going to introduce a capability like this, it should be via a generic mechanism and not treated as something that's CRD-specific.
Also, do we believe EHRs actually have support for FHIR Questionnaires with embedded CQL for population? (That's well beyond what Argonaut got agreement on.)
In terms of using SMART / client_credentials, do we expect SMART apps to be able to protect client secrets? How would this be managed? If you think this is possible/reasonable/appropriate, feel free to submit a change request.
Isaac Vetter (Sep 22 2021 at 20:08):
- Security of access token in
appContext- Found my jira! The resolution was to update the spec to have the DTR app use backend services, the jira was marked as applied, but the change hadn't been applied (or had been and then was again changed back later). I changed to "Not Applied" (jira for the win!). The comments on that jira are a fairly thorough analysis of the options.
-
do we expect SMART apps to be able to protect client secrets
- Definitely yeah, there's a confidential client ... "profile" in SMART that describes this. It's common for apps to have client secrets/private keys. It's less common for user-facing apps to support both auth code and client_credentials flow, but not unheard of or unreasonable, in my experience.
Lloyd McKenzie (Sep 22 2021 at 20:10):
Perfect - then it's DTR's fault and not mine ;)
Isaac Vetter (Sep 22 2021 at 20:11):
oh yeah, my default assumption is that that's the case for all the problems .... :wink:
Lloyd McKenzie (Sep 22 2021 at 20:11):
Your thoughts on defining a generic mechanism for CDS Hooks to be able to a) identify the availability of EHR-specific functions; and b) indicate to the user that they might want to launch them?
Lloyd McKenzie (Sep 22 2021 at 20:12):
(Thoughts also welcome on providing guidance on the ability to defer/assign cards to be acted on by others)
Isaac Vetter (Sep 22 2021 at 20:19):
how the CDS service is to know that there's EHR functionality that should be launched. It might be feasible for a payer to adjust for an overall EHR product, but we definitely don't want to customize on a per-hospital basis
I'd expect customization/configuration to be reasonable, at a minimum, at the level of the client id. Right now, we have three client ids involved:
1) used by the payer's CDS service, issued by the EHR
2) used by the DTR app, issued by the EHR
3) used by the DTR app, issued by the payer
Isaac Vetter (Sep 22 2021 at 20:20):
It seems like during the registration process of either the app or the CDS service (#1 or #2) would be the natural place for the payer to determine and configure capabilities. That would be for the EHR software though, and not a particular health system ("hospital" or system comprising a hundred hospitals).
Lloyd McKenzie (Sep 23 2021 at 01:53):
That seems reasonable - and would be the time to address @Matt Varghese's concern about knowing that a particular app is a 'DTR' app.
Matt Varghese (Sep 23 2021 at 02:02):
Ha ha, @Lloyd McKenzie, now you're accepting that the CDS Client needs to know that a particular App is the DTR App. I would rather this is captured in the data exchange, rather than orthogonally configured. (I kinda like @Josh Mandel's phrase: "dark arts" type stuff). I was talking to my boss and he suggested that perhaps we should walk through existing Prior Authorization workflows with the Da Vinci Burden Reduction group..
Lloyd McKenzie (Sep 23 2021 at 02:16):
I'm saying that if it needs to happen, the time to do it is at app registration, not in the card. From a CDS hooks perspective, an app is an app and all apps are aimed at humans, not at automated processes.
Lloyd McKenzie (Sep 23 2021 at 02:17):
We absolutely aren't trying to mirror existing prior auth processes. We're very much intending to change them, to ensure that all clinical data is collected up front and that the clinician is 'done' with the prior auth (including any possible follow-ups) before the patient leaves the room.
Josh Mandel (Sep 23 2021 at 02:37):
I think spending some time understanding current workflows would be extremely valuable.
Josh Mandel (Sep 23 2021 at 02:38):
I'd love to have a tour/discussion on this.
Matt Varghese (Sep 23 2021 at 02:50):
@Josh Mandel: https://jira.hl7.org/browse/FHIR-33959 and https://jira.hl7.org/browse/FHIR-33958
Lloyd McKenzie (Sep 23 2021 at 16:54):
We'll figure out a CRD call time that will work and will post an invite here. (@Robert Dieterle)
Isaac Vetter (Sep 23 2021 at 18:35):
Lloyd, CDS talked a little bit about how to better enable and support CRD's use of CDS Hooks yesterday. The outcome was the same as the above -- to find some time for discussion.
Bryn Rhodes (Sep 23 2021 at 21:39):
CDS Discussed this with @Robert Dieterle during a session today and he offered the CRD call two weeks from yesterday (so the 10/6 call, details on the HL7 calendar here)
Last updated: Apr 12 2022 at 19:14 UTC
