FHIR Chat · docs / PR #112 Add ability to pass CDS Service supplied p... · cds hooks/committers

Stream: cds hooks/committers

Topic: docs / PR #112 Add ability to pass CDS Service supplied p...

---

Github Notifications (Nov 21 2017 at 22:31):

kpshek edited PR #112
from issue59-passing-context to master

@kpshek , @isaacvetter , @brynrhodes - I have made changes based on the discussion in https://github.com/cds-hooks/docs/issues/59. Please let me your thoughts

Github Notifications (Nov 22 2017 at 12:28):

kpshek commented on PR #112

While at FHIR DevDays last week, I talked with a couple guys from @StayWell who asked me for the same functionality described in #59 (and what this PR is attempting to address). I just emailed them to ask them to provide their feedback on the various approaches we've been discussing for their input for an additional perspective.

Github Notifications (Nov 22 2017 at 12:32):

kpshek commented on PR #112

I think a new attribute on a link (specifically for links of type smart only) is the most straightforward approach to solve this particular need. It is more explicit as to the use case we are attempting to solve and works when a card has multiple SMART app links.

It is not clear to me where else an opaque string on the CDS card would be used (outside of being passed to the SMART app on launch).

Github Notifications (Nov 27 2017 at 17:28):

yashaskram commented on PR #112

@kpshek Appreciate your input. I am ok to have something at the link level for this use case

It isn't clear to me why we are adding this card-level attribute for a value that is only intended to be passed to a SMART app via a launch parameter. Can you elaborate on why the proposal to add a new attribute on the link wasn't ideal?

I think a new attribute on a link (specifically for links of type smart only) is the most straightforward approach to solve this particular need

