Stream: cds hooks
Topic: Can AppContext of one App be used to launch a different App?
Matt Varghese (Sep 15 2021 at 18:31):
I just sat in on a conversation where the CRD track was talking about taking the App Context in a CDS Hooks SMART App Link, ignoring the URL, and launching a completely different App using that App Context. Is this conformant with the CDS Hooks spec?
Lloyd McKenzie (Sep 15 2021 at 19:01):
I'm curious about that too. It is something that some EHR vendors have expressed a desire to do. And, where there's a need/desire, I expect it'll find it's way into the specification if it's not already explicitly there.
Matt Varghese (Sep 15 2021 at 21:24):
This has already been written into the CRD IG: http://www.hl7.org/fhir/us/davinci-crd/hooks.html#launch-smart-application
However, I'm not sure how this is going to work, when for example, I have a single endpoint which is CRD + Other CDS service, and my card contains two or more SMART Apps - which one is the DTR App?
image.png
Also, from a security perspective, the above describes a JWT being passed to someone other than the intended recipient. Is that good practice?
Josh Mandel (Sep 21 2021 at 21:48):
talking about taking the App Context in a CDS Hooks SMART App Link, ignoring the URL, and launching a completely different App using that App Context. Is this conformant with the CDS Hooks spec?
I mean, this certainly isn't something we intended and I'd consider it to be "dark arts" type stuff. App Context is defined by the CDS Service and is opaque to the Client (EHR), so how would the EHR know what set of apps were capable of accepting this kind of context-swap? Any well-behaved app would need to authenticate its context to protect against injection attacks. But if a group of apps decided to form a kind of trust framework and trust each others' context... and if the EHR wanted to model these "App Collections" explicitly and swap context among them, this could work, technically. But I think a safer pattern would be for the CDS Service to explicitly return a list of apps, each with (potentially the same) context.
Lloyd McKenzie (Sep 21 2021 at 22:57):
There's also the question of "how does the CDS Service know what apps are even available to the user through the EHR?"
Josh Mandel (Sep 21 2021 at 23:12):
The main intention of returning app link cards was in the case where the CDs service and the CDs app are offered by the same organization; think about companion apps that work together with the service to provide more in-depth experience
Lloyd McKenzie (Sep 22 2021 at 00:39):
No issue with the CDS service and app knowing about each other. But how does the CDS service know what apps the EHR has available? Or is that expected to be pre-managed at the time the service is enabled? (I.e. "if you're going to support connections to this service, please also authorize the launching of these two apps")
Josh Mandel (Sep 22 2021 at 03:04):
The CDS Service and the app would be offered together as a package. I'd think of the app as essentially part of the CDS Service, if it's using AppContext
Lloyd McKenzie (Sep 22 2021 at 04:12):
Ok. But if we're talking about multiple alternative apps so that the user can pick the one they want, then that's no longer really part of a package. (And ideally, the user wouldn't be faced with a choice, but would instead only be exposed the one either they've chosen in advance or their organization has chosen in advance.)
Josh Mandel (Sep 22 2021 at 13:02):
Sure, this is a different thing; it could be modeled on top of existing params like AppContext, but it'd probably be better to add an explicit extension if the context is non-opaque / understood by the EHR.
Matt Varghese (Sep 22 2021 at 13:24):
I think the problem here is, CRD is changing appContext from an "opaque handle" understandable to the App only, into data that has semantic interpretation. As Josh puts it,
if a group of apps decided to form a kind of trust framework and trust each others' context
However, this is not an arbitrary group of Apps, but an HL7 standard. So if I were writing CRD IG, I would capture the data in a designated discrete field, rather than hacks / "dark arts" type stuff.
In fact, the CRD Card could just contain this data, and not bother with returning the App, if not using CDS Hooks (URL is required in CDS Hooks.)
Matt Varghese (Sep 22 2021 at 13:35):
Here's a graphical representation of the problem as I am coming to see it..
image.png
And so I have written a few JIRA issues around this including this one https://jira.hl7.org/browse/FHIR-33963 asking if CDS Hooks is the right vehicle for CRD.
Matt Varghese (Sep 22 2021 at 14:59):
We have started feeling like we may have to have two implementations of CDS Hooks.
- One, the existing implementation, for regular decision support, including the regular order-select and order-sign hooks etc.
- And a separate implementation of CDS Hooks specific to CRD that will still advertise an order-sign hook, but will do one order at a time, and will likely only support a single card and at most one SMART App.. Probably no suggestion support either.
To me, that defeats using CDS Hooks :(
Lloyd McKenzie (Sep 22 2021 at 15:18):
In the current release of CRD, the appContext is indeed an opaque handle, understandable to the App only. However, we've had a request to standardize the appContext such that it can be consistent across apps, making it easier to swap apps in and out. There are no dark arts involved here. You launch the app, it goes and grabs the relevant Questionnaires, value sets, etc., populates them as it can based on querying the EHR and guides the user through populating the rest. When it's done, it writes a QuestionnaireResponses to the EHR that can be subsequently be used as a basis for submitting PAS requests.
When we developed CRD, none of the EHRs had the ability to run Questionnaires with embedded CQL that could manage population of questionnaire answers (and to the best of my knowledge, that's still true), so passing back the Questionnaires alone wouldn't suffice. Also, sometimes the logic for what's covered and when prior authorization is needed is proprietary, so wrapping it in an app outside the EHR might be necessary even if EHRs had full support.
As I've explained CRD definitely wants to tie into the regular hooks. We want the information about what's covered and what's not to be in front of the clinician at the time the drug, lab test, referral procedure, or whatever is selected. There's no need to do one order at a time. And there's definitely suggestion support - the payer might suggest alternate meds, lab tests or other things based on what's covered, what's cheaper, what's a required first-line therapy, etc.
CRD is perfectly happy to have there only be one app tied to the service and have zero ability to launch equivalent EHR capability. The ability to support multiple apps (so as to allow selection of a 'preferred' app) or support launching an EHR's internal functionality rather than launching a SMART App are new requirements generally coming from the EHR community. We're open to those, but they're in no way essential to make CRD work.
Matt Varghese (Sep 22 2021 at 15:32):
@Lloyd McKenzie
As I've explained CRD definitely wants to tie into the regular hooks.
That can only happen if the CRD Spec is compliant with the CDS Hooks spec.
We have a production CDS Hooks implementation that supports many, if not most, of the features of CDS Hooks. Yet CRD as written will not work with that implementation and will break downstream workflows.
Lloyd McKenzie (Sep 22 2021 at 16:46):
How? You only need to support one of the specified Request types, so if you don't support DeviceRequest or some of the others we added, that's ok. You're also only required to support a couple of the card types, so if you can't handle receiving Tasks or Questionnaires, that's also fine. The configuration stuff is optional. What is it about the way the CRD spec is written that prevents you from complying "as is"?
Matt Varghese (Sep 22 2021 at 21:37):
@Lloyd McKenzie, I need to make both sides of this workflow because we have both provider and payer customers. The CDS Hooks implementation as it stands does not have the information I need on the payer CRD service side for determining prior authorization requirements at the point of order-sign (nor order-select) hook. Then, DTR App needs to be recorded on to the referral record for later launch, but the CDS Hooks implementation does not know which app is a DTR App (nor which card is a CRD card), or which order this needs to be recorded on. And since location selection and provider selection happens after all of this, whatever evaluation the service did will no longer be valid at the point of claim (real claim, not PAS claim) submission.
Lloyd McKenzie (Sep 23 2021 at 01:57):
Are you saying that for none of services covered by the payer would you be able to determine whether coverage existed or not or whether prior authorization was necessary? I.e. you'd always need to fall back to DTR? And that your payer would have no other useful information to share (cheaper covered therapies, required first line therapies, known duplicate therapies) that could be provided back with CRD?
The CDS Hooks implementation shouldn't know that an app is a DTR app. If you need to know, it should be managed when the app is registered, not every time you receive a link to it.
Matt Varghese (Sep 23 2021 at 02:48):
@Lloyd McKenzie, there are some services for which the rules are simple. But in those cases, logic in the EHR itself can answer without calling to a payer. So for this to be meaningful, we should be able to address the more complex cases. This was why I had previously asked what are the inputs that go into prior authorization - have we done any research on that? ( https://jira.hl7.org/browse/FHIR-33958 )
I don't realistically see a payer doing cheaper coverage therapies, required first line therapies, known duplicate therapies etc. within their CRD Service. Rather these would far more likely be like with Radiology, where payers will say, you have to show that say 90% of the time, your order gets a "pass" from an actual decision support service like PAMA Radiology Appropriateness Services. The kind of knowledgebase, fidelity of that knowledgebase, people, logistics of upkeep etc. required to do active decision support feels different from what is required to review provider decisions against guidelines in the fashion payers generally do (anything complex in prior authorization gets marked for Medical Director Review on the payer side). Even if a payer had such a line of business, it probably would be organized separately from utilization review, so that it would make more sense for them to have a separate decision support endpoint / service?
Actually, a lot of the information in the CRD and DTR Apps need to be interpreted by the EHR. I have written "the what" as well as "the why", in this JIRA ticket: https://jira.hl7.org/browse/FHIR-33961 . As far as I understand most EHRs will already have a referral data-model and extensive workflow support, even though I believe FHIR doesn't really capture it well (?) This is why, I have also requested we do a survey of workflows: https://jira.hl7.org/browse/FHIR-33959 . Unlike with decision support which is much more atomic, prior authorization is a full fledged workflow involving many people. Provider cannot really do it all - in fact I'd think most organizations have staff who know these things better than the provider?
Matt Varghese (Sep 23 2021 at 02:49):
The real valued add that CRD/DTR/PAS can do are the following
- Being able to conclusively know instead of the current "informed guesswork" the EHR can already do about whether prior authorization is required. This doesn't at all need to be the provider themself. It will save a lot of paperwork (or electronic paperwork to coin that phrase), whereas if the CRD Service falls short of the "informed guesswork" that the EHR can do today, that adds a lot of paperwork unnecessarily in the form unnecessary data gathering and unnecessary PAS submission.
- The DTR App showing the exact information that is required for prior authorization, instead of the referral coordinator "generally knowing" / doing "informed guesswork" that these are all the paperwork we need to submit to this payer. Again bear in mind, there is sufficient paperwork enough to make such a role as referral-coordinator necessary. We can't move all of that to the provider, and it cannot all be done in one sitting (although I really am optimistic that DTR will improve efficiency)
- PAS is actually not all that much of an improvement, because there is already X12 interfaces. The reason I think prior authorization happens over the phone or fax is that every provider organization doesn't have an interface set up with every payer organization. PAS may improve things a little if because it is a JSON based standard it is easier to stand-up than X12 interfaces.
Also that same existing adoption problem for X12 applies for CRD and DTR - it should really blend into the existing workflow, high signal to noise ratios, and be easy to stand up, if it is at all going to be adopted organically.
Matt Varghese (Sep 23 2021 at 02:58):
There is also another thing I want to point out. As I understand, prior authorization is the responsibility of the performing party. Not the ordering party. It is the performing party who later needs to get paid, and won't get paid if the service was not prior authorized.
Often times, these are different organizations. In these cases, the ordering provider wouldn't even care whether prior authorization is required, and wouldn't work through obtaining the prior authorization. (And this is also another reason why a payer would want to have their CDS as a separate service from their CRD).
Note that this also means, not only could a DTR app get recorded on a referral, it could get sent to a different organization (?) Likewise, if the referral went from the ordering side to the performing side on paper (because there isn't always interfaces to send it between two provider organizations) the DTR information is lost, unless we make another hook. This is also where (1) I wonder that we should have a CRD specific hook and (2) I really wonder if CRD should use CDS Hooks at all. The hook at data entry on the performing side will show to a very non-clinical user.
Matt Varghese (Sep 23 2021 at 03:16):
I wrote the above also up as a JIRA ticket: https://jira.hl7.org/browse/FHIR-33998 Prior Authorization is the responsibility of the performing provider/organization, not the ordering provider/organization
Lloyd McKenzie (Sep 23 2021 at 04:11):
The scope of CRD is for a payer to provide any useful information it can. It includes information about coverage and prior authorization, but also clearly supports far more use-cases - this is explicit in the spec. Whether a payer chooses to provide multiple CDS services with different decision support functionality offered by each or a single service is up to them. The intention is to get payers to intervene directly in the order process with the information they have to ensure the best decisions are made.
The payers are the source of truth for knowledge about what they'll pay, as well as average costs, so their databases there should be good indeed.
There is no expectation that provider will necessarily do it all, but there is an expectation that all actions that need to be taken by the provider are taken at the time of order entry (at least as much as feasible) and that he patient never has to come back for a subsequent visit because requirements for prior authorization were missed during that initial visit. That bit absolutely needs the provider. And the EHR won't know whether provider input into DTR is necessary unless either a) provider always launches DTR; or b) we split the DTR app into two, with one for content that must be provided by the provider or requires patient interaction and one for content that can be supplied subsequently by workflow processes. Right now, we assume (a). If (a) is problematic, we could explore pursuing (b).
Note as well, that the intention of DTR is to minimize much of the paperwork by gleaning as much as possible from system query. In many cases all that may be required for a prior authorization is a couple of attestations by the provider.
PAS is essentially just a way of putting a FHIR facade on the existing (mandated) X12 interaction. If you already support the X12 275 and 278 functions, PAS doesn't buy you much (other than making FHIR available to the payers who might like that).
Brett Marquard (Sep 23 2021 at 14:29):
There is no expectation that provider will necessarily do it all, but there is an expectation that all actions that need to be taken by the provider are taken at the time of order entry
Zero chance the provider I have in rural country will do this. What payers + EHRs + providers are you piloting this with?
Brett Marquard (Sep 23 2021 at 14:30):
She has a team of people that handle prior auth - and while I expect CRD to reduce the burden, pushing it all to her will not go over well.
Lloyd McKenzie (Sep 23 2021 at 23:56):
The objective isn't to push all of it to the provider, only the part the provider is going to end up having to do anyhow. Provider will need to order certain tests, provider will need to attest to certain things, provider may need to ask patient some extra questions. Also keep in mind that when the app is able to already check what tests have been done and what the results are and what medications have already been used and what conditions are recorded, there'll be a lot less information to prompt for. Obviously prior authorization questions related to "who's going to perform the service" shouldn't be handled by the provider if they're not the ones who typically dispatch the service - though knowing up front that prior authorization is only needed if the service is filled out-of-network might influence where you choose to send the patient.
Last updated: Apr 12 2022 at 19:14 UTC
