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

July 11, 2017 Security Conference Call

From HL7Wiki
Revision as of 18:56, 18 July 2017 by Mayada Abdulmannan (talk | contribs) (→‎Attendees)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Back to Security Main Page

Attendees

x Member Name x Member Name x Member Name x Member Name
. John MoehrkeSecurity Co-chair x Kathleen ConnorSecurity Co-chair . Alexander Mense Security Co-chair . Trish WilliamsSecurity Co-chair
x Mike Davis x Suzanne Gonzales-Webb x David Staggs
x Glen Marshall, SRS x Beth Pumo . Ioana Singureanu . Rob Horn
x Diana Proud-Madruga . Serafina Versaggi x Joe Lamy . Galen Mulrooney
. Duane DeCouteau . Chris Clark . Johnathan Coleman . Aaron Seib
. Ken Salyards . Christopher D Brown TX . Gary Dickinson x Dave Silver
x Rick Grow . William Kinsley . Paul Knapp x Mayada Abdulmannan
. Kamalini Vaidya . Bill Kleinebecker x Christopher Shawn . Grahame Grieve
. Oliver Lawless . Ken Rubin . David Tao . Nathan Botts

Back to Security Main Page

Agenda

  1. (2 min) Roll Call, Agenda Approval
  2. (4 min) Review and Approval of Security WG Call Minutes June 20,72017
  3. (10 min) July Harmonization Final Proposals - Report out on Harmonization Proposal Submission and plans for moving the Signature Type proposal, which was withdrawn, forward in next cycle - Kathleen and John
  4. #(5 min) Review News and Reminders - See below.
  5. (30 min) Break the Glass - new version Mike Davis
  1. (10 min) FHIR Security call this week - Overview of Block Vote - John

News and Reminders

  • FHIR Security Block Vote today - John has sent out reminders to the list a couple of times. Please review, attend, and vote, or send John your vote on the block.
  • Direct Trust, and FHIR: A Value PropositionThis paper is short with great insights – explains why Smart on FHIR is not adequate for FHIR Trust Framework, and a description of how DirectTrust trust anchor bundles and PKI trust authority could be used for that capability.
  • Excerpt - Using Direct Trust Certificates with the FHIR RESTful API

As discussed above, the FHIR API itself specifies no particular security arrangement. The focus of the existing implementation work on the SMART-on-FHIR is around authorization mediated by a human as part of the interaction (C2B context). In this context, the authentication of the user is delegated to the authorizing server. The existing work in the FHIR eco-system does not deal with establishing trust between systems. To authenticate system to system communication, some trust framework will be needed – either point to point agreement about certificates and other security tokens, or some mediated trust community will need to provide a framework in which these are managed. The DirectTrust community could serve this role – this would enable the 94,000+ existing DirectTrust enabled institutions and 1.5 million identity proofed addressees at those institutions to allow connections between each other without the need for point-to-point agreements. Such an arrangement would also potentially save the FHIR community from the financial requirement to build a new trust framework by using one already proven to scale high identity assurance. Enabling this requires both technical and policy agreements. A separate specification “Using Direct Trust Certificates with the RESTful API” (still under development) describes how appropriate DirectTrust certificates can be acquired and used to secure RESTful APIs, and lays out a basic policy framework to allow any DirectTrust participant to automatically accept and process requests from data from any other participant.

  • Harmonization Proposal Submission e-Vote results: Based on the number of participants at the June 27th call, which was 10, the number of e-votes needed for approval = 4 or more. Per Security WG DMP, the email vote was open for one week from June 29th through July 6th. I received 7 affirmative votes from Trish Williams, Jim Kretz, Ken Salyards, David Pyke, Johnathan Coleman, Mike Davis, and Chris Shawn. Proposals submitted were:  Add Competency ActReason Code; Add Five Security Compartment Label Codes; and Add Purpose of Use codes. Harmonization meeting is scheduled for July 11 - 12 Each Day, at Noon Eastern Time(12:00PM) GoToMeeting: https://global.gotomeeting.com/join/204365989 Meeting ID: 204365989 Audio Line: 1-770-657-9270 pc 598745#
  • ONC 21st Century Cures Act Trusted Exchange Framework and Common Agreement Kick-Off Meeting June 24, 2017. As part of the July 24, 2017 meeting, ONC will share the results of a recent analysis of existing frameworks that support the interoperable flow of health information across disparate networks and supportive principles related to enabling trusted exchange nationally. The meeting also will provide an opportunity for stakeholders to comment on existing national trust infrastructures used to exchange health information electronically and on electronic data sharing best practices.
  • RSVP for Webmeeting to maxwell.souder@hhs.gov
Agenda