which proposal are you referring? Can you point to this? If not, can you propose what you have is mind in issue [#59]

For example : are you thinking of leveraging query params in the url like

{
      "cardid": "345"
      "summary": "Card 1 - Clinical Pathway 1",
      "indicator": "info",
      "detail": "This is an example app card.",
      "links": [
        {
          "label": "SMART App",
          "url": "https://smart.example.com/launch?foo=a",
          "type": "smart"
        }
      ]
    }

vs having an additional attribute like below. If so were you thinking extension vs dedicated attribute name

{
      "cardid": "345"
      "summary": "Card 1 - Clinical Pathway 1",
      "indicator": "info",
      "detail": "This is an example app card.",
      "links": [
        {
          "label": "SMART App",
          "url": "https://smart.example.com/launch",
          "type": "smart",
          "foo": "a"
        }
      ]
    }

Github Notifications (Nov 27 2017 at 22:41):

yashaskram commented on PR #112

@kpshek - thx for reviewing my changes, as for your comment https://github.com/cds-hooks/docs/pull/112#pullrequestreview-78423057, I will wait to arrive at a consensus on this https://github.com/cds-hooks/docs/pull/112#issuecomment-347258271 and redo the PR

Github Notifications (Nov 28 2017 at 17:27):

kpshek commented on PR #112

@yashaskram - I was referring to something similar to the example noted under "A link in CDS card has params data" in #59. Here is a concrete proposal what I'm in favor of implementing here:

{
  "summary": "Example card",
  "indicator": "info",
  "source": {
    "label": "Example CDS Service"
  },
  "links": [
    {
      "label": "SMART App",
      "url": "https://smart.example.com/launch",
      "type": "smart",
      "cdsHooksContext": "Some opaque (to the EHR) string that will come back alongside your OAuth 2 access token on a SMART app launch"
    },
    {
      "label": "Another SMART App",
      "url": "https://smart2.example.com/launch",
      "type": "smart",
      "cdsHooksContext": "Another context value for this SMART app"
    },
    {
      "label": "An absolute link",
      "url": "http://cds-hooks.org",
      "type": "absolute"
    }
  ]
}

The cdsHooksContext field should only ever be valued if the link type is smart. cdsHooksContext is not valid for absolute links.

The cdsHooksContext field and value will be sent to the SMART app alongside the other launch context when the SMART app is launched. See "Launch context arrives with your access_token" in the SMART documentation. For instance, here is what would come back for the first SMART app in my example:

{
  "access_token": "secret-xyz",
  "patient": "123",
  "cdsHooksContext": "Some opaque (to the EHR) string that will come back alongside your OAuth 2 access token on a SMART app launch"
  // etc...
}
~~~

Github Notifications (Nov 28 2017 at 19:46):

yashaskram commented on PR #112

@kpshek - I like your proposal. looks like we are back to the start point
@isaacvetter , @brynrhodes - thoughts? based on your input I can make the changes to my PR

Github Notifications (Nov 28 2017 at 19:53):

isaacvetter commented on PR #112

Hey @yashaskram , guys,

Yeah - the above sample message from @kpshek makes sense - the cardInstance that I was pushing towards had the disadvantage of not accounted for multiple smart links in a single card. Not allowing this parameter to be specified in an absolute link makes sense because this param should be passed as a SMART launch parameter (alongside the access token). A similar parameter should simply be put into the url (perhaps in the querystring) of an absolute link.

The only part of the above proposal that I object to, is the name: cdsHooksContext. Ultimately, it's not descriptive of the purpose of the element. How about: appSession or serviceAppId` or ... something that actually describes the intent and purpose of the field.

Isaac

Github Notifications (Nov 28 2017 at 20:30):

yashaskram commented on PR #112

@isaacvetter & team - how about the name - appcontext?

Github Notifications (Nov 28 2017 at 21:04):

kpshek commented on PR #112

I struggled coming up with a descriptive name for this field as well. I originally named it appContext but changed it when I saw it alongside the other context variables in a SMART app launch. With that being said, I'm fine if we name this appContext (note the camelCase in keeping with our existing field naming conventions).

Github Notifications (Nov 28 2017 at 21:55):

yashaskram synchronized PR #112

Github Notifications (Nov 28 2017 at 22:07):

yashaskram synchronized PR #112

Github Notifications (Nov 28 2017 at 22:25):

yashaskram synchronized PR #112

Github Notifications (Nov 29 2017 at 00:37):

kpshek commented on PR #112

@travistcummings - can the HSPC Sandbox support passing arbitrary launch context to the SMART app per these proposed changes?

Tagging @zplata for the eventual cds-hooks/sandbox change that this will also require.

Github Notifications (Nov 29 2017 at 15:16):

yashaskram synchronized PR #112

Github Notifications (Nov 29 2017 at 17:39):

kpshek closed PR #112

Github Notifications (Dec 01 2017 at 18:28):

travistcummings commented on PR #112

@kpshek The HSPC Sandbox launch will support additional parameters in the SOF launch url: https://example.com/launch.html?p1=abc&p2=xyz

When the CDS Hooks sandbox registers a launch context, it can also provide a params map object that will be passed to the client along side their access token:

launch context:
{
...
"parameters":{
"patient":"BILIBABY",
"appContext": {
"p1": "abc",
"p2": "xyz"
},
"need_patient_banner":false
}
}

SOF launch response:
{
"access_token": "eyJhbGc...",
"token_type": "Bearer",
"expires_in": 86399,
"scope": "patient/Observation.read launch patient/Patient.read patient/Observation.write",
"patient": "BILIBABY",
"need_patient_banner": false,
"appContext": {
"p1": "abc",
"p2": "xyz"
}
}

Github Notifications (Dec 01 2017 at 19:28):

kpshek commented on PR #112

That's great, thanks @travistcummings!

Github Notifications (Jan 03 2018 at 16:16):

mtcollie commented on PR #112

Hi @kpshek , apologies for the delay, but this parameter would be just what we need to provide contextual links to particular content or a program. For example, if a physician prescribed a sleep aid medication, we could prompt with a notification that the patient was eligible to be enrolled in the sleep health program and the link to could take them directly to the enrollment section.

---

Last updated: Apr 12 2022 at 19:14 UTC