Stream: cds hooks
Topic: user-triggered hooks request aka "app button"
Aziz Boxwala (Jul 19 2018 at 17:53):
Following up from the CDS WG call on 18 July. I proposed a new type of hooks trigger that is initiated by the user. explicitly In comparison, the current triggers are initiated implicitly through other actions or events (such as medication prescribe). The objective of the new trigger is for the user to request apps (and CDS) in a given context. Context can be a problem, a med, a lab result or other items in a patient's chart. The hook is analogous to the infobutton in which the user requests informational resources.
I have attached a slide deck presented in the wg call. If anyone is interested in participating in further developing the proposal or in a connectathon, please reply here.
app-launch-hooks.pptx
David Hay (Jul 19 2018 at 19:38):
I'm interested in this...
Kevin Olbrich (Jul 20 2018 at 13:16):
I am also interested in this.
Aziz Boxwala (Jul 22 2018 at 16:06):
I am also interested in this.
We will have additional discussion on this proposal during the August 1 CDS WG call (12 noon EDT). In the discussion last week, the main issues were around usability - where to show the "buttons" for the user to trigger the request, would it be undesirable to receive a response that there was no CDS or apps available.
Of those interested, who will be providing the CDS services + apps and who will be a client (e.g., EHR application)?
Kevin Olbrich (Jul 22 2018 at 17:17):
@Aziz Boxwala we're a service provider
Aziz Boxwala (Jul 22 2018 at 17:36):
@Aziz Boxwala we're a service provider
As are we.
Brett Esler (Jul 24 2018 at 22:41):
intend to have 'topics' (indication, patient information, treatment etc.) like info-button for this? would love a value set for topics + the appropriate context of use for them...
Aziz Boxwala (Jul 25 2018 at 00:26):
intend to have 'topics' (indication, patient information, treatment etc.) like info-button for this? would love a value set for topics + the appropriate context of use for them...
This will be useful. Need to consider how to fit this in a hooks request. Possibly in the context field.
Kevin Shekleton (Aug 01 2018 at 11:54):
It sounds like we're describing here individual, discrete hooks. A "topic" along with appropriate context for each...that's a discrete, unique hook.
Aziz Boxwala (Aug 01 2018 at 14:19):
A reminder that this topic is up for discussion at today's CDS WG call at 12 noon EDT or 4 pm UTC.
https://global.gotomeeting.com/join/383926805
Dial-in: 224-501-3312
Participant code: 383926805
Aziz Boxwala (Aug 01 2018 at 14:21):
It sounds like we're describing here individual, discrete hooks. A "topic" along with appropriate context for each...that's a discrete, unique hook.
Kevin, are you suggesting that the hook/button associated with a problem list might be different than a hook associated with a med list, say? I'll defer to you on how to best create the hook or hooks. If we create separate hook specs, they could be very similar to each other.
Kevin Shekleton (Aug 01 2018 at 14:33):
The whole notion of this uber-hook that is flexible based upon a multitude of situations just doesn't fit with how we describe hooks today -- a very specific action/event in the workflow with contextual specific data.
Kevin Olbrich (Aug 01 2018 at 14:35):
As much as I'd like to join this discussion today, I probably won't be able to make it.
Aziz Boxwala (Aug 01 2018 at 15:26):
The whole notion of this uber-hook that is flexible based upon a multitude of situations just doesn't fit with how we describe hooks today -- a very specific action/event in the workflow with contextual specific data.
Understood. Thanks @Kevin Shekleton
Aziz Boxwala (Aug 02 2018 at 05:12):
For those who were unable to join, the WG call today, here is a quick summary:
1. This will not be a connectathon topic in September.
2. We will explore infobutton as an alternative to cds-hooks to "discover" context-relevant apps. Key issues to address are (a) how the response will indicate that the content is a link to a SMART on FHIR app, and (b) given that the infobutton spec does not exchange PHI, how can the client launch a SMART app from that link. I will look into issue (a) with @Guilherme Del Fiol and client implementers (i.e., EHR vendors) will share their feedback here on issue (b).
Since cds-hooks is still a candidate for the solution, I suggest we continue the discussion in this stream for now.
Aziz Boxwala (Aug 14 2018 at 04:58):
I reviewed the infobutton spec to see what changes need to be made for infobuttons to return links to SMART on FHIR apps. It appears that only one change is needed, which I confirmed with @Guilherme Del Fiol .
The atom feed and atom entry have link elements in the response of an infobutton request. We need to set the type field to have a value indicating this is a link for a SMART on FHIR app. That value must be a mime-type. I don't believe there currently is a mime-type for SMART on FHIR. Therefore, that needs to be created.
"link": [
{
"title": "Cardiac Risk App",
"rel": "self",
"type": "application/smart-on-fhir",
"href": "https://cardiac.apps.example.com/index.html"
},
...
]
For those who have infobutton clients, is this an easier and preferred path to "app buttons", as compared to implementing new types of hooks?
If infobutton is the preferred approach, does it make sense to move this discussion to the SMART stream? There is no infobutton stream in zulip.
Isaac Vetter (Aug 14 2018 at 04:59):
Hey aziz! Would this also work an HTTP Get / non-atom infobutton implementation?
Aziz Boxwala (Aug 14 2018 at 05:03):
The SOA guide describes the request and response format. The URL-based implementation guide only describes the request format. I assumed the response format for both implementations has the same structure. That is, only the requests have different structures. I will tag @Guilherme Del Fiol for a more authoritative reply.
Isaac Vetter (Aug 14 2018 at 05:05):
Aziz, my understanding is that there's a number of systems that have only implemented the Url-based implementation, so this would be important. It makes sense that they would use the same syntax, though.
Aziz Boxwala (Aug 14 2018 at 05:06):
Agree. I believe most of the implementation in use are URL-based. GET requests still return a body in the response so no reason for the response to be different in structure between URL and SOA implementations.
Guilherme Del Fiol (Aug 14 2018 at 15:35):
That's my understanding too (most systems implemented only URL-based). The URL-based approach returns an HTML page that loads on the client browser. I am not sure SMART on FHIR apps could be launched form links in such a page. Probably not?
Aziz Boxwala (Aug 15 2018 at 18:47):
Back to the drawing board!
Last updated: Apr 12 2022 at 19:14 UTC
