Stream: smart
Topic: Launch Sequence
B Stibbe (Feb 05 2021 at 14:43):
An EHR initiates a “launch sequence” by opening an instance pointing to the app’s registered launch URL and passing some context.
The parameters iss and launch are included. For the launch we need an opaque identifier, and any EHR context associated with it. This parameter must be communicated back to the EHR at authorization time by passing along a launch parameter (see example below).
So is the following “launch sequence” allowed: GET https://app/launch?iss=https://ehr/fhir&launch=xyz123&patient=abc&task=123 according SMART?
I'm passing extra info about patient=abc and task=123 EHR context
Josh Mandel (Feb 05 2021 at 14:47):
This is not correct. Contextual data (and especially sensitive data like a patient ID) should not be passed to SMART apps via URL parameters. Instead, give the app an opaque launch parameter, and then at the end of the authorization process return the data you need as part of the access token response.
Josh Mandel (Feb 05 2021 at 14:48):
Specifically for patient: this is a defined launch context parameter that we document for inclusion in the access token response. You can follow this pattern with task if you have a use case for task-passing.
B Stibbe (Feb 05 2021 at 15:38):
How does the *authorization process * get the EHR context from the host?
Josh Mandel (Feb 05 2021 at 15:40):
That's an internal choice; you get one parameter (launch) to use to make the connection. One example would be: EHR writes context to a database, keyed by a random launch value; and authz server can read from that db.
B Stibbe (Feb 05 2021 at 15:42):
Ok. So the EHR and the authz server shares the EHR context and the authz server passes this info via the token response.....
Josh Mandel (Feb 05 2021 at 16:19):
Yes, you've got it.
B Stibbe (Feb 05 2021 at 16:33):
It looks like if you post an launch artifact (like SAML). But you should get this artifact (first) from the authz server. The launched application delivers the launched artifact to the authz server and response with the access_token and other context.
Nice, but this is not a current SMART standard.........
Josh Mandel (Feb 05 2021 at 16:36):
I'm not following. The SMART App Launch standard provides a way to communicate (arbitrary) launch context to an app, ensuring it only becomes available once authorization is complete.
B Stibbe (Feb 05 2021 at 16:39):
I get that part. But the first part, to use the launch parameter as an artificat or key to get launch content from the authz server.
B Stibbe (Feb 05 2021 at 16:41):
Or the communication between the host and the authz server about the launch parameter.
Bernard Stibbe (Jun 09 2021 at 13:57):
Josh Mandel said:
That's an internal choice; you get one parameter (
launch) to use to make the connection. One example would be: EHR writes context to a database, keyed by a randomlaunchvalue; and authz server can read from that db.
@Josh Mandel how do you passes the launch context endpoint or the db entry to the authz server. This must be done befor we start the launch? Do we have an launch context endpoint extension for the CapabilityStatement?
Josh Mandel (Jun 09 2021 at 14:03):
There is no such thing as a "launch context endpoint". Apps supporting the EHR launch sequence have a launch endpoint;
Josh Mandel (Jun 09 2021 at 14:04):
When launching such an app, the EHR redirects to that endpoint and includes a URL parameter called launch.
Bernard Stibbe (Jun 09 2021 at 15:35):
Ok. Launch context endpoint is the wrong definition for getting the launch context. But how does the authz server get the endpoint (or entry) of the launch context?
Michele Mottini (Jun 09 2021 at 15:52):
Non-programmatically. Someone maintain the list of apps the EHR 'knows' with the corresponding launch end point for each
Josh Mandel (Jun 09 2021 at 16:00):
And note this is the same as for "how does any app register with the EHR".
Bernard Stibbe (Jun 10 2021 at 09:08):
Hello, I understand the registered launch endpoint.
So
1) I prepare a "launch context" (e.g prepare a FHIR Task for an application) and a launch handle, before I launch the application
2) I launch the application, passes the lauch parameter (or handle) to that application together with the iss parameter.
3) The started application passes the launch handle to the authorization server, in or with the scope of the auth request
4) somehow the authorization server needs to know where the location is (or endpoint) of this launch context. How does the authorization server knows where to find this luanch context?
Has somebody some example how this work with OAuth2/OpenID Connect?
Michele Mottini (Jun 10 2021 at 12:16):
How does the authorization server knows where to find this luanch context
Up to the implementation. For example: the EHR saves the launch context data in a database, the launch context is the database id of this data, the authorization server retrieves the data from that database (or instead of 'database' it can be a shared service etc)
Josh Mandel (Jun 10 2021 at 17:07):
Functionally speaking, the important thing is that the launch context needs to be tamper-proof. In other words, an outside party should not be able to tweak/change the launch parameter to manipulate the context. The EHR can prevent this by creating a one-time-use database id, or a signed assertion, etc.
Bernard Stibbe (Jun 11 2021 at 07:37):
@Michele Mottini Thanks for the explanation, but ...
Here comes my question: How does the authorization server know the location or url or ... of that database or shared service?
Michele Mottini (Jun 11 2021 at 12:36):
In the usual ways a piece of software 'knows' anything: hard-wired in its code, read from a configuration file, fetched from _another_ service etc.
Michele Mottini (Jun 11 2021 at 12:37):
The upshot is that the 'EHR' that launches the app, the authorization server that controls access and the FHIR server that provides the data have to be tightly coupled - they are not really separate systems, they are just different pieces of the same system really
Last updated: Apr 12 2022 at 19:14 UTC
