1. Notice of Proposed Rulemaking (NPRM) Comments Privacy and Security Workgroup Deven McGraw, Chair Stan Crosley, Co-Chair April 20, 2015

2. Agenda Recap: Presentation to the HIT Policy Committee Notice of Proposed Rulemaking (NPRM) Discussion 1

3. Privacy and Security Draft Workplan 2 MeetingsTask ✓ HITPC Meeting April 7, 2015 Interoperability Roadmap comments to the HITPC April 20, 2015 NPRM Discussion April 27, 2015 MU Stage 3 NPRM Discussion May 1, 2015 Finalize Comments May 12, 2015 HITPC Meeting Certification NPRM Comments

4. Recap: Presentation to the Health IT Policy Committee 3

5. Recap: Presentation to the HITPC 4 Comments well received by HITPC One concern  patient’s ability to require a provider to share health information with a third party for treatment purposes – Case of unreliable or nefarious app provider; potential security and IT performance issues Clarifications: – Comment re: patient requiring provider to share remains unchanged; discussions with OCR – “Authorization” changed to “have authority to” – Please submit final thoughts by 4/22

6. Notice of Proposed Rulemaking (NPRM) 5

7. NPRM Assignments Data Segmentation for Privacy (DS4P) Pharmacogenomics Data MU3 NPRM pp. 128-136, 390 §170.315(b)(7) / §170.315(b)(8) Comment on whether the PSWG agrees with ONC’s proposal; specifically, that DS4P send and receive technology should be part of the 2015 certification criteria, as described in the NPRM pp. 236-240 Comment on some of the questions in the bulleted list that begins on p. 239 Review proposed Objective 1 (Protect Patient Health Information), pp. 60- 67) Ramifications of increased patient access to data 6

8. Draft PSWG NPRM Workplan 7 MeetingsTask April 20, 2015 2:30-4:30pm ET Certification NPRM Data Segmentation for Privacy (DS4P) Pharmacogenomics Data April 27, 2015 12:00-1:30pm ET MU3 NPRM Objective 1: Protect Patient Health Information Ramifications of increased patient access to data May 1, 2015 10:00-11:30am ET NPRM Finalization Finalize comments May 12, 2015 HITPC Meeting Certification NPRM Comments

9. Data Segmentation for Privacy (DS4P) 8

10. ONC proposes to adopt two new certification criteria that would focus on the capability to separately track (“segment”) documents that contain sensitive health information – Data Segmentation for Privacy: Send – Data Segmentation for Privacy: Receive Use of HL7 standard Not part of Base EHR (providers not required to purchase it) 9

11. Data Segmentation for Privacy (DS4P) Data segmentation describes the electronic labeling or tagging of health information that allows patients or providers to electronically share parts, but not all, of a patient record DS4P initiative and its pilots focused on the exchange of health information in the context of 42 CFR Part 2 (Part 2) Sought to develop technical standards to enable a provider to adopt health IT that can segment electronic sensitive health information and achieve compliance with laws like Part 2 10

12. DS4P: Discussions from March 30 PSWG Meeting Uncomfortable with sequestration at document level – Non-sensitive information is swept up in the document- level tag; exclusion from clinical decision support (CDS) system Desire for more information on the sequestered document – Viewing sequestered data does not preclude manual incorporation How will “sequestered” be data handled? – API capability to query for discrete data – Not sure where all “sensitive data” will be located  provider burden 11

13. DS4P Send Proposal: Technology must enable a user to create a summary record formatted in accordance with each of the standards adopted in § 170.205(a)(3) and (4) that is tagged as restricted and subject to restrictions on re-disclosure according to the standard adopted in § 170.205(o)(1). Straw Comments for Discussion: Tiger Team (PSWG) proposed two glide paths: Level 0: current state; exchange paper or fax Level 1: document level sequester Sender: send consolidated clinical document architecture (CCDA) tagged as restricted Ideally for MU 3, include level 1 send functionality in voluntary certification program for BH providers 12 Excerpt from 7/15/14 Transmittal Letter

14. DS4P Receive Proposal: Technology must enable a user to: (i)Receive a summary record that is tagged as restricted and subject to restrictions on re- disclosure according to the standard adopted in § 170.205(o)(1). (ii)Apply document-level tagging and sequester the document from other documents received. (iii)View the restricted document (or data), without incorporating the document (or data). Straw Comments for Discussion: Tiger Team (PSWG) proposed two glide paths: Level 0: current state; exchange paper or fax Level 1: document level sequester Recipient: receive and automatically recognize documents; able to view restricted CCDA or data element, but CCDA or data cannot be automatically parsed/consumed/inter-digitated into EHR (no CDS use) Ideally for MU 3, include level 1 receiver functionality in voluntary certification program for BH providers Ideally for MU 3, include level 1 receiver functionality as voluntary certification criterion for CEHRT 13 Excerpt from 7/15/14 Transmittal Letter

15. Data Segmentation for Privacy (DS4P) Proposed criteria are an initial step toward the ability of an interoperable health care system to compute and persist the applicable permitted access, use, or disclosure – Under state and federal laws, or individual choice Challenges: – Prevalence of unstructured data – Sensitive images – Use of sensitive information by CDS systems 14

16. Additional Recommendations from Tiger Team 15 Additional Comments: Additional pilots and guidance to clarify recipient response Education of providers and patients HITSC to address maturity/feasibility of DS4P or other standards for BH EHR and general EHR voluntary certification. If so, at what level of granularity? From 7/15/14 Transmittal Letter

