Difference between revisions of "October 10, 2017 Security Conference Call"
(5 intermediate revisions by the same user not shown) | |||
Line 63: | Line 63: | ||
• 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 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. | • Add NIST SP 800-63, NIST SP 800-53, and NISTR 8062 to Security Standards section. | ||
+ | *Security WG Bulk Data Transfer Comments on [https://chat.fhir.org/#narrow/stream/implementers/topic/Bulk.20Data.20AccessFHIR 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 [https://www.healthit.gov/buzz-blog/interoperability/get-ready-for-a-showdown/ Get Ready for a Showdown! – The Secure API Server Showdown Challenge] | ||
==Minutes== | ==Minutes== | ||
Line 68: | Line 85: | ||
*October 3rd Minutes reviewe deferred. | *October 3rd Minutes reviewe deferred. | ||
*Agenda reviewewed and approved | *Agenda reviewewed and approved | ||
− | *Is Privacy Obsolete? updates - Chris and John have added articles. Links to the IPO? List Serve added. | + | *Quick look at [https://www.healthit.gov/buzz-blog/interoperability/get-ready-for-a-showdown The Secure API Server Showdown Challenge] |
− | + | *Is Privacy Obsolete? updates - Chris and John have added articles. Links to the IPO? List Serve added. | |
− | *FHIR Bulk Data Transfer comments. | + | *John referenced the HL7 Blog Posts by Sandeep Giri [http://blog.hl7.org/hl7_fhir_connectathon16_patientconsent_oauth2 HL7® FHIR® Connectathon 16: Patient Consent Forms: Redundant in the World of OAuth2? Part 1 of 2] and [http://blog.hl7.org/hl7_fhir_connectathon16_patientconsent_oauth2-0 HL7® FHIR® Connectathon 16: Patient Consent Forms: Redundant in the World of OAuth2? Part 2 of 2] which captured the main findings from the CCDE Connectathon Track. |
− | *Kathleen presented topics for HL7 comments on the ONC ISA 2018 for input by Security WG. | + | *Kathleen will add links to the Consumer Centric Data Exchange (CCDE) thread on HL7 Blog, from the Connectathon wiki, and MiHIN CCDE Confluence stite. |
+ | *John and Kathleen discussed the 2 individual Right of Access (RoA) use cases, which were explored in the CCDE Connectathon Track in September: (1) MU VDT with RoA requested by the patient directly - where the Discloser has already identitiy proofed and can authenticate the patient requesting RoA as well as vetted the patient designated App end point, which does not require a prospective signed RoA consent directive, and where the RoA consent directive can be memorialized retrospectively; and (2) RoA where the end point requesting access is a third party acting on behalf of the patient, which does require prospective signed individual RoA consent directive. See [https://www.hhs.gov/hipaa/for-professionals/privacy/guidance/access/index.html HHS Individuals’ Right under HIPAA to Access their Health Information 45 CFR § 164.524] and [https://www.hhs.gov/hipaa/for-professionals/faq/2041/why-depend-on-the-individuals-right/index.html HHS Right of Access vs. HIPAA Authorization] | ||
+ | *FHIR Bulk Data Transfer comments - John indicated that he'd posted these on the [https://chat.fhir.org/#narrow/stream/implementers/topic/Bulk.20Data.20Access FHIR Zulip Chat. Grahame has responded. | ||
+ | *Kathleen presented topics for HL7 comments on the ONC ISA 2018 for input by Security WG. Plan is to continue comment development in these areas and seek WG approval during next week's call. | ||
+ | *John will hold a FHIR Security call later in the day. | ||
+ | *Meeting adjourned. |
Latest revision as of 16:32, 11 October 2017
Contents
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 |
Agenda
- (3 min) Roll Call, Agenda Approval
- (10 min) Review and Approval of October 3rd Minutes.
- (10 min) Is Privacy Obsolete? Study Group wiki page with IOP? Listserve link. Update on project - Mike Davis and Chris Shawn
- (5 min) Update on Security WG Bulk Data Transfer Comments submission - John Moehrke
- (30 min) Review and draft Security WG comments on PAC comment guidelines and highlighted ISA items related to Security and CBCP Scope
- (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
- Kathleen Chaired.
- October 3rd Minutes reviewe deferred.
- Agenda reviewewed and approved
- Quick look at The Secure API Server Showdown Challenge
- Is Privacy Obsolete? updates - Chris and John have added articles. Links to the IPO? List Serve added.
- John referenced the HL7 Blog Posts by Sandeep Giri HL7® FHIR® Connectathon 16: Patient Consent Forms: Redundant in the World of OAuth2? Part 1 of 2 and HL7® FHIR® Connectathon 16: Patient Consent Forms: Redundant in the World of OAuth2? Part 2 of 2 which captured the main findings from the CCDE Connectathon Track.
- Kathleen will add links to the Consumer Centric Data Exchange (CCDE) thread on HL7 Blog, from the Connectathon wiki, and MiHIN CCDE Confluence stite.
- John and Kathleen discussed the 2 individual Right of Access (RoA) use cases, which were explored in the CCDE Connectathon Track in September: (1) MU VDT with RoA requested by the patient directly - where the Discloser has already identitiy proofed and can authenticate the patient requesting RoA as well as vetted the patient designated App end point, which does not require a prospective signed RoA consent directive, and where the RoA consent directive can be memorialized retrospectively; and (2) RoA where the end point requesting access is a third party acting on behalf of the patient, which does require prospective signed individual RoA consent directive. See HHS Individuals’ Right under HIPAA to Access their Health Information 45 CFR § 164.524 and HHS Right of Access vs. HIPAA Authorization
- FHIR Bulk Data Transfer comments - John indicated that he'd posted these on the [https://chat.fhir.org/#narrow/stream/implementers/topic/Bulk.20Data.20Access FHIR Zulip Chat. Grahame has responded.
- Kathleen presented topics for HL7 comments on the ONC ISA 2018 for input by Security WG. Plan is to continue comment development in these areas and seek WG approval during next week's call.
- John will hold a FHIR Security call later in the day.
- Meeting adjourned.