FHIR Infrastructure Minutes CC 20171102
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:
- 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>