17. Further Comments? Does the proposal comport with prior Tiger Team and Policy Committee recommendations on DS4P and EHR certification? Is there more we want to say here? 16

18. Pharmacogenomics Data 17

19. Pharmacogenomics Data Pharmacogenomics data: – Clinically significant genetic variants that alter metabolism and can affect drug interactions – Generally, not captured in structured manner (currently free text of PDF) – Several organizations are working on standards and other steps toward wider adoption – Health IT systems can use it to improve safety and outcomes through optimal drug choices and patient-specific dosing 18

20. Pharmacogenomics Data ONC welcomes input on: – Factors to consider for health IT to allow use or disclosure of genetic information that complies with federal and state privacy laws – Leverage the proposed Data Segmentation for Privacy (DS4P) certification criteria for segmenting genetic information? – Balance patient benefit with avoiding discrimination 5 specific questions deal with privacy and security (10 questions overall on this issue) 19

21. Privacy & Security–related Questions 1.Should ONC offer certification for health IT functionality that could facilitate HIPAA- compliant sharing of discrete elements of a patient’s genomic information from their record to the family history section of a relative’s record? 2.Does the proposed ‘data segmentation for privacy’ criteria provide needed health IT functions with respect to the storage, use, transmission, and disclosure of genetic, genomic, and pharmacogenomics information that is subject to protections under HIPAA and additional state and federal privacy and protection laws such as the Genetic Information Nondiscrimination Act (GINA)? 20

22. Privacy & Security–related Questions 3.Do the proposed ‘data segmentation for privacy’ criteria adequately balance complex genetic privacy issues, such as those related to behavioral health, with the clinical value of context-appropriate availability of a patient’s actionable genetic and genomic information? 4.Should Health IT be required to apply different rules for the use and exchange of genetic, genome, and pharmacogenomics data based on different groupings of diseases or conditions based on the sensitivity of the information, such as those related to behavioral health? 5.What other factors should be considered for health IT that allows the user to use or disclose genetic information in a manner compliant with federal and state privacy laws? 21

23. Discussion Most states have laws protecting genetic information – e.g., requiring consent to collect and/or disclose (although some have exceptions for treatment disclosures) - http://www.ncsl.org/research/health/genetic-privacy- laws.aspx (from 2008). GINA (and HIPAA modifications due to GINA) prohibit collection/use by employers and payors for certain purposes Under HIPAA – “treatment” is defined as treatment of “a patient” Redisclosure prohibitions? (depends on state law and jurisdiction) 22

24. Discussion DS4P provides document-level segmentation – appropriate for this context? What other protections (for example, FIPPs) are recommended for this use case? Consequences of failure to collect/use this information? What other recommendations – – Education of providers & patients? – Guidance on law? 23

25. Backup Slides 24

26. Readiness Evaluation and Classification Criteria for Technical Specifications Emerging Standards Pilots National Standards Adoptability Maturity Low Moderate High Maturity Criteria: Maturity of Specification Maturity of Underlying Technology Components Market Adoption Adoptability Criteria: Ease of Implementation and Deployment Ease of Operations Intellectual Property Source: http://jamia.oxfordjournals.org/content/jaminfo/early/2014/12/17/amiaj nl-2014-002802.full.pdf?%2520ijkey=8oAq1ZTZyQ6edqC&keytype=ref http://jamia.oxfordjournals.org/content/jaminfo/early/2014/12/17/amiaj nl-2014-002802.full.pdf?%2520ijkey=8oAq1ZTZyQ6edqC&keytype=ref The Metrics the HITSC has adopted for helping to determine when a technology specification is ready to become a national standard.

27. Pharmacogenomics Data: Discussions from March 30 PSWG Meeting Incorporating pharmacogenomics data in the 2015 Edition seems to be premature Viable companies are already providing genomic data as a service to doctors – Data does not reside in an EHR – Becoming a “black box” to the EHR vendor Family history remains a powerful indicator; research/evidence on improved safety and outcomes using genomic data is still developing EHRs unlikely to provide complete genomic data; instead, high-level summaries may be available as certain profiles become available 26

28. Pharmacogenomics Data: Non P&S Related Questions 27 1.Should the 2015 Edition “medication allergy list” certification criterion include the capability to integrate genotype-based drug metabolizer rate information? 2.Should the 2015 Edition “drug-drug, drug-allergy interactions checks for CPOE” certification criterion or as a separate certification criterion include pharmacogenomic CDS for “drug-genome interactions”? 3.Should ONC offer 2015 Edition certification for CDS that incorporate a patient’s pharmacogenomic genotype data into the CPOE prescribing process with the goal of avoiding adverse prescribing outcomes for known drug-genotype interactions? 4.Are there certification approaches that could enhance the end-user’s (provider’s) adoption and continued use of health IT implementations that guide prescribing through CDS using pharmacogenomic data? 5.Are there existing or developing standards applicable to the capture, storage, display, and exchange of potentially clinically relevant genomic data, including the pharmacogenomic subset?

29. Examples of Privacy Risks to Genomic Information What can be revealed if data is compromised? Association/propensity with certain diseases Identification (e.g., forensics, ethnicity) Revelation of family relationships Threats: Re-identification Phenotype inference Potential for legal and forensic abuse 28 Source: Privacy and Security in the Genomic Era: http://arxiv.org/pdf/1405.1891v1.pdfhttp://arxiv.org/pdf/1405.1891v1.pdf