FHIR Infrastructure Minutes CC 20171102

SMART Ballot Reconciliation

Full Notes in Zulip

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:

• Joshua Bell
• Lisa Erickson
• Robert Scanlon
• Grahame Grieve
• Debbie Bucci
• Dylan Mahalingam (MITRE)
• Corey Spears (time of join noted below)
• Isaac Vetter (time of join noted below)

Topic #1 - Block Vote

Josh Mandel: Motion to approve Block Vote #1 from Grahame Grieve, Second from Rob Scanlon -- For: 4 for, 0 against, 2 abstain Josh Mandel: Cory Spears Joins

Topic #2: SD isn't needed for Capabilities

"Grahame Grieve From: http://fhir-registry.smarthealthit.org/StructureDefinition/capabilities Comment: this is never described (nor is such an end-point available). It should be described " "Not Persuasive.

This is no longer needed since Capabilities is being put in a .well-known/smart-configuration file.

Move: Grahame Grieve, Second: Debbie Bucci 5 for, 0 against, 2 abstain

Topic #3: "EHR Launch" for portals, too (65)

Comment: The main launch page assumes the app is being launched from an EHR - most interpret that as the practitioner system. Does that need to be generalized more, or do we think people will understand it could be launched, for example, from a portal? Summary: EHR vs Portal" "An app (confidential or public) can launch from within an existing EHR session, which is known as an EHR launch. --> An app can launch from within an existing EHR or Patient Portal session; this is known as an EHR launch.

Include a definition of the ""EHR Role"" up front, and also make a spot fix to the sentence above -- we'll note that this role can to a practitoiner-facing clinical system, or patient-facing system (e.g. PHR or Patient Portal); indeed to any FHIR system where a user can give permissions to launch an app.

Move Debbie Bucci / Second: Corey Spears 6 for, 0 against, 1 abstain

Topic #4: Who controls permission on launch? (73)

Hans Buitendijk Comment: If an EHR launches the app for an authenticated user who has explicitly requested the launch, asking for the end user’s authorization is optional; else the user’s authorization SHOULD be requested. from http://www.hl7.org/fhir/smart-app-launch/index.html#2-ehr-evaluates-authorization-request-asking-for-end-user-input - not sure I'm following. If a patient explicitly launches the app, we still ask for auth. If a practitioner launches an app (implicit or explicit), we do not. Is this trying to say something else? Summary: Requirement for end user input " "This is basically saying that the decision about when to prompt a user for approval is up to the EHR. We should try to simplify this language and provide an example.

Proposal from Debbie: remove the following text, ""If an EHR launches the app for an authenticated user who has explicitly requested the launch, asking for the end user’s authorization is optional; else the user’s authorization SHOULD be requested. The user should be given information regarding the client requesting the access, the request, the scope, and the time access is needed.""

Mover: Debbie Bucci, Seconder: Corey Spears 6 for, 0 against, 1 abstain

Isaac Vetter joins.

Topic #5: Token Signing

"Grahame Grieve From: A large range of threats to bearer tokens can be mitigated by digitally signing the token Comment: Which token? (this paragraph should be called out as a note, so the example following is not taken as an example relating to this pararaph) " online "Theme: ""Signed Tokens"" This note is referring to the access token. Agreed that the fomatting should be improved -- but I'm unsure what ""called out as a note"" is suggesting." "Clarify that we are talking about the Access Token

Agreed that the fomatting should be improved -- use italics as we do for the ""Apps using the standalone launch flow won’t have a launch"" paragraph above.

Move: Grahame, Second: Debbie 7 for, 0 against, 1 abstain

Topic #6: launch/patient for EHR launch?

Hans Buitendijk Comment: http://www.hl7.org/fhir/smart-app-launch/conformance/#launch-context-for-ehr-launch - states that patient and encounter are requested explicitly by the app for an EHR launch (which is equivalent to the ""launch"" scope). I thought this was only required for standalone launch? Summary: launch/patient for EHR launch? " "When an app requests ""launch/encounter"", for example - the EHR decides what to supply. During an EHR Launch scope, if there's no current encounter in scope, is the ""launch/encounter"" scope asking the EHR to display an encounter-picker in order to define a new context?

Eventually we might want to introduce different parameters to differentiate between ""I need this; don't bother launching me without it"" vs. ""It'd be nice to have, but I can work either way"" -- but not for this version of the specification.

Mover: Isaac Vetter, Seconder: Grahame Grieve 7 for, 0 against, 1 abstain

<End of call>