Stream: cds hooks
Topic: Appbutton - App discovery by extending infobutton
Aziz Boxwala (Sep 12 2018 at 23:24):
app-launch-hooks-proposal.pptx
A few weeks I had initiated a conversation about using cds hooks to allow discovery of apps around data contexts (e.g., problem in the problem list). Based on feedback from the group, we look at infobuttons as an alternative approach. I am attaching slides from today's CDS WG call where we discussed an approach to extending the infobutton spec. The first part of the deck is the proposed approach. The latter slides capture the motivation and earlier discussions on alternative solutions.
We're looking for feedback from the group on the infobutton approach. Since there weren't any representatives of infobutton clients, i.e., EHRs, we'd like to call them out, in particular, to share their feedback.
Isaac Vetter (Sep 13 2018 at 03:18):
Hey Aziz,
1) I'm still not certain that the problem you're addressing is widely applicable.
2) Your current direction seems to make sense.
When the the infobutton response is a webpage, including a hypertext anchor, such as:
<a class="hl7.org:fhir-app" data-fhir-app-redirect="https://smartapp.com/diabetes/redirect.html" href= =“https://smartapp.com/diabetes/launch.html”>Diabetes app</a>
Are you expecting the Infobutton client to transform the hypertext reference into an EHR Launch url (i.e. add the iss and launch token GET parameters)? I'm not sure how a web-based EHR would be able to do that.
Isaac
Aziz Boxwala (Sep 13 2018 at 21:31):
Hi @Isaac Vetter
Yes, we are expecting the infobutton client to transform the anchor tag into an EHR launch URL. A client could use Javascript to perform the transformation. Is your concern that the client would not know how to set these parameters for an unknown (i.e., unregistered in EHR) app?
I have two projects that have a need for such a solution. I can't be sure how widespread the need might be, but this seems like a small modification (in the grand scheme of all things HIT) and could have a positive impact on the use of apps.
Thanks Isaac.
--Aziz
Isaac Vetter (Sep 14 2018 at 02:38):
Yes, we are expecting the infobutton client to transform the anchor tag into an EHR launch URL. A client could use Javascript to perform the transformation.
Hey Aziz,
My primary concern is that a web-based infobutton client wouldn't have the technical ability to reach into an iframe and transform the url of a hypertext reference. Maybe I'm wrong. Prototyping will definitely expose this problem, if it exists.
Isaac
Brian Postlethwaite (Sep 15 2018 at 22:48):
Specifically cross site scripting would trigger and some browsers would deny it and view it as a security violation.
We wouldn't do it for sure.
Aziz Boxwala (Sep 17 2018 at 05:46):
@Isaac Vetter : Iframe for what? The infobutton client is the one that contains the hyperlink.
Isaac Vetter (Sep 19 2018 at 05:16):
Hey Aziz - maybe I'm missing the big picture, please let me know if you think so.
My understanding is that the infobutton response is parsed/displayed in a browser based client. In the case where that client is fully web based, the primary method for displaying the infobutton response is within an iframe of a larger web application. In this case, the larger web application will not have the ability to modify a hyper text reference to a SMART app, as returned from the Infobutton service, to append the launch/iss parameters.
Again, prototype testing will definitely expose this, if it's a problem.
Isaac
Aziz Boxwala (Sep 19 2018 at 17:42):
Hi Isaac. That's right. I imagine the client could insert their own javascript in the html received from the infobutton within the iframe (just like they might apply their own css). Would that pose a security risk?
Do we still think infobutton is the approach we want to pursue? The alternative is to create a hook for "problem-list-review" ... and others in the future?
Isaac Vetter (Sep 25 2018 at 03:43):
Hey Aziz,
the client could insert their own javascript in the html received from the infobutton within the iframe
I'm pretty sure that this is specifically not allowed in most browsers, when the domain of the page hosting the iframe is different from the domain of the page contained within the iframe.
I personally think that adding additional hooks to CDS Hooks would be a far more desirable approach.
1. Adding more hooks would enhance CDS Hooks.
2. In some cases, _CDS clients_ already have non-standardized hooks available.
3. InfoButton's awesome as a clinical knowledgebase integration method, CDS Hooks is a bit more generic, enabling the cds service to query FHIR dynamically. I think that you want this capability.
Isaac
Aziz Boxwala (Sep 27 2018 at 00:06):
Isaac,
cds-hooks is the approach I too prefer.
When we initially proposed the project we considered both infobutton and cds-hooks requirements. The concern about infobutton operating in a non-PHI was identified then. There were a different set of concerns around hooks - mostly usability if the user clicks resulted in no responses. I believe that is less of a concern since there will be some apps that will cover a wide range of problems.
We can further develop a proposal for a hook around the problem review for WG discussion in October.
--Aziz
Hey Aziz,
the client could insert their own javascript in the html received from the infobutton within the iframe
I'm pretty sure that this is specifically not allowed in most browsers, when the domain of the page hosting the iframe is different from the domain of the page contained within the iframe.
I personally think that adding additional hooks to CDS Hooks would be a far more desirable approach.
1. Adding more hooks would enhance CDS Hooks.
2. In some cases, _CDS clients_ already have non-standardized hooks available.
3. InfoButton's awesome as a clinical knowledgebase integration method, CDS Hooks is a bit more generic, enabling the cds service to query FHIR dynamically. I think that you want this capability.Isaac
Last updated: Apr 12 2022 at 19:14 UTC
