FHIR Chat · SMART launch for a specific Resource instance · smart

Stream: smart

Topic: SMART launch for a specific Resource instance


view this post on Zulip Michael Lawley (Mar 15 2019 at 05:02):

SMART is currently very EHR-oriented. Has there been any work on its use in other contexts?
The particular issue I have is wanting to be able to launch an App with a specific resource instance as the context (there's no "current patient").
A secondary requirement would be a POST-based launch where I'm supplying the Resource as the POST body (although this is probably simpler - there's no need to agree on what the parameter name is)

view this post on Zulip Grahame Grieve (Mar 15 2019 at 05:04):

what's a POST based launch look like? I don't follow that

view this post on Zulip Grahame Grieve (Mar 15 2019 at 05:05):

but I do firmly endorse the need for any kind of resource as a launch context

view this post on Zulip Isaac Vetter (Mar 15 2019 at 05:08):

Hey Michael, even from the EHR-oriented SMART launches, the ability to add additional contextual information as "SMART launch parameters" alongside the access_token is common. Ultimately, as long as it can be expressed as simple values, the user's session context should be presented to the app during the launch in these key/values pairs as the response from the authorization server's /token endpoint.

view this post on Zulip Michael Lawley (Mar 15 2019 at 05:39):

Well, with a POST-based launch I might have a template / partially authored resource (or one obtained via some off-line mechanism) and I want to pass it to the App ; maybe its a Bundle of Meds for curation into a current-meds list, or maybe its a template ValueSet (with boilerplate publisher, copyright, etc) as a starter for authoring a new ValueSet.

view this post on Zulip Isaac Vetter (Mar 15 2019 at 05:46):

Hey Michael, I draw the line on contextual launch parameters at "simple" parameters. If the contextual information can be expressed as a single, discrete value, then it's appropriate to send in an app launch. Alternatively, if the information is represented in a complex/hierarchical form, it should be accessed via a web service and not as a launch parameter.

view this post on Zulip Isaac Vetter (Mar 15 2019 at 05:46):

Of course, the SMART launch itself enables further web service use by providing the app with the OAuth2 access_token.

view this post on Zulip Michael Lawley (Mar 15 2019 at 05:57):

The challenge I have is that the "complex" information (FHIR Resource) is not available via a web API; it's sitting in a web browser's internal state. The browser can do an XHR to the SMART App, but it can't field requests itself.

view this post on Zulip Jenni Syed (Mar 15 2019 at 13:23):

What is the use case/workflow this is trying to solve for?

view this post on Zulip Michael Lawley (Mar 17 2019 at 21:58):

I have two clients, one is a specialised tool that creates transient and minimal ValueSets (normally these are POSTed to $expand), the other is a more complete authoring tool (Snapper, which is a SMART on FHIR app). I want to be able to hand off the partially-authored ValueSet to Snapper for complete authoring.
Either I create it on a FHIR server then launch (GET request) Snapper with a reference to the newly created thing (not great, since the resource is bare-bones, won't have a URI, etc) or I pass it directly to Snapper (POST request).
Clearly I have control of both clients so can solve this in several ways, but I'd rather build on a std interaction pattern.

view this post on Zulip Michael Lawley (Mar 25 2019 at 01:13):

I think this also relates to the idea of template resources that has been discussed in relation to use-cases like prescribing - handing a template resource back to the EHR for completion. In my use-case, I'm wanting to hand off a resource template from one SMART App to another SMART App rather than back to the host EHR.

view this post on Zulip Isaac Vetter (Mar 27 2019 at 19:13):

Hey @Michael Lawley , upon consideration, I think that the best fit in FHIR for a "POST-based launch" is actually the Questionnaire/QuestionnaireResponse stuff. See the larger diagram on the Structured Data Capture's workflow section. This "SDC" integration is quite similar to both IHE's RFD profile and the many ad-hoc POST-based launch integrations in the wild.

view this post on Zulip Michael Lawley (Mar 30 2019 at 10:16):

Hi @Isaac Vetter , I've had a look at the sequence/flow diagram but it's not clear to me how it relates?


Last updated: Apr 12 2022 at 19:14 UTC