FHIR Chat · SMART Ballot Reconciliation Call: 2017-10-19 · smart

Stream: smart

Topic: SMART Ballot Reconciliation Call: 2017-10-19


view this post on Zulip Josh Mandel (Oct 19 2017 at 18:37):

I'm going to try taking notes for minutes here -- and please feel free to join in the discussion. https://join.freeconferencecall.com/fhir (meeting ID: FHIR)

view this post on Zulip Josh Mandel (Oct 19 2017 at 18:37):

Key docs for our call: Ballot Themes List and Ballot Summary Spreadsheet

view this post on Zulip Kevin Shekleton (Oct 19 2017 at 19:04):

Attendees:
- Josh Mandel
- Avinash Shanbhag (ONC)
- Kevin Shekleton (Cerner)
- Isaac Vetter (Epic)
- Jeff Danford (AllScripts)
- Robert Scanlon (MITRE)
- Dylan Mahalingam (MITRE)
- Eric Haas
- Joe Lamy (Aegis) -- joined on topic #5

view this post on Zulip Kevin Shekleton (Oct 19 2017 at 19:09):

Topic #1 - Client Conformance
Proposal to include something like smart-configuration.json that includes a client's capabilities.

Kevin: Good idea but propose we push this until a future revision to SMART
<All: Discussion on the details behind this particular topic>

Motion (Kevin, 2nd by Jeff): Defer this enhancement until a future revision to SMART.

Pass: 7 for, 0 abstain, 0 against

view this post on Zulip Josh Mandel (Oct 19 2017 at 19:17):

"Wait: Given that ""capabilities"" are a new API feature, and that servers will just be starting to produce capability lists, it is too early to standardize the publication of client capability statements. We can pick this up in a future revision.

view this post on Zulip Kevin Shekleton (Oct 19 2017 at 19:17):

Topic #2 - Omit needless launch contexts
Remove resource and location. Mark smart_style_url as experimental.

Motion (Kevin, 2nd by Isaac): Adopt ballot proposal as written
Pass: 7 for, 0 abstain, 0 against

view this post on Zulip Josh Mandel (Oct 19 2017 at 19:24):

Given their limited use, standardized concepts for "location" and "resource" should be removed from the specification. "smart_style_url" should be marked as "experimental" to indicate that there may be backwards-incompatible changes to the style document pointed to by the smart_style_url.

view this post on Zulip Kevin Shekleton (Oct 19 2017 at 19:24):

Topic #3 - Tenant Concept
Long discussion at https://github.com/smart-on-fhir/smart-on-fhir.github.io/issues/133

Motion (Kevin, 2nd by Eric): Defer the notion of tenant as a launch parameter per the ballot proposal

Pass: 7 for, 0 abstain, 0 against

view this post on Zulip Josh Mandel (Oct 19 2017 at 19:28):

Given the long conversation without a clear agreement on terms and use case, we should not try to add a new "tenant" (or equivalent) to the specificaiton during this reconciliation process. We should take this up as follow-on work.

view this post on Zulip Kevin Shekleton (Oct 19 2017 at 19:29):

Topic #4 - Behavior of patient/*.read
<Discussion of this issue amongst several people>

Motion (Kevin, 2nd by Jeff): Indicate that there are varying implementations of wildcard scopes and that we need to clarify this in the future.

Pass: 7 for, 0 abstain, 0 against

view this post on Zulip Josh Mandel (Oct 19 2017 at 19:45):

Indicate that there is variability in implementations today, where some EHRs enable access to related resource (e.g. Practitioners linked to from Patient-specific resources) and other do not. We will try to provide better definitions in the future.

view this post on Zulip Kevin Shekleton (Oct 19 2017 at 19:49):

Topic #5 - Registering a SMART app with an EHR (dynamic registration)

Motion (Kevin, 2nd by Isaac): Do not document best practices on dynamic registration. Defer this for a future consideration into SMART.

Pass: 8 for, 0 abstain, 0 against

view this post on Zulip Josh Mandel (Oct 19 2017 at 19:51):

Joe from Aegis joins.

view this post on Zulip Kevin Shekleton (Oct 19 2017 at 19:53):

Topic #6 - "Using OAuth 2 for authentication overloads that model in ways that can be risky"

Motion (Kevin, 2nd by Isaac): Close this ballot comment as not persuasive since this is not the purpose of a bearer token. OpenID Connect is our mechanism for authentication, not OAuth 2

Pass: 8 for, 0 abstain, 0 against

view this post on Zulip Josh Mandel (Oct 19 2017 at 19:59):

We do not find this persusasive. SMART uses OAuth 2.0 for authorization, rather than authentication. Apps should not treat OAuth access tokens as evidence of authentication. (For that, the recommendation is to use OpenID Connect's id_token.)

view this post on Zulip Kevin Shekleton (Oct 19 2017 at 19:59):

Josh to send out block vote for next week

<End of call>

view this post on Zulip Josh Mandel (Oct 20 2017 at 15:04):

Minutes cleaned (slightly) at: http://wiki.hl7.org/index.php?title=FHIR_Infrastructure_Minutes_CC_20171019


Last updated: Apr 12 2022 at 19:14 UTC