FHIR Infrastructure Minutes CC 20171026
Contents
SMART Ballot Reconciliation
Key docs for our call: Ballot Themes List with prioritized issues in red at the bottom; and Ballot Summary Spreadsheet with full ballot comments + dispositions so far.
Attendees:
- Josh Mandel (FHIR-I)
- Kevin Shekleton (Cerner)
- Eric Haas (Health Data, Inc)
- Dylan Mahalingam (MITRE)
- Jeff Danford (AllScripts)
- Nikolai Schwertnewr (Interopion)
- Isaac Vetter (Epic)
- Dan Gottlieb (Boston Children's Hospital)
- Grahame Grieve (HL&, FHIR-I) - joined on topic #4
Josh - Reminder that there is a block vote (see the block vote tab on this spreadsheet) coming up. If you want something pulled from the block vote, speak up
Topic #1 - Use Cases Theme (row 17)
Josh: This could be resolved by simply taking the contents of the Argonaut use cases PDF and including them directly into the spec
Eric: We should talk with Micky to see what we need to do to incorporate the Argonaut documentation into the SMART spec (permission from Argonaut?).
Eric & Kevin agreed that this PDF content should live in just one place (wherever that may be)
Isaac: This topic will be addressed via the 'Intro language' theme (next up).
Topic #2 - Intro Language Theme (row 19)
Motion (Eric, 2nd by Dylan): Wordsmith the introduction language on the main page, retaining the link to the Argonaut PDF (actual wording at the discretion of the editor)
Wordsmith the following language and incorporate into the specification:
"SMART Health IT is an open, standards based technology platform that enables innovators to create apps that seamlessly and securely run across the healthcare system. Using an electronic health record (EHR) system or data warehouse that supports the SMART standard, patients, doctors, and healthcare practitioners can draw on this library of apps to improve clinical care, research, and public health.
The SMART App Launch Framework connects third-party applications to Electronic Health Record data, allowing apps to launch from inside or outside the user interface of an EHR system. The framework supports apps for use by clinicians, patients, and others. It provides a reliable, secure authorization protocol for a variety of app architectures, including apps that run on an end-user's device as well as apps that run on a secure server. For details about the use cases that the SMART App Launch Framework supports, see the Use Cases 1-4 developed by the Argonaut Project"
Pass: 7 for, 0 against, 0 abstain
Topic #3 - Token Introspection Theme (row 18)
Josh: What does everyone think of mentioning token introspection as something to consider, similar to what we do for dynamic registration?
Isaac: Sounds good (also, this is an optional feature so not required to implement)
Motion Isaac (2nd by Kevin): Add information on token introspection to the spec (similar to how we mention dynamic registration)
Include a reference to Token Introspection in the specification, describing it as an optional feature that EHRs may want to consider (similar to how we describe dynamic registration) Include an OAuth discovery URI called "introspection" that a client can use to learn a server's introspection URL, if any.
Pass: 7 for, 0 against, 0 abstain
Topic #4 - Persisting tokens Theme (row 20)
<Discussion on word smithing the line in question>
Motion Grahame (2nd by Kevin): Reword based upon word smithing
"Persuasive with mod
"Apps should persist tokens and other sensitive data in app-specific storage locations only, not in system-wide-discoverable locations."" -> Apps should not persist tokens and other sensitive data in a way that allows unauthorized access."
Pass: 8 for, 0 against, 0 abstain
Topic #5 - Two kinds of clients Theme (row 21)
Motion Kevin (2nd by Jeff): - Word smith introduction to link to the OAuth 2 specification - Let Ken know that the terms "public" and "confidential are from OAuth 2. Also, we have offline_access and online_access
Persuasive with Mod
We should update the introduction to our ""Two Types of Clients"" section to read: ""Within this profile we differentiate between the two types of apps defined in the [OAuth 2.0 specification: confidential and public]. The differentiation is based upon..."
We note to Ken that the term ""public"" comes from OAuth and we want to maintain transparency with this terminology. The public client is not prohibited from doing refreshes; this is up to an EHR to determine.
We also note to Ken, regarding refreshes: we have provided a response in the ""online_access"" and ""offline_access"" themes."
Pass: 8 for, 0 against, 0 abstain
<End of call>