Minutes

  • Chaired by Alex
  • Agenda Approved
  • Approved of Security WG Call Minutes June 20,72017
    • ( Mike, Kathleen approved) ( Ken, Josh Abstained)
  • July Harmonization Final Proposals - Report out on Harmonization Proposal Submission and plans for moving the Signature Type proposal, which was withdrawn, forward in next cycle - Kathleen and John
    • All final proposals were approved
  • News and Reminders (Reviewed from Agenda by Kathleen) See below
    • • FHIR Security Block Vote today - John has sent out reminders to the list a couple of times. Please review, attend, and vote, or send John your vote on the block.

• Direct Trust, and FHIR: A Value PropositionThis paper is short with great insights – explains why Smart on FHIR is not adequate for FHIR Trust Framework, and a description of how DirectTrust trust anchor bundles and PKI trust authority could be used for that capability. • Excerpt - Using Direct Trust Certificates with the FHIR RESTful API As discussed above, the FHIR API itself specifies no particular security arrangement. The focus of the existing implementation work on the SMART-on-FHIR is around authorization mediated by a human as part of the interaction (C2B context). In this context, the authentication of the user is delegated to the authorizing server. The existing work in the FHIR eco-system does not deal with establishing trust between systems. To authenticate system to system communication, some trust framework will be needed – either point to point agreement about certificates and other security tokens, or some mediated trust community will need to provide a framework in which these are managed. The DirectTrust community could serve this role – this would enable the 94,000+ existing DirectTrust enabled institutions and 1.5 million identity proofed addressees at those institutions to allow connections between each other without the need for point-to-point agreements. Such an arrangement would also potentially save the FHIR community from the financial requirement to build a new trust framework by using one already proven to scale high identity assurance. Enabling this requires both technical and policy agreements. A separate specification “Using Direct Trust Certificates with the RESTful API” (still under development) describes how appropriate DirectTrust certificates can be acquired and used to secure RESTful APIs, and lays out a basic policy framework to allow any DirectTrust participant to automatically accept and process requests from data from any other participant. • Harmonization Proposal Submission e-Vote results: Based on the number of participants at the June 27th call, which was 10, the number of e-votes needed for approval = 4 or more. Per Security WG DMP, the email vote was open for one week from June 29th through July 6th. I received 7 affirmative votes from Trish Williams, Jim Kretz, Ken Salyards, David Pyke, Johnathan Coleman, Mike Davis, and Chris Shawn. Proposals submitted were: Add Competency ActReason Code; Add Five Security Compartment Label Codes; and Add Purpose of Use codes. Harmonization meeting is scheduled for July 11 - 12 Each Day, at Noon Eastern Time(12:00PM) GoToMeeting: https://global.gotomeeting.com/join/204365989 Meeting ID: 204365989 Audio Line: 1-770-657-9270 pc 598745# • ONC 21st Century Cures Act Trusted Exchange Framework and Common Agreement Kick-Off Meeting June 24, 2017. As part of the July 24, 2017 meeting, ONC will share the results of a recent analysis of existing frameworks that support the interoperable flow of health information across disparate networks and supportive principles related to enabling trusted exchange nationally. The meeting also will provide an opportunity for stakeholders to comment on existing national trust infrastructures used to exchange health information electronically and on electronic data sharing best practices. • RSVP for Webmeeting to maxwell.souder@hhs.gov


  • Break the Glass - new version Mike Davis
    • ReviwescEmergency Access presentation
    • ** Epic has an application called " Break the Glass"
    • Break the Glass was Updated to with the HL7 Emergency Access (HL7 Break glass Emergency Access paper)
    • Security WG is requested to review "Break the Glass" and make distinctions on access in an emergency room, and emergency use that needs to utilize " Break the Glass" to gain access
    • Break the Glass can support emergency access or the purpose can be declared explicit, or emergency (implicit), or button request access
    • It is a mechanism for enforcing Security and Privacy Policy
    • Break the Glass screen can elevate the user's permission or elevate it
    • In terms of access control and implementation there may not be a implementation engine, it can a matter of clicking on a banner
    • Break Glass attribute is mandatory as it requests the user to read, acknowledge, accept or reject
    • One Methods of triggering "Break the Glass (eg: Clinician attempting to access protected records)
    • It requires a clinician to have a couple of access's such as emergency credentials, and normal credentials
    • Lack of access can delay treatment in cases of emergency
    • If a user has a problem with their access they may also have pre-staged access (eg: such as loosing badge for access)
    • eHealth Exchange does not have a purpose of use for emergency, and these restrictions does not elevate any restrictions on the use of exchange of information
    • Break the Glass can assist in the issue of not having a purpose of use for emergency
    • Q (1) Beth: Have you had any discussion with Tom Sullivan Group with ID issues and emergency access regarding their discussion on Break the Glass?
    • A (1) Mike : We have only had discussions on XAML and was not aware they had discussions on Break the Glass
  • FHIR Security call this week - Overview of Block Vote - John
    • Call Adjourned**