Stream: cds hooks
Topic: notifying the EHR when a SMART link is done
Kevin Olbrich (Jun 07 2018 at 04:12):
Kevin Olbrich (Jun 07 2018 at 04:13):
Didn't mean to start that one in the github channel... oops.
Kevin Olbrich (Jun 07 2018 at 04:17):
Kevin Olbrich (Jun 07 2018 at 04:18):
@Isaac Vetter Yeah, that's pretty much what I need.
Isaac Vetter (Jun 07 2018 at 04:32):
Reposting here:
@Kevin Shekleton @Isaac Vetter Here's a scenario I'm trying to work through. A user clicks on a link in a cds-hooks card that launches a SMART app in a separate window. Once the user completes the workflow in the new window I would want to 1) close the window, and 2) cause the original page that launched the workflow to update so that if there are new cards to display, they will be visible. Is that the kind of workflow you would expect to occur in your respective EHRs, and if so, how can we implement something like that in the sandbox?
Hey @Kevin Olbrich !
If you can, it would make sense to move this conversation from cds hook/github, to the cds hooks stream.
Except for the need for the app to be in an external window, you have described the "decisions" workflow. Check out this older version of the spec. We took out this pretty awesome feature because very few people had implemented it and it wasn't obvious that the all the technical bits were right.
Note that SMART really tends to assume that the app is running in an embedded window/iframe. How would you expect the EHR to know that the workflow in the external window is complete?
Kevin Olbrich (Jun 07 2018 at 04:32):
What I need doesn't necessarily need to be a completely different window, it could be a popup or something similar. Perhaps the SMART window could use the postMessage API to tell the EHR that it was done and give it the details of the completed workflow.
Isaac Vetter (Jun 07 2018 at 04:34):
Kevin, yeah, postMessage is exactly what we've talked about. Should enabling this communication in a standards-based way be part of CDS Hooks or SMART?
Kevin Olbrich (Jun 07 2018 at 04:34):
yes
Kevin Olbrich (Jun 07 2018 at 04:36):
I guess you could make the argument that once you have started a SMART app, then the rest of the behavior is up to SMART. It may not really be specific to cds-hooks at that point.
Isaac Vetter (Jun 07 2018 at 04:38):
So, what would we want SMART to enable?
- window-close
- ehr-navigate?
- fhir query?
Those are the outstanding questions in my mind.
Kevin Olbrich (Jun 07 2018 at 04:40):
The things I know I would need would be
- window close
- place an order for the drugs the CDS service suggested
- refresh the patient-view
Isaac Vetter (Jun 07 2018 at 04:42):
and "place an order" puts an unsigned order in the clinician's list of orders to sign?
and "refresh the patient-view" is a re-query for CDS Hooks cards?
Isaac Vetter (Jun 07 2018 at 04:44):
In my system, "place an order" definitely makes sense. It seems like "refresh the patient-view" does as well, but we haven't started looking at that yet.
Kevin Olbrich (Jun 07 2018 at 04:44):
I could probably get away with just the 'window close' and 'refresh' for now. The workflow would look more like
1. show a card inviting the user to launch a SMART app
2. user interacts with the app and makes a decision, the app saves some state about the decisision
3. the window closes
4. the patient-view refreshes and the cds-hook app now shows a suggestion card that might include something like 'order drug xyz' based on the patient and saved state.
Grahame Grieve (Jun 07 2018 at 04:53):
doesn't this overlap with FHIRCast? I'm really suspicious of something described in such EHR centric terms here
Kevin Olbrich (Jun 07 2018 at 04:56):
@Grahame Grieve FHIRcast did cross my mind too. I just haven't dug into it enough to know if it would solve the problems we have.
Isaac Vetter (Jun 07 2018 at 05:05):
FHIRcast is context synchronization. Suggesting an order is such a critical piece of CDS Hooks that it seems that it should be native.
The whole "external browser" thing really does suggest FHIRcast to me, too.
Grahame Grieve (Jun 07 2018 at 05:06):
what's the difference between 'suggesting an order' (a medication order?) and 'suggesting a system action'?
Isaac Vetter (Jun 07 2018 at 05:07):
that's a great question. Currently, I know how to represent an order in FHIR, I don't know how to represent a "system action" in FHIR.
Grahame Grieve (Jun 07 2018 at 05:08):
what kind of order? a medication request? a service request? a task?
Isaac Vetter (Jun 07 2018 at 05:08):
also, the nature of "suggest" means that in CDS Hooks, a user click is required to activate the order; whereas in FHIRcast, the "system action" should be taken automatically
Grahame Grieve (Jun 07 2018 at 05:11):
umm are these different? the FHIRcast system action would be 'propose an action'
Kevin Olbrich (Jun 07 2018 at 05:13):
My preference would be for the end user to push a button in our SMART app and then get dropped into the order entry system with the proper order pre-populated. That seems more in line with the FHIRcast approach. I would rather not have the user 'select' some course of treatment and then have to take a second step to actually make it happen. Especially when that second step probably has a third and fourth step embedded in it.
Kevin Olbrich (Jun 07 2018 at 05:13):
It's not hugely different at this point and even just getting the page to refresh and show a suggestion card that would place the order would be sufficient and pretty useful.
Isaac Vetter (Jun 07 2018 at 05:20):
Certainly, cds is a subset of context synchronization. CDS Hooks has been successful by cranking down the scope neccessary to implement. Grahame, definitely you're right that we could represent an activity change request in FHIR with something like task.
There are important distinctions in the primary use-cases. For these fancier (but obviously desirable workflows), the similarities start to reveal our lack of foresight.
Using something like postMessage for a communication channel would limit the app to being on the same machine as the clinical system it was communicating with.
Lloyd McKenzie (Jun 07 2018 at 05:21):
System action might be representable with Task
Kevin Olbrich (Jun 07 2018 at 05:21):
FHIRcast seems like it would avoid a whole bunch of browser bugs and CORS issues.
Isaac Vetter (Jun 07 2018 at 05:22):
Kevin, any feedback on websockets ? We really need some implementer feedback on this.
Isaac Vetter (Jun 07 2018 at 05:22):
https://github.com/fhircast/docs/issues/33
Kevin Olbrich (Jun 07 2018 at 05:27):
Interesting.
Kevin Olbrich (Jun 07 2018 at 05:27):
web sockets do seem interesting
Kevin Olbrich (Jun 07 2018 at 05:27):
BTW, who would host the `hub? The EHR or the CDS service?
Isaac Vetter (Jun 07 2018 at 05:29):
The system driving the workflow hosts the hub, so, perhaps the EHR.
Kevin Olbrich (Jun 12 2018 at 19:18):
@Kevin Shekleton did you have any thoughts on how to tell the EHR that a SMART app launched from a cds-hooks card had completed it's interaction, and what should happen when it does?
Kevin Shekleton (Jun 12 2018 at 19:34):
We need to revisit Decisions in CDS Hooks ;-)
Kevin Shekleton (Jun 12 2018 at 19:43):
You may be interested in taking a look this. @Alexander Tatiyants, myself, and a few others noodled on this a couple of months ago while brainstorming some use case. Alex did a great write-up of our conversations.
Kevin Olbrich (Jun 12 2018 at 20:28):
@Kevin Shekleton thanks! That's a pretty thorough write-up. Frankly, I'd be happy for now if the EHR just refreshed the current screen when a SMART app closed. I can render a card with suggestions for the next step in the workflow that way at least. It's not ideal, but sounds like it might be something the various EHR vendors could implement sooner rather than later.
Kevin Olbrich (Jul 12 2018 at 14:05):
I would love to see some work around this at the next connectathon. I thin @Isaac Vetter had an example that could be used for this.
Isaac Vetter (Jul 16 2018 at 03:28):
Hey @Kevin Olbrich , our current scenario(s) for the Sept connectathon is just implementing the 1.0 spec. I do think that we should be pushing towards new features (ex: Radiology GAO, decisions, analytics?). Do you agree that the (redacted from spec) decisions is a reasonable way to implement what you need?
Kevin Olbrich (Jul 16 2018 at 22:41):
@Isaac Vetter if this... https://github.com/cds-hooks/docs/wiki/Decision-Proposal#1-user-decision-fulfillment is what you were thinking of, then yes. That seems like a reasonable way to implement. I am a bit concerned about the reliance on javascript to implement this, but the general workflow seems appropriate.
Last updated: Apr 12 2022 at 19:14 UTC
