This wiki has undergone a migration to Confluence found Here
<meta name="googlebot" content="noindex">

HL7 FHIR Security 2018-03-20

From HL7Wiki
Revision as of 12:50, 21 March 2018 by JohnMoehrke (talk | contribs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Call Logistics

Weekly: Tuesday at 05:00 EST (2 PM PST) 

Web conference desktop and VOIP https://www.freeconferencecall.com/join/security36 
Online Meeting ID: security36
Phone: +1 515-604-9567, Participant Code: 880898
 Please be aware that teleconference meetings are recorded to assist with creating the meeting minutes

Back to HL7 FHIR security topics

Attendees

Member Name Member Name Member Name
x John Moehrke Security Co-Chair x Kathleen Connor Security Co-Chair . Alexander Mense Security Co-chair
x Suzanne Gonzales-Webb CBCC Co-Chair . Mike Davis x Joe Lamy AEGIS
x Ali Massihi . Johnathan Coleman CBCC Co-Chair . Glen Marshal
. Diana Proud-Madruga . Rob Horn x Beth Pumo
. Irina Connelly . Mario Hyland AEGIS . Mark Underwood NIST
x Peter Bachman x Grahame Greve FHIR Program Director . blank

Agenda

Minutes

  • John chaired
  • approval of agenda
  • approval of the HL7 FHIR Security 2017-12-05 and HL7 FHIR Security 2018-02-06 and HL7 FHIR Security 2018-02-20 and HL7 FHIR Security 2018-03-13 Minutes
    • Motion to approve all: Kathleen Connor / Joe Lamy : 7-0-0
  • Poll to determine if a different time for this meeting would bring in more attendance
    • https://doodle.com/poll/nxccanax4ua2rf5m
    • ACTION: John to send a reminder
    • Right now there is not clear indication that we could find a better time
    • Request Grahame promote people he knows that are interested in security to engage
  • Johnathan specific guidance given a paper from ONC that might guide improvements to the security guidance
  • All security open http://gforge.hl7.org/gf/project/fhir/tracker/?action=TrackerItemBrowse&tracker_id=677&tracker_query_id=4967
    • Skipped for this week
  • Grahame suggestion for future topics
    • when are we going to issue a profile around app registration (profiling standard rfc to match smart app launch so we're interoperable at that level too
      • Would be good to gather current practices. How are systems and organizations satisfying the need today?
      • UMA seems might have a solution built into the UMA specification
      • Kathleen and Grahame will help gather examples of current practice
    • what are we going to do about Smart App Launch scopes? What's the relationship between scopes and consent?
      • Would be good to gather current practices. How are systems and organizations satisfying the need today?
      • Grahame reports that HEART is starting on a next revision, so that might also factor in
      • Grahame has a advanced model that grew organically in his server, with security logical groups of Resources
      • Grahame reports that one proposal he likes is that the scope holds the URL to the FHIR Consent receipt, where the RS is capable and expected to enforce the provisions in that Consent.
      • Kathleen and Grahame will help gather examples of current practice
    • when are we going to work on a protocol to leverage to OAuth to enable to different FHIR servers to communicate directly with each other?
      • Where a consent is directing two (or more) services to have direct communications. For example the patient tells hospital A and hospital B that they both are authorized to talk about that patient directly between hospital A and hospital B without needing to go through the patient.
      • Not clear to me how this is not already inscope of Sync for Science... where hospital A is treated as a patient selected app that the authorize with hospital B; and where hospital B is treated as a patient selected app that is authorized with hospital A. The result of this logically is simply a bi-directional communication where each hospital has a long-term token that is good for that patient at the other hospital. This could be made more streamlined at the UX, but the resulting technical solution would be the same. The drawback is that each hospital then needs to manage long-term (thus expiring) tokens for each patient/remote-system; and tokens must be managed securely so couldn't be managed in the Patient resource.
      • does bring up more visibly the need for transparency
    • are we going to back backend services and adopt that? Do we need to say anything about certificate management? Are we going to adopt openID tokens for communicating user in focus on backend services?
      • This might be the most urgent, and most simple.
      • Gather examples of current practice
    • what questions should I be asking that are blocking patients|providers|payers from actually accessing the information they should be able to get?
      • Good open ended statement. Possibly the ONC efforts will help structure and advance us.
  • John asks Grahame: I notice no mention of audit log or audit report for a patient to indicate transparently communications that have happened. Is this just an oversite, or are the people Grahame talks to simply not talking about this functionality.
    • Grahame: He has an answer to the broad question that FHIR has AuditEvent that that can enable the report. He has not gotten pushback or further questions. This might be because it is clear, or might be because they are not prioritizing the solution given there seems to be a basic answer.
      • John: We do have more CR to improve this messaging. R4 has some improved text already.
Retrieved from "https://wiki.hl7.org/w/index.php?title=HL7_FHIR_Security_2018-03-20&oldid=154782"