Stream: cds hooks
Topic: FHIR Sandbox Integrations
Travis Cummings (Sep 06 2017 at 15:40):
Hi @Kevin Shekleton @Zach Plata @Amy Ballard @Rick Freeman
Is the CDS-Hooks Sandbox as a SMART App deployed to an environment where we can try launching it?
Travis Cummings (Sep 06 2017 at 15:42):
Also, would you like the CDS-Hooks Sandbox to use a static client-id, or would you like the HSPC Sandbox to create a registration and provide you with a client-id for our system?
Kevin Shekleton (Sep 06 2017 at 16:07):
@Travis Cummings - Here's the PR in review: https://github.com/cerner/cds-hooks-sandbox/pull/24
Amy Ballard (Sep 07 2017 at 14:23):
@Zach Plata I'm launching CDS-Hooks against your Heroku deployment. It launches using the SMART of FHIR auth flow. After it gets the token, I see, in Developer Tools, that it queries the SMART open endpoint, https://sb-fhir-dstu2.smarthealthit.org/api/smartdstu2/open/Patient/SMART-1288992, and then it queries the patient I launched with and my FHIR server http://localhost:8071/dstu2/data/Patient/SMART-665677. Is this expected behavior?
Zach Plata (Sep 09 2017 at 04:56):
@Amy Ballard Yes, the Sandbox executes queries to a default patient and calls the services (these have been executed via commands that were triggered globally on a few JS files, so they execute on page load). You can ignore the first calls for now to 1288992. Soon we will work on re-factoring the Sandbox in it's entirety and the issue should be resolved.
Travis Cummings (Sep 09 2017 at 14:53):
@Kevin Shekleton @Zach Plata I'm here at the FHIR connectathon. Is this something we can work on today?
Zach Plata (Sep 09 2017 at 15:51):
Here's the client ID for the Sandbox: 48163c5e-88b5-4cb3-92d3-23b800caa927
Travis Cummings (Sep 20 2017 at 18:29):
@Zach Plata Would you like to keep using the client ID above, or move to a well-known id like "cds-hooks-sandbox"?
Zach Plata (Sep 27 2017 at 14:35):
@Travis Cummings Sorry for the delay! I think the well-known ID you mentioned would be good. We'll have to make this change in the launch endpoint, and can coordinate changing it in the default HSPC app about the same time. Is this default app already available to everyone?
Travis Cummings (Sep 28 2017 at 17:08):
@Zach Plata Yes the default app is already available. We can change the client_id associated with it when you are ready with the sandbox integration.
Zach Plata (Sep 29 2017 at 13:29):
Great, thanks @Travis Cummings ! We'll let you know when the PR is out to change that client_id and we can coordinate the switch.
Travis Cummings (Oct 04 2017 at 02:31):
@Zach Plata I've been seeing inconsistent launches of the CDS Hooks Sandbox from the HSPC sandbox. It seems to sometimes load the proper patient (ex: Baby Bili) then very quickly flashes over to Daniel Adams.
Travis Cummings (Oct 04 2017 at 02:33):
Travis Cummings (Oct 04 2017 at 02:33):
Other timers it shows Daniel Adams then quickly flashes to the launched patient, Baby Bili.
Zach Plata (Oct 04 2017 at 14:08):
@Travis Cummings Thanks for bringing this up. I'll take a look today
Travis Cummings (Oct 10 2017 at 19:24):
@Zach Plata Have you detected any issue with the patient that is displayed when the CDS Hooks sandbox is launched from the HSPC Sandbox?
Travis Cummings (Oct 10 2017 at 20:36):
@Zach Plata Can you let me know, when the CDS Hooks sandbox is launched from the HSPC sandbox, does the CDS Hooks sandbox send the access token to the subsequent CDS Hooks services? Do they all share the same token or how do the services get access to the HSPC sandbox instance?
Zach Plata (Oct 10 2017 at 20:59):
@Travis Cummings I haven't noticed any issues launching the CDS Hooks Sandbox from the HSPC Sandbox on my end. What are you seeing? The inconsistent launch of that Baby Bili issue?
And yes, the CDS Hooks Sandbox sends the access token to services via the fhirAuthorization parameter in the request. All services hooked up will receive the same token (the token the CDS Hooks Sandbox receives, and just passes along, for now).
Travis Cummings (Oct 10 2017 at 21:09):
@Zach Plata I haven't seen the inconsistent patient display today in 5 or 6 launches. If it happens again, I'll try to use the "change patient" menu and see if I can get bilibaby to show properly.
Travis Cummings (Oct 10 2017 at 22:26):
@Zach Plata Do you think the CDS Hooks-HSPC Sandbox integration is something we can demo at the next Argonaut CDS Hooks Team Meeting? If so, need to do a little work on the HSPC side to make sure the bilirubin cds service and bilirubin app are working together.
Zach Plata (Oct 18 2017 at 21:09):
@Travis Cummings I'm not on the email chain that gets sent the meeting invites, but you are more than welcome to demo that at the next Argonaut meeting. Please let me know if you encounter any patient/service patient name mismatch leading up to it.
Travis Cummings (Oct 19 2017 at 00:13):
@Zach Plata @Kevin Shekleton @Matt Henkes It seems like the next easiest integration would be for the HSPC sandbox to pass a custom launch parameter that contains context info for the CDS-Hooks sandbox. I think the first context item would be the a CDS-Hooks service discovery endpoint the CDS-Hooks sandbox can add to the "Select a Service:" box. This could either be in the form of an action/command or a declaration, singular or plural:
"add_cds_service_discovery_endpoint": "https://example.com/cds-services"
"cds_service_discovery_endpoint": "https://example.com/cds-services"
"cds_service_discovery_endpoints": [{"https://example.com/cds-services"}]
Or, what would you like to see?
Zach Plata (Oct 23 2017 at 17:19):
@Travis Cummings Is there any update on the HSPC end for implementing the API for SMART app launches registered from an HSPC sandbox for the CDS Hooks Sandbox? Curious on your thoughts for that specific proposal, as I'm hoping to figure out what this might look like for working on next.
Travis Cummings (Nov 02 2017 at 06:29):
@Zach Plata Here is a rough draft on how I think the app launch could work. Basically the CDS-hook service would return an app link card that contained the URL of the target app. The CDS-Hooks sandbox would receive that link card and show a button. When the user clicked the button, the cds-hooks sandbox would send a smart launch request (not a formal smart-on-fhir launch) to the HSPC Sandbox's smart launch invocation endpoint (a new endpoint) with the fhir_url, the open_id token, and the launch url of the app. The HSPC sandbox would then figure out if a registered app matched the launch url, and perform a persona-launch (launching for a persona user).
Travis Cummings (Nov 02 2017 at 06:29):
Zach Plata (Nov 02 2017 at 15:59):
@Travis Cummings Thanks for that flow chart! To clarify, when the Sandbox calls the new HSPC launch endpoint, will the Sandbox get the launch code back, so it can trigger the app launch itself? It looks like HSPC is doing the coordination of the app launch on that bottom half of the picture. Also, is there an estimated time on when this new endpoint from HSPC would be available?
Travis Cummings (Nov 02 2017 at 22:34):
I had thought that the CDS Hooks sandbox would ask the HSPC sandbox to launch the app. Are you proposing the CDS Hooks sandbox registers a launch context with the HSPC sandbox (receiving back a launch code), then just opens the app by passing along the launch code?
Travis Cummings (Nov 02 2017 at 23:02):
If the cds hooks sandbox wants to create the launch context and perform the smart launch, then the cds hooks sandbox would be acting basically like the HSPC's "Sandbox Manager" tool.
In this case, the process is:
1) the Sandbox Manager creates a launch context (app to launch, params, issuer, launch details, etc)
2) the Sandbox Manager creates a launch code ("key")
3) the Sandbox Manager registers the launch context with the issuer (fhir server) at the endpoint iss + '/_services/smart/Launch' using a POST
4) the Sandbox Manager receives the context back from the registration call and adds it to the windows local storage indexed by the launch code ("key") so the opening window (for the app) can find it (opened with a param ?key=...}
Travis Cummings (Nov 02 2017 at 23:04):
You can see this all in action here:
In the "factory('launchApp'..." starting at 1925.
Travis Cummings (Nov 02 2017 at 23:05):
Note the call to registerContext(). registerContext is defined on line 621 and looks like this:
registerContext: function (app, params, issuer) {
var deferred = $.Deferred();
var reqLaunch = fhirClient.authenticated({
url: issuer + '/_services/smart/Launch',
type: 'POST',
contentType: "application/json",
data: JSON.stringify({
client_id: app.authClient.clientId,
parameters: params
})
});
$.ajax(reqLaunch)
.done(deferred.resolve)
.fail(deferred.reject);
return deferred;
}
Zach Plata (Nov 02 2017 at 23:13):
@Travis Cummings Ah, I should've looked more closely at the first message, that this would not be a formal smart-on-fhir launch. I originally thought the new API would return the opaque launch context for the launch parameter, and the sandbox would append the FHIR server on the iss parameter to launch the app, from the control of the Sandbox.
Travis Cummings (Nov 02 2017 at 23:19):
I assume the cds hooks sandbox needs to be able to smart-launch apps when not being launched from the hspc sandbox?
Zach Plata (Nov 02 2017 at 23:28):
Right, and as of right now, if the cds hooks sandbox is launched securely, like through HSPC sandbox, I'm not aware if the secure SMART app launch has been nailed down yet, beyond this case.
Travis Cummings (Nov 02 2017 at 23:49):
To launch an app, the HSPC Sandbox Manager creates a launch context and key (launch code), and then posts it to the iss. The iss then posts it to the auth server. The Sandbox Manager then gets back the launch context and opens the app. It looks like this:
Travis Cummings (Nov 02 2017 at 23:50):
Travis Cummings (Nov 02 2017 at 23:54):
I think the cds-hooks sandbox has two options.
1) act like the HSPC Sandbox Manager and create and register the launch context, then open the app
2) delegate launching the app to the HSPC Sandbox Manager (just tell the HSPC Sandbox Manager to launch the app)
Travis Cummings (Nov 03 2017 at 00:02):
For #2, we would probably pass into the CDS Hooks sandbox a extra launch parameter like "smart_launch_delegate=http://...". Then when a smart app link is clicked, the CDS Hooks sandbox would post to the delegate everything it knew (the app link, the iss, the access token, the user token).
Travis Cummings (Nov 03 2017 at 00:04):
Is there a different option you are think of? The first option is available right now, the second option would take some work on our side to build the delegate launch stuff. I could help you with the first option by a pull request if that helped out.
Zach Plata (Nov 03 2017 at 00:09):
Ah, that smart_launch_delegate part was what I was looking for. So when the CDS Hooks Sandbox is launched from HSPC, along with the access token and such, it should retrieve this smart_launch_delegate url, to which the CDS Hooks Sandbox would post to with relevant data.
Zach Plata (Nov 03 2017 at 00:11):
I think #2 would be a good option, whenever that is ready. @Kevin Shekleton thoughts on this?
Josh Mandel (Nov 04 2017 at 18:44):
I think the key requirements are:
1. Ensure that the CDS Hooks Sandbox can launch apps (via "App Link") in a way that looks, to the app, exactly like a norma SMART Launch.
2. Ensure that the CDS Hooks Sandbox connects to an underlying clinical data sandbox (like the HSPC or SMART sandbox) through a well-specified protocol, so that anyone can implement another clinical data sandbox and it stays compatible.
Josh Mandel (Nov 04 2017 at 18:44):
I think a non-goal is: making the CDS Hooks sandbox work in front of production EHRs to protect real data.
Josh Mandel (Nov 04 2017 at 18:46):
Given these requirements: my preferred solution is to continue defining a "sandbox launch API" like Travis suggests in #1, and making sure the inputs/outputs are clearly specified. (We did this back when we created the initial SMART auth server; I think that work may have persisted to this day, but it'd be good to double-check. @Travis Cummings is the protocol in your diagram documented?)
Josh Mandel (Nov 04 2017 at 18:49):
(I prefer #1 because:
- it leverages an existing protocol and
- it gives components like the CDS Hooks sandbox more control -- e.g. you can generate a few launch ids in parallel to anticipate different user choices and speed up the process.
- it's very easy for a client to simulate the behavior of #2 if it has access to the API for #1 — but the other direction is not possible.
)
Travis Cummings (Nov 06 2017 at 20:46):
@Josh Mandel : @Zach Plata and I met on Friday and talked through some options. We thought first that the system launching the CDS Hooks sandbox should pass in a "launch registration endpoint" as a launch parameter. Otherwise the CDS Hooks sandbox would either have to use the issuer or the launch requestor address.
Travis Cummings (Nov 06 2017 at 20:56):
I'm having some doubts. I'm thinking the endpoint should actually be in the iss server now. This is for a couple reasons, but mostly because the CDS Hooks sandbox already has an access token to that server. In that case, there is no "launch registration endpoint" value passed to the CDS Hooks sandbox because it is a well-known endpoint on the iss. For example, smart/launch-registration or something like that.
Travis Cummings (Nov 06 2017 at 21:48):
(deleted)
Travis Cummings (Nov 06 2017 at 21:49):
Travis Cummings (Nov 06 2017 at 22:44):
@Josh Mandel @Zach Plata Here is a confluence page we can collaborate on:
Travis Cummings (Nov 06 2017 at 22:44):
https://healthservices.atlassian.net/wiki/spaces/HSPC/pages/119734296/Registering+a+Launch+Context
Travis Cummings (Jan 24 2018 at 19:52):
We are exited to announce that SMART app links in your cards now can be launched from the CDS Hooks sandbox to your HSPC Sandbox instance (as the issuer)! Thanks @Zach Plata for making this happen!
Last updated: Apr 12 2022 at 19:14 UTC
