FHIR Chat · docs / Issue #59 Passing parameters between CDS Hook and ... · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #59 Passing parameters between CDS Hook and ...

---

Github Notifications (Jul 19 2017 at 18:53):

yashaskram opened Issue #59

Passing parameters between CDS Hook and SoF app launch (when hook provider and app provider are same and would like to use the state/context

Couple of use cases
1) Taking users to a particular point in the SoF app based on the CDS Hook interaction. Sharing app context
2) Pre populating information based on the hook interaction. Sharing hook id (Example Imaging appropriate use case – populating or linking back to the CDS receipt information generated in the hook interaction)

Couple of straw men (Thx to @kpshek and @Isaac Vetter ) to start with.

A link in CDS card has params data

{
"summary": "Example Card",
"indicator": "info",
"detail": "This is an example card.",
"source": {
"label": "Static CDS Service Example",
"url": "https://example.com"
},
"links": [
{
"label": "Google",
"url": "https://google.com",
"type": "smart"
"params": "foo=a&bar=c"
},
}

SMART launch URL param
EHR appends the params value to the SMART app launch URL. This is a change we’d want to put into SMART (to call out launch params by the SMART app) and take advantage of here in CDS Hooks.
http://<app launch url>&foo=a&bar=c&iss=xx&launch=xx

OAuth claim alongside access token during SMART launch
Similar to above, but the EHR passes the custom value in the CDS card SMART link alongside the access token during a SMART launch. In this case the value doesn’t have to be URL encoded

{
"need_patient_banner":true,
"patient":"123",
"encounter":"456",
"token_type":"Bearer",
"access_token":"....",
"id_token":"...",
"scope":"patient\/Patient.read patient\/Observation.read launch online_access openid profile",
"expires_in":570,
"params":"foo=a&bar=c"
}

Other ideas / thoughts?

Github Notifications (Jul 19 2017 at 19:51):

isaacvetter commented on Issue #59

Hey @yashaskram,

I think that the CDS Hooks community has an ideal that a cds service can/will recommend SMART apps that are external to it. As we get closer to production implementations, it'll be interesting to see if that's actually a common use-case. I think that it makes sense to enable tighter integration when the service and app are the same system -- as long as we continue to enable the case where they're not.

Because the SMART app launch url is typically pre-registered in an EHR's SMART app directory, the launch url itself can't be dynamic.

Overall, I think that both of the above _params_ approaches are overcomplicated. Echoing service-provided strings feels risky from a security point of view. A parameter of parameters feels inelegant.

Why not just put the hook id alongside the access_token as a SMART launch parameter? This feels both cleaner and simpler. We could try to get the launch param standardizes in SMART as "session_id" or something like that. It'd then be the responsibility of the server/app server to maintain state, which it's doing already.

Github Notifications (Jul 20 2017 at 15:04):

robs16 commented on Issue #59

If you are going through the trouble of putting these parameters in a separate field within the link definition - perhaps they should be headers and defined as a map?

I tend to agree with @Isaac Vetter that a defined launch parameter would probably be better. However, rather than treating the hook instance as a security token, I would like to see a JWT instead (it could include the hook instance).

Github Notifications (Aug 02 2017 at 21:30):

yashaskram commented on Issue #59

hook id as SMART launch would parameter work for the particular use case above. Only concern I have is that it is not extensible for other use cases where app would like to share context with EHR upfront (in the use cases where local rules engine within EHR is leveraged to launch SMART app which I think is outside of the scope of this group)

hook_id (or session_id) as launch param works for us -> Can we agree upon this approach to be v 1.0 milestone?

Github Notifications (Oct 20 2017 at 10:42):

brettmarquard labeled Issue #59

Github Notifications (Oct 23 2017 at 21:09):

kpshek milestoned Issue #59

Github Notifications (Oct 23 2017 at 21:09):

kpshek assigned Issue #59

Github Notifications (Nov 01 2017 at 18:14):

isaacvetter assigned Issue #59

Github Notifications (Nov 01 2017 at 18:15):

isaacvetter commented on Issue #59

@yashaskram and I just talked this through.

I really do think that the hookInstance from the CDS request passed as a SMART launch parameter is the cleanest, simplest and least invasive method for enabling a session from the CDS Request to the launched SMART app, in the case where the service and the app are the same.

Github Notifications (Nov 01 2017 at 20:56):

yashaskram commented on Issue #59

@Isaac Vetter - I am thinking more about how above would work for our use case. Let me detail our use case a bit more. We have hundreds of clinical pathways and our pathway CDS Hook service can respond back with multiple cards applicable for the patient in context. For example: lets say the CDS Hook service responds back two cards as below

{
"cards": [
{
"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"
}
]
},
{
"summary": "Card 2 - Clinical Pathway 2",
"indicator": "info",
"detail": "This is an example app card.",
"links": [
{
"label": "SMART App",
"url": "https://smart.example.com/launch",
"type": "smart"
}
]
}
]
}

The need is when user opens the smart link in the app card, it launches a particular clinical pathway. One option is to register each pathway as its own SMART of FHIR app which is something we like to avoid so planning to accomplish above with out having to register each pathway as individual SMART on FHIR app.

