Difference between revisions of "FHIR Infrastructure Minutes CC 20171019"
Josh mandel (talk | contribs) (Created page with "== SMART Ballot Reconciliation == [https://chat.fhir.org/#narrow/stream/smart/topic/SMART.20Ballot.20Reconciliation.20Call.3A.202017-10-19 Full Notes in Zulip] SMART Ballot...") |
Josh mandel (talk | contribs) |
||
| Line 7: | Line 7: | ||
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: 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 | Josh Mandel: Key docs for our call: Ballot Themes List and Ballot Summary Spreadsheet | ||
| + | |||
Kevin Shekleton: Attendees: | 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. | Proposal to include something like smart-configuration.json that includes a client's capabilities. | ||
| Line 27: | Line 29: | ||
Pass: 7 for, 0 abstain, 0 against | 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. | Remove resource and location. Mark smart_style_url as experimental. | ||
Motion (Kevin, 2nd by Isaac): Adopt ballot proposal as written | Motion (Kevin, 2nd by Isaac): Adopt ballot proposal as written | ||
| + | |||
Pass: 7 for, 0 abstain, 0 against | 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. | + | |
| − | + | ''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 | Long discussion at https://github.com/smart-on-fhir/smart-on-fhir.github.io/issues/133 | ||
| Line 40: | Line 50: | ||
Pass: 7 for, 0 abstain, 0 against | 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. | + | |
| − | + | '' | |
| + | 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> | <Discussion of this issue amongst several people> | ||
| Line 47: | Line 61: | ||
Pass: 7 for, 0 abstain, 0 against | 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. | + | |
| − | + | ''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. | Motion (Kevin, 2nd by Isaac): Do not document best practices on dynamic registration. Defer this for a future consideration into SMART. | ||
| Line 55: | Line 72: | ||
Josh Mandel: Joe from Aegis joins. | 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 | 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 | 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.) | + | |
| + | ''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 | Kevin Shekleton: Josh to send out block vote for next week | ||
| + | |||
| + | |||
<End of call> | <End of call> | ||
Revision as of 20:10, 19 October 2017
Contents
- 1 SMART Ballot Reconciliation
- 1.1 Topic #1 - Client Conformance
- 1.2 Topic #2 - Omit needless launch contexts
- 1.3 Topic #3 - Tenant Concept
- 1.4 Topic #4 - Behavior of patient/*.read
- 1.5 Topic #5 - Registering a SMART app with an EHR (dynamic registration)
- 1.6 Topic #6 - "Using OAuth 2 for authentication overloads that model in ways that can be risky"
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
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>
