FHIR Infrastructure Minutes CC 20171019

SMART Ballot Reconciliation

Full Notes in Zulip

SMART Ballot Reconciliation Call: 2017-10-19 Today Josh Mandel: 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) Josh Mandel: Key docs for our call: Ballot Themes List and Ballot Summary Spreadsheet

Kevin Shekleton: 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

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

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.

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

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.

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

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.

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

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.

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

Josh Mandel: Joe from Aegis joins.

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

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.)

Kevin Shekleton: Josh to send out block vote for next week

<End of call>