FHIR Infrastructure Minutes CC 20171019
SMART Ballot Reconciliation
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
Kevin Shekleton: 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 "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. Kevin Shekleton: 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. Kevin Shekleton: 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. Kevin Shekleton: 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. Kevin Shekleton: 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.
Kevin Shekleton: 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>
