FHIR Chat · docs / Issue #323 May 2018 Ballot Comment 117 · cds hooks/github

Stream: cds hooks/github

Topic: docs / Issue #323 May 2018 Ballot Comment 117

---

Github Notifications (May 16 2018 at 23:02):

cds-hooks-bot milestoned Issue #323

Github Notifications (May 16 2018 at 23:02):

cds-hooks-bot labeled Issue #323

Github Notifications (May 16 2018 at 23:02):

cds-hooks-bot edited Issue #323

## May 2018 Ballot Comment 117

Submitted by @kensaku-kawamoto on behalf of @euvitudo from University of Utah

Chapter: Link
Section: https://cds-hooks.org/specification/1.0/
Type: A-S :bulb:
In Person Requested? Yes :bust_in_silhouette:

Existing Wording:

appContext: An optional field that allows the CDS Service to pass context regarding the launch of this SMART app from the CDS card to the SMART app. The appContext field should only be valued if the link type is smart and is not valid for absolute links. The appContext field and value will be sent to the SMART app as part of the OAuth 2 access token response, alongside the other launch context when the SMART app is launched.

Comment:
Recommend we be able to send information/insights gained from the CDS Hooks process to the SMART app as parameters.

---

_This issue was imported by @cds-hooks-bot from the consolidated CDS Hooks May 2018 ballot spreadsheet._

Github Notifications (May 16 2018 at 23:02):

cds-hooks-bot opened Issue #323

## May 2018 Ballot Comment 117

Submitted by @kensaku-kawamoto on behalf of @euvitudo from University of Utah

Chapter: Link
Section: https://cds-hooks.org/specification/1.0/
Type: A-S :bulb:
In Person Requested? Yes :bust_in_silhouette:

Existing Wording:

appContext: An optional field that allows the CDS Service to pass context regarding the launch of this SMART app from the CDS card to the SMART app. The appContext field should only be valued if the link type is smart and is not valid for absolute links. The appContext field and value will be sent to the SMART app as part of the OAuth 2 access token response, alongside the other launch context when the SMART app is launched.

Comment:
Recommend we be able to send information/insights gained from the CDS Hooks process to the SMART app as parameters.

---

_This issue was imported by @cds-hooks-bot from the consolidated CDS Hooks May 2018 ballot spreadsheet._

Github Notifications (May 20 2018 at 10:45):

kpshek commented on Issue #323

Hi @euvitudo,

While reviewing the ballot comments in Cologne earlier this week, we had a question regarding this ballot comment (117) from you.

Your comment was that we “Recommend we be able to send information/insights gained from the CDS Hooks process to the SMART app as parameters.” Were you referring to URL parameters such that a CDS Service could return a link to a SMART app where the URL contains parameters containing this information?

For example:

{
  "summary": "Example Card",
  "indicator": "info",
  "source": {
    "label": "Example"
  },
  "links": [
    {
      "label": "Example SMART app",
      "url": "https://example.com/launch?myCustomParam=1&anotherParam=abc",
      "type": "smart"
    }
  ]
}

If this was what you were suggesting, check out our discussion in issue #59, where we debated the pros/cons of the various approaches for a CDS Service to communicate custom information to the SMART app they link to. We ultimately went with launch context parameters alongside your OAuth access token (via the appContext field) as this provides a better security model, as any parameters which are sensitive would not be shared/accessible via the URL.

Let us know if this what your ballot commenter was referring to or if we misunderstood. Thanks!

Github Notifications (May 21 2018 at 16:43):

euvitudo commented on Issue #323

Hi @kpshek,

URL parameters are not ideal as you mention, as they would expose PHI.

The appContext field is limiting, as a String is likely not sufficient for all use cases. Which is to say that a full JSON object would be beneficial (e.g., a Parameters resource). That's really what I wanted to say and ultimately wasn't clear on that (apologies).

A couple alternatives to consider:

1. allow passing a Parameters resource in the CDSResponse (as part of the spec) where the appContext could reference the ID
2. set the value of appContext field to the Parameters resource

In either case, the EHR can either (1) pass the Parameters as part of the OAuth 2 access token, or (2) provide a reference to the Parameters, where the SoF app would then obtain them via the EHR's FHIR service. Both the EHR and the SoF app must understand the protocol.

Github Notifications (May 21 2018 at 18:50):

kpshek commented on Issue #323

@euvitudo - Thanks for the additional clarification! Now I understand. :smile:

You could represent a full JSON object as a string which is why we didn't think it was limiting. For instance:

{
  "summary": "Example Card",
  "indicator": "info",
  "source": {
    "label": "Example"
  },
  "links": [
    {
      "label": "Example SMART app",
      "url": "https://example.com/launch",
      "type": "smart",
      "appContext": "{\"foo\":1,\"bar\":{\"baz\":false}}"
    }
  ]
}

That appContext blows out to the following JSON (which I've formatted for readability:

{
  "foo":1,
  "bar":{
    "baz":false
  }
}

You could even serialize a FHIR Parameters resource as JSON and communicate it as well like this. :fire:

This is why we went with the string type for appContext. The value is inherently something only the CDS Service and SMART app understand (which you pointed out too). As such, choosing a string type allows CDS Hooks to support any data the two entities want to communicate between each other. Parties that want to share simple data can do so easily with a simple string; if you want to share more complex data in a richer format, you can do as well by simply serializing it as json (like in the above example).

Choosing some other type like the FHIR Parameters resource also allows any data to be shared, albeit in a more verbose fashion. So, if you want to communicate this data via the Parameters resource, feel free to -- just serialize it over in the string field. We believe the majority of SMART apps/CDS Services won't communicate using that data type; most are just wanting to communicate a simple bit of data (like session/reference id).

Thanks again for the additional clarification behind your ballot comment. I've tagged this for discussion on the May 30th CDS working group call. Let me know if you want to discuss it on a different CDS working group call.

Github Notifications (May 21 2018 at 18:58):

euvitudo commented on Issue #323

This intent should be communicated clearly in the spec.

Github Notifications (May 30 2018 at 22:33):

kpshek commented on Issue #323

## :telephone_receiver: CDS Working Group Vote (5-30-2018)

Meeting notes: http://wiki.hl7.org/index.php?title=File:2018-05-30_CDS_WG_Call_Minutes.docx

@kpshek moved the following disposition, seconded by @euvitudo.

Disposition: Persuasive with Mod
Disposition Comment:
We will clarify the documentation to state that appContext allows you to share any information between a CDS Service and SMART app with this string value. We will also include an example showing appContext being used to share data between a CDS Service and SMART app launch.

:+1: For: 15
:expressionless: Abstain: 0
:-1: Against: 0

:tada: The motion passed! :tada:

Github Notifications (Jun 14 2018 at 13:43):

cds-hooks-bot assigned Issue #323

Github Notifications (Aug 08 2018 at 13:40):

kpshek closed Issue #323

---

Last updated: Apr 12 2022 at 19:14 UTC