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

October 10, 2017 Security Conference Call

From HL7Wiki
Jump to navigation Jump to search

Back to Security Main Page

Attendees

x Member Name x Member Name x Member Name x Member Name
x John MoehrkeSecurity Co-chair x Kathleen ConnorSecurity Co-chair x Alexander Mense Security Co-chair . Trish WilliamsSecurity Co-chair
. Mike Davis x Suzanne Gonzales-Webb x David Staggs x Christopher Shawn
. Mohammed Jafari x Beth Pumo . Ioana Singureanu . Rob Horn
x Diana Proud-Madruga . Serafina Versaggi . Joe Lamy . Galen Mulrooney
. Paul Knapp . Grahame Grieve . Johnathan Coleman . Aaron Seib
. Ken Salyards x [1] . Gary Dickinson . Dave Silver
. Oliver Lawless . Ken Rubin . David Tao . Nathan Botts

Back to Security Main Page

Agenda

  1. (3 min) Roll Call, Agenda Approval
  2. (10 min) Review and Approval of October 3rd Minutes.
  3. (10 min) Is Privacy Obsolete? Study Group wiki page with IOP? Listserve link. Update on project - Mike Davis and Chris Shawn
  4. (5 min) Update on Security WG Bulk Data Transfer Comments submission - John Moehrke
  5. (30 min) Review and draft Security WG comments on PAC comment guidelines and highlighted ISA items related to Security and CBCP Scope
  6. (2 min) FHIR Security call - Call will happen at 5PM ET/2PM PT

Meeting Materials

  • Potential Comment Areas

• Upgrade maturity of data segmentation on CDA ○ Include FHIR Security labels as means to protect FHIR Bundles and Resources • Add FHIR Consent and Contract to emerging Consent Directive standards ○ Include use of both for individual Right of Access • Add FHIR Provenance to DPROV • Add FHIR Audit Event ○ Include the ability to use FHIR Audit Events to generate FHIR Accounting of Disclosure Resources • Add TF4FA and FHIR Contract for App Terms of Service and for Trust Contract to determine trading partner capabilities for e.g., consuming and enforcing computable consent directives • Add NIST SP 800-63, NIST SP 800-53, and NISTR 8062 to Security Standards section.

  • Security WG Bulk Data Transfer Comments on Chat - Zulip and Grahame Grieve's responses (Thanks John for posting for use and the dialogue with Grahame):

John Moehrke: @Grahame Grieve The Security WG looked at the Bulk Data Access proposal, and we have some Privacy and Security "Considerations". We recognize that you are simply trying to address a technical need for a solution to Bulk Data Access, and you have been careful to indicate that you have not addressed Security. We would agree with the modularity of focusing on the access method without conflating Security/Privacy; but we also want to make sure that this Bulk Data Access has a Privacy and Security Considerations so that use of the method DOES consider these issues. The Security WG minutes contain these 'issues', we stayed away from declaring 'solutions' although we do think there are ready accessible solutions. We would like to be included on development to help address these issues. See http://wiki.hl7.org/index.php?title=October_3,_2017_Security_Conference_Call#Bulk_Data_Transfer_Access_Control_.26_AuthorizationQuestions:

  • John Moehrke: Generally we are not clear what kind of use-case would allow this level of access, especially with a PERMIT without exceptions. Given that we expect many exceptions, we are concerned that a mechanism is needed to recognize the exceptions and obligations. Second we would like to assure that audit logging be specified in a way that is actionable but not unnecessarly verbose.
  • John Moehrke: There was also discussion and support for a companion method for service to de-identify, such as I outline on my blog https://healthcaresecprivacy.blogspot.com/2017/09/fhir-and-bulk-de-identification.html
  • Grahame Grieve: in general, I expect that the API itself will be use for a variety of purposes of use
  • Grahame Grieve: in general, for all the uses, there will be consent/authorization/access control issues.
  • Grahame Grieve: as yet, we have had no requests for anything related to these to appear on the API itself.
  • Grahame Grieve: we did refer a number of policy issues back to ONC for clarification - these are US specific things
  • Grahame Grieve: I agree that there's a place for de-identification in the service, but as yet this is not required or asked for
  • Grahame Grieve: finally, audit logging is a policy question. We do't anywhere specify that audit logging is required, and nor should we in the base specification

implementers > Bulk Data Access Today

  • John Moehrke: I agree that many of these issues are not the issues we would address in a core specification. But we can put them in a "Security/Privacy Considerations" section so that those that are using the core capability are informed of some of the 'considerations' . This is minimally all we ask. This is what IETF, W3C, ISO, IHE, and DICOM are doing today. This is what our Security Risk Assessment Cookbook intended to drive to happen.
  • Grahame Grieve: do you think this is different to any other access that FHIR permits?
  • John Moehrke: Yes, for the above reasons...
  • John Moehrke: The use-cases that SMART focused on were targeting either Treatment (this patient, or any patient I have access to), or accesses by the Patient themselves. These are the use-case focus that has driven the development of the scope patterns today.
  • John Moehrke: Basically, the 'risk' -- 'impact' for bulk data access is 'everyone'; where a Provider or Patient access is more clearly one-patient-at-a-time.

ONC Get Ready for a Showdown! – The Secure API Server Showdown Challenge

Minutes

Retrieved from "https://wiki.hl7.org/w/index.php?title=October_10,_2017_Security_Conference_Call&oldid=147410"