Going back to your input to use hookInstance as SMART launch param to solve this problem will work only if we assume there is one card response for a particular hook request.

The option which we were thinking before https://github.com/cds-hooks/docs/issues/59#issuecomment-316497416 is to have a dedicated element in base spec (as opposed to using extension or hookInstance). What do you think about going ahead with that approach say having a field - cardid (or hookid) added to cards spec as in the example below

{
"cards": [
{
"cardid": "123"
"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"
}
]
},
{
"cardid": "345"
"summary": "Card 2 - Clinical Pathway 2",
"indicator": "info",
"detail": "This is an example app card.",
"links": [
{
"label": "SMART App",
"url": "https://smart.example.com/launch",
"type": "smart"
}
]
}
]
}

Below might be outside CDS Hook scope, but the hope is CDS Hook requester (EHR) can send this information back alongside access token during SMART launch similar to below

{
"need_patient_banner":true,
"patient":"123",
"encounter":"456",
"token_type":"Bearer",
"access_token":"....",
"id_token":"...",
"scope":"patient/Patient.read patient/Observation.read launch online_access openid profile",
"expires_in":570,
"cardid: "123"
}

Personally I am kind off inclined to using extension https://github.com/cds-hooks/docs/issues/76 at the links level for this issue but I also prefer above approach. And also with the latter, it doesn't stop implementer's to go with extensions if needed

Github Notifications (Nov 02 2017 at 12:48):

isaacvetter commented on Issue #59

Hey @yashaskram ,

Thanks for explaining the above. The feature you're describing isn't about strictly maintaining a session between the CDS request and the SMART app, as I had thought (and which would be generically useful anytime the CDS service and the SMART app are the same system), rather, it's needed to distinguish between your hundreds of "apps" (or workflows), all of which have the same launch url registered in the EHR.

Do you think that this will be a common need? While I do understand your use-case, it doesn't seem common -- I expect that most SMART apps are registered as different apps or display the same content upon launch. What are other scenarios where a card specific id (I'd go with the term "cardInstance" for consistency) would be useful?

Isaac

Github Notifications (Nov 02 2017 at 18:41):

grahamegrieve commented on Issue #59

Generically, it seems like a good robust idea for a cds-hooks service to be able to pass some information from the card to the app it is launching

Github Notifications (Nov 06 2017 at 16:42):

yashaskram commented on Issue #59

@Isaac Vetter scenarios where specific card id is useful in when CDS service provider has multiple points with in their app and want to take the users to a particular point in their app based on the rules/logic executed during the CDS Hooks request processing

I thought about cardInstance to be in sync with hookInstance but in our current implementation the card identifier (which we would like to share with EHR and get back during SMART launch) is not unique but we can make it unique. We can go with cardInstance

Github Notifications (Nov 22 2017 at 10:44):

kpshek edited Issue #59(assigned to kpshek)

Passing parameters between CDS Hook and SoF app launch (when hook provider and app provider are same and would like to use the state/context

Couple of use cases
1) Taking users to a particular point in the SoF app based on the CDS Hook interaction. Sharing app context
2) Pre populating information based on the hook interaction. Sharing hook id (Example Imaging appropriate use case – populating or linking back to the CDS receipt information generated in the hook interaction)

Couple of straw men (Thx to @kpshek and @isaacvetter ) to start with.

A link in CDS card has params data

{
  "summary": "Example Card",
  "indicator": "info",
  "detail": "This is an example card.",
  "source": {
    "label": "Static CDS Service Example",
    "url": "https://example.com"
  },
  "links": [
    {
      "label": "Google",
      "url": "https://google.com",
      "type": "smart",
      "params": "foo=a&bar=c"
    }
  ]
}

SMART launch URL param
EHR appends the params value to the SMART app launch URL. This is a change we’d want to put into SMART (to call out launch params by the SMART app) and take advantage of here in CDS Hooks.
http://<app launch url>&foo=a&bar=c&iss=xx&launch=xx

OAuth claim alongside access token during SMART launch
Similar to above, but the EHR passes the custom value in the CDS card SMART link alongside the access token during a SMART launch. In this case the value doesn’t have to be URL encoded

{
  "need_patient_banner":true,
  "patient":"123",
  "encounter":"456",
  "token_type":"Bearer",
  "access_token":"....",
  "id_token":"...",
  "scope":"patient\/Patient.read patient\/Observation.read launch online_access openid profile",
  "expires_in":570,
  "params":"foo=a&bar=c"
}

Other ideas / thoughts?

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

jmandel commented on Issue #59

Only quick note I'll make is that:

1. If we ever expect passed parameters to include sensitive information or details that an app needs to authenticate, then URL parameters aren't a good fit (and accept token response parameters should be ok)

2. No matter what we tell people, sometimes sensitive information or details that need to be authenticated by the app (rather than blindly trusted) will be part of a developer's use case... so see (1).

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

kpshek commented on Issue #59

Thanks for that note, @jmandel. In all of the proposals we've discussed so far around this, the value would be communicated to the SMART app along with the other context variables alongside the OAuth 2 access token -- not as URL parameters on the launch URL.

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

kpshek closed Issue #59

---

Last updated: Apr 12 2022 at 19:14 UTC