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

June 27, 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 . Alexander Mense Security Co-chair . Trish WilliamsSecurity Co-chair
x Mike Davis x Suzanne Gonzales-Webb . David Staggs . [mailto:]
. Glen Marshall, SRS . Beth Pumo . Ioana Singureanu . Rob Horn
. Diana Proud-Madruga x Serafina Versaggi x Joe Lamy . Galen Mulrooney
. Duane DeCouteau x [mailto: anonymous] . Johnathan Coleman . Aaron Seib
. Ken Salyards . Christopher D Brown TX . Gary Dickinson x Dave Silver
. [mailto:] . 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, 2017
  3. (10 min) Review News and Reminders - See below.
  4. (20 min) July Harmonization Proposal QA Review and Request for approval of initial submission see *July 2017 Harmonization Proposal Overview - Kathleen
  5. (5 min)FHIR Security call this week

News and Reminders

  • Thanks John for pointing out the "major change" NIST Launches New Special Publication (SP) 800-63 Suite!. RE: "Gone are the days of levels of assurance (LOAs), replaced by ordinals for individual parts of the digital identity flow, enabling implementers more flexibility in their design and operations." Likely means we need to rework the Security Labels for Trust Level of Assurance codes.
  • Thanks to Rene Spronk for this blog: Impact of the GDPR on the use of interoperability standards.
  • RE "In order to satisfy the Data portability requirement one has to know what information is subject to which explicit patient consent, and the information has to be either provided by the patient (e.g. quantified self, medical history) or has to be (in most general terms) an observation on the patient - this will require those specific data items to be labelled as such. If one isn't able to distinguish between this category of data and other data one will have no choice but to disclose all of it, and to do so in a machine-readable (i.e. using healthcare interoperability standards) format."
  • KC Comment: Could the limitations related to data portability discourage EU providers from use of Patient Generated Health Data [PGHD] since that would seem to eliminate their requirement to provide data portability? It may even limit interest in use of Health IoT [HIoT] especially if that's considered PGHD.
  • RE - Data Portability limitations wrt to healthcare information generated by providers
    • "The data portability right doesn’t apply when "processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services on the basis of Union or Member State law" (GDPR, Art. 9, para.2, point(h))
    • That's a rather wide ranging definition which greatly diminishes the value of the Data Portability right in healthcare. However, any processing or exchange of data which requires patient consent (e.g. most regional/national data exchanges, XDS/XCA implementations, clinical trial data) will be subject to the GDPR data portability right."
  • KC Comment: Interestingly, in the US, HIPAA Privacy Rule provisions for Patient Right of Access combined with the Meaningful Use View, Download, and Transmit EHR certification criteria does support data portability of much of the healthcare information that is excluded under GDPR. See Individuals’ Right under HIPAA to Access their Health Information 45 CFR § 164.524
  • Also: Could this encourage HIEs to be opt-out because consent would be avoided. It certainly limits applicability in US where most of the HIEs are moving to an opt-out model - and even with opt-out, that doesn't mean that the HIE stops collecting PHI - the excuse being that the opted out healthcare consumer may change their mind and the PHI is still available for break glass or emergency purposes of use as well as HIE analytic and public health reporting.
  • RE Rene's suggestion that "A label on an item of data that states "data subject to the Data Portability rights" would be useful for any 'downstream' processors of that data, for that specific data item would also be subject to the Data Portability right within a receiving application" could be done using the Security Label Category for Consent Directive types. It would require adding a new code to the ActConsentDirective code system during November Harmonization cycle.
  • June 5, 2017 NIST Privacy Risk Assessment Workshop Opening Session Video and NIST Privacy Risk Workshop slides related to NIST Internal Report 8062 "An Introduction to Privacy Engineering and Risk Management in Federal Systems"
  • Mid June, the Digital Commerce and Consumer Protection Subcommittee within the Energy and Commerce Committeeheld a series of hearings on Internet of Things, which touched on privacy and security challenges. See:
  • Reminder the SMART app specification (including their basic OAuth 2.0 profile) is available for review at https://github.com/smart-on-fhir/smart-on-fhir.github.io/tree/into-hl7
  • Please review and provide FMG comment by July 12 on FHIR Conformance QA Criteria. Requested comment areas: Are these criteria complete? Are there others we need? Are these criteria useful? Are there any of these we shouldn't be wasting our time on? Are these criteria reasonable? If you're going to be creating your own IGs and associated resources, would you be comfortable adhering to these criteria?

Minutes

  • Chaired by Kathleen
  • Agenda Approved
  • Approved Security WG Call Minutes June 13, 2017 and June 20, 2017 (Mike, John)
  • Review News and Reminders -
  • John Comment: 80063 had only one set level of assurances, which bound together by the level of assurances of identity, session, and the strength of federation into one level of assurance
    • the level of assurances have been separated in the new release of 80063 provision to review separately
    • Kathleen Comment: Security Labels and Trust Level of assurance are still being reviewed by Kathleen
  • Mike comment on Release of 80063:
    • Applicable to federal agencies
    • FHA will be convening a work group for federal partners
    • FHA work group will review the implications of 863 and provide guidance to federal agencies on how to interpret it
  • Notes of News by Kathleen:

Thanks John for pointing out the "major change" NIST Launches New Special Publication (SP) 800-63 Suite!. RE: "Gone are the days of levels of assurance (LOAs), replaced by ordinals for individual parts of the digital identity flow, enabling implementers more flexibility in their design and operations." Likely means we need to rework the Security Labels for Trust Level of Assurance codes. Thanks to Rene Spronk for this blog: Impact of the GDPR on the use of interoperability standards. RE "In order to satisfy the Data portability requirement one has to know what information is subject to which explicit patient consent, and the information has to be either provided by the patient (e.g. quantified self, medical history) or has to be (in most general terms) an observation on the patient - this will require those specific data items to be labelled as such. If one isn't able to distinguish between this category of data and other data one will have no choice but to disclose all of it, and to do so in a machine-readable (i.e. using healthcare interoperability standards) format." KC Comment: Could the limitations related to data portability discourage EU providers from use of Patient Generated Health Data [PGHD] since that would seem to eliminate their requirement to provide data portability? It may even limit interest in use of Health IoT [HIoT] especially if that's considered PGHD. RE - Data Portability limitations wrt to healthcare information generated by providers "The data portability right doesn’t apply when "processing is necessary for the purposes of preventive or occupational medicine, for the assessment of the working capacity of the employee, medical diagnosis, the provision of health or social care or treatment or the management of health or social care systems and services on the basis of Union or Member State law" (GDPR, Art. 9, para.2, point(h)) That's a rather wide ranging definition which greatly diminishes the value of the Data Portability right in healthcare. However, any processing or exchange of data which requires patient consent (e.g. most regional/national data exchanges, XDS/XCA implementations, clinical trial data) will be subject to the GDPR data portability right." KC Comment: Interestingly, in the US, HIPAA Privacy Rule provisions for Patient Right of Access combined with the Meaningful Use View, Download, and Transmit EHR certification criteria does support data portability of much of the healthcare information that is excluded under GDPR. See Individuals’ Right under HIPAA to Access their Health Information 45 CFR § 164.524 Also: Could this encourage HIEs to be opt-out because consent would be avoided. It certainly limits applicability in US where most of the HIEs are moving to an opt-out model - and even with opt-out, that doesn't mean that the HIE stops collecting PHI - the excuse being that the opted out healthcare consumer may change their mind and the PHI is still available for break glass or emergency purposes of use as well as HIE analytic and public health reporting. RE Rene's suggestion that "A label on an item of data that states "data subject to the Data Portability rights" would be useful for any 'downstream' processors of that data, for that specific data item would also be subject to the Data Portability right within a receiving application" could be done using the Security Label Category for Consent Directive types. It would require adding a new code to the ActConsentDirective code system during November Harmonization cycle. June 5, 2017 NIST Privacy Risk Assessment Workshop Opening Session Video and NIST Privacy Risk Workshop slides related to NIST Internal Report 8062 "An Introduction to Privacy Engineering and Risk Management in Federal Systems" Mid June, the Digital Commerce and Consumer Protection Subcommittee within the Energy and Commerce Committeeheld a series of hearings on Internet of Things, which touched on privacy and security challenges. See: Series: Update on IOT Opportunities and Challenges VIDEO RECAP: IoT Showcase Reminder the SMART app specification (including their basic OAuth 2.0 profile) is available for review at https://github.com/smart-on-fhir/smart-on-fhir.github.io/tree/into-hl7 Please review and provide FMG comment by July 12 on FHIR Conformance QA Criteria. Requested comment areas: Are these criteria complete? Are there others we need? Are these criteria useful? Are there any of these we shouldn't be wasting our time on? Are these criteria reasonable? If you're going to be creating your own IGs and associated resources, would you be comfortable adhering to these criteria?

  • July Harmonization Proposal QA Review and Request for approval of initial submission see *July 2017
    • E-vote will be sent out prior to July 7th submission
    • on 2017-06-30 an Evote was sent out
    • All outstanding QA issues have now been resolved .
    • David Pyke, Jim Kretz, Trish Williams approved final Security WG July Harmonization proposals
Retrieved from "https://wiki.hl7.org/w/index.php?title=June_27,_2017_Security_Conference_Call&oldid=142862"