Notice of Proposed Rulemaking (NPRM) Comments Privacy and Security Workgroup Deven McGraw, chair Stan Crosley, co-chair May 1, 2015

Agenda Presentation: DS4P Criteria Finalize Comments on the 2015 Edition Health IT Certification Criterion NPRM and the Meaningful Use Stage 3 NPRM 1

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

Presentation: DS4P ONC team has been invited to speak about the DS4P criteria. Sample questions raised during 4/20 Meeting: – The HITPC recommended that only the DS4P Receive certified technology be able to receive and view data from the DS4P Send technology. How is this technically implemented? – How does a DS4P Send technology know where to send the segmented data? – Can a DS4P Send certified technology send segmented data to a provider that does not have the technology to view the data? If so, how is the sending provider alerted? – What happens to the data after the receiving provider views the data? Presenters: Johnathan Coleman and Julie Chua 3

NPRM Assignments Health IT Certification NPRM Meaningful Use (MU) Stage 3 NPRM DS4P (Send and Receive) Pharmacogenomics Data Objective 1 (Protect Patient Health Information) Ramifications of privacy and security issues related to increased patient access to data 4

Straw Comment for Discussion Certification: DS4P – Send The P&S Workgroup generally agrees that the proposed the DS4P Send criterion is an important first step toward enabling the exchange of information covered by Part 2. The Workgroup supports the NPRM proposal to require “DS4P send” be part of certification but NOT part of the mandatory Base EHR definition. 5

Straw Comment for Discussion Certification: DS4P – Receive The Workgroup favors having “DS4P-receive” be certified but not part of the Base EHR. – If part of certification, educate providers about the features and limits of the technology. Areas of Concern: – Obligations for DS4P-receive provider who do not want to receive the information digitally. – Document level sequestration, with read-only capability. – Uncertainties about manual entry of similar data received directly from a patient. – Uncertainties about whether DS4P-receive would enable complying with other sensitive data laws that may not include prohibitions on re- disclosure. – Incomplete electronic medical records due to patient withholding data. 6

Straw Comment for Discussion Certification: Pharmacogenomics Data 7 The P&S WG concludes that introducing certification for this functionality in the 2015 Edition is premature. – ONC should to continue to review issues around accessing, sharing, and using pharmacogenomics data as the science evolves. Response to Comments Sought: – Apply different rules for the use and exchange of pharmacogenomics data, such as those related to behavioral health? Strongly cautions ONC from promoting policies that require higher or more complex protection than what is provided for in current law. – Does DS4P provide needed health IT functions on the storage, use, transmission, and disclosure of pharmacogenomics information? The proposed DS4P is not useful for providers to comply with more sensitive laws governing pharmacogenomics data. DS4P does not support key use cases (not able to use decision-support software).

Straw Comment for Discussion MU 3: Objective 1 - Protect Patient Health Information The Workgroup supports the proposed MU Stage 3 security requirements. Adding administrative and physical safeguards to the current requirements more closely aligns the CEHRT risk assessments and attestations with the compliance requirements of the HIPAA Security Rule. 8

Straw Comment for Discussion MU 3: Ramifications on privacy and security issues related to increasing patient access to data (i.e., VDT, APIs) The Workgroup supports the proposal to increase the opportunities for patient access to information through the use of VDT technologies as well as open API. However, the Workgroup has concerns about potential privacy and security risks associated with increasing patient access to health information electronically. 9

Straw Comment for Discussion MU 3: Ramifications on privacy and security issues related to increasing patient access to data Recommendations: – ONC and CMS should reference and leverage appropriate previous recommendations on best practices for view and download. – ONC should continue to work with FTC and OCR to develop guidance for key stakeholders to adopt the use of mobile IT, apps, and APIs. – ONC and OCR to produce educational materials for both patients and providers on the safe use of apps and API. – Reference prior recommendations on identity proofing and authentication of patients, family members, friends and personal representatives. 10

Straw Comment for Discussion MU 3: Ramifications on privacy and security issues related to increasing patient access to data (i.e., VDT, APIs) Recommendations (cont.): – ONC and OCR should issue guidance addressing the intersection between the MU patient engagement objectives, the certification requirements, and HIPAA’s patient access rights. the extent to which a provider may reject a patient’s request for electronic access due to a perceived security risk for the provider; the extent to which a provider may reject a patient’s request for electronic access in the absence of a security risk; the ability of provider’s to charge fees for meaningful use access. – Voluntary effort to “certify” patient-facing health apps to help patients choose apps. ONC and other federal agencies could advise such an initiative, particularly around privacy and security policies and help facilitate greater standardization. 11

Backup Slides 12

Data Segmentation for Privacy (DS4P) Update HIMSS 2015 Lucia Savage, JD Chief Privacy Officer

Outline of Topics Need for Data Segmentation 14 Challenges with Data Segmentation Technical Approach Way Forward and Conclusion

NEED FOR DATA SEGMENTATION Data Segmentation for Privacy 15

The Need for Data Segmentation HIPAA Privacy Rule allows health care providers to disclose protected health information without patient consent for treatment, payment and health care operations purposes. HIPAA leaves in place other state and federal privacy laws that are more protective. Some state and federal privacy laws which address social hostility and stigma associated with certain medical conditions, require consent to disclose information beyond that required by HIPAA.* *See Additional Resources included in the Interoperability Roadmap interoperability-roadmap-draft-version-1.0.pdf interoperability-roadmap-draft-version-1.0.pdf 16 Why Segment Data?

Examples of Heightened Legal Privacy Protections 42 CFR Part 2: Federal Confidentiality of Alcohol and Drug Abuse Patient Records regulations protect specific health information from exchange without patient consent. Title 38, Section 7332, USC: Laws protecting certain types of health data coming from covered Department of Veterans Affairs facilities and programs. Types of data include sickle cell anemia, HIV, and substance abuse information. 45 CFR § (a)(1)(iv): Effective 3/26/2013, this final rule describes how patients may withhold any health information from health plans for services they received and paid for out-of-pocket.* 17 * Patient, not provider, has responsibility for ensuring that downstream recipients know that patient is requesting restriction.

Why is this important? An estimated 26% of Americans age 18 and older are living with a mental health disorder in any given year. 46% of Americans will have a mental health disorder over the course of their lifetime. An estimated 8% of Americans are in need of drug or alcohol abuse treatment. Patients suffering from serious mental illness have increased rates of co-occurring conditions, which results in a reduced life expectancy of 8-17 years. Of 50 states, an estimated 18 states have rules regarding mental health data that are more privacy protective than HIPAA; an estimated 17 states have similar rules that are specific to drug or alcohol abuse (not Part 2 rules) CMS CMMI State Innovation Model Round 2 has awarded over $1.2 billion million to states to test and/or implement new models of care delivery, including those that integrate behavioral and physical health. easeDatabase/Fact-sheets/2014-Fact- sheets-items/ html easeDatabase/Fact-sheets/2014-Fact- sheets-items/ html 18

“WE HAVE THE TECHNOLOGY…” AKA “IT’S THE RULES…” Data Segmentation for Privacy 19

20 or Laws, regulations, and policies for patient consent Laws, regulations, and policies for sensitive information Consent models (opt-in, opt-out, with restrictions, etc.) HIO/HIE Architecture EHR system interoperability Consent directive (paper/electronic) Patient provides consent to share sensitive health information and HIPAA Permitted Uses and Disclosures Current U.S. Privacy Rules Environment

D.C. Code § Definitions District of Columbia Official Code—Division I. Government of District—Title 7. Human Health Care and Safety— Subtitle C. Mental Health—Chapter 12. Mental Health Information—Subchapter I. Definitions; General provisions Mental health information means any written, recorded or oral information acquired by a mental health professional in attending a client in a professional capacity which: (A) Indicates the identity of a client; and (B) Relates to the diagnosis or treatment of a client’s mental or emotional condition. N.C. Gen. Stat. § 122C-3 Definitions General Statues of North Carolina—Chapter 122C. Mental Health, Developmental Disabilities, and Substance Abuse Act of 1985—Article I. General Provisions Confidential information means any information, whether recorded or not, relating to an individual served by a facility that was received in connection with the performance of any function of the facility. Confidential information does not include statistical information from reports and records or information regarding treatment or services which is shared for training, treatment, habilitation, or monitoring purposes that does not identify clients either directly or by reference to publicly known or available information. 21 Sample State Definitions of Mental Health Information (for Disclosure Purposes)

States philosophically aligned State privacy and consent laws are diverse in content Diversity in organizational policies within states See roadmap appendix A and B for ONC Consent Bibliography Current State Law Environment 22

ABOUT THAT TECHNOLOGY... AKA DATA SEGMENTATION CHALLENGES Data Segmentation for Privacy 23

DS4P was tested on substance abuse information (for example, 42 CFR Part 2 data) where the category of special protection derives from the facility where the care is supplied – 42 CFR Part 2 (Part 2) is a federal law and does not change across state lines – 42 CFR Part 2 protect adheres to care supplied in buildings covered by that regulation and the statute it derives from DS4P can therefore recognize that a provider applied special protections because of the physical source of the data; – Therefore, segmentation can be based on the building (facility type codes) 24 DS4P Standards: What can DS4P do? For example, in a Part 2 covered facility, a physician may track a patient’s blood pressure. Although this data might not be specially protected otherwise, it is specially protected because the care is supplied in a Part 2 covered facility.

What about segmentation necessary due to the clinical nature of the data (not a location)? There are 8 basic categories of special privacy protections due to clinical nature, not necessarily where care was provided – HIV/AIDS; Drug/Alcohol Abuse (not Part 2), Mental Health/Behavioral Health; Reproductive Health of Women; Genetic Information (not GINA); STD; Teen Health Information; Domestic Violence health information. DS4P might be effective if there was harmonization between legal definitions of what is protected and medical codes (e.g. ICD10). Harmony is lacking: Example: in a PCP office, some collected information is specially protected, such as evidence that a Chlamydia test occurred, while other information is not. All care occurs in the same place. Even if a disclosing system segments data, the receiving system may not be able to recognize that segmentation (more later). DS4P Standards: What are DS4P Limits? 25

Technical standards can help organizations implement policy, but first the policy must support the use of the technical standards. Currently, although state law is philosophically aligned, it is not harmonized, so nationwide mapping to code sets has not taken root. Lack of harmony may: – Exaggerate privacy concerns because of confusion. – Undermine potential business cases for interoperable information exchange. – Foster skepticism about the ability of information exchange to deliver comprehensive data. 26 DS4P Standards: What does this tell us?

DS4P Standards: How it Works Separating Policy from Technical Capability The DS4P standard enables interoperability and provides a capability to support existing privacy law, including federal, state, and local laws The standard uses document level tagging as the mechanism to convey confidentiality levels and obligations, but also specifies how to be more granular (e.g. sections or entries inside the document) Depends if the implementing (sending or receiving) system can support it 27

Laws tell data-holders not to disclose; law rarely tells them what to say about that non-disclosure. For example: – HIV Status: **Redacted** This is a likely indicator that the patient has a test result –if the applicable law protects results of tests, not occurrences, this may indicate a positive result; or –HIV Status: **No data available** This is may be misleading for a physician, who may then make a health decision for the patient without knowing important details that could lead to safety issues. –HIV Status: [record is silent] This is ambiguous. The recipient does not know if there was a redaction, or no data is available. 28 Policy Challenges

How to Segment: There are multiple levels at which segmentation could occur, such as: –Type of Data category of data - e.g. medications, diagnostic codes, etc. –Clinical category of code of whatever type –Disclosing provider –Intended recipient –Facility type (e.g. Part 2 clinic) Structured vs unstructured Data: Prevalence of free-text complicates identification of data that is subject to enhanced protection. Things to Solve 29

Things to Solve Granularity: Should data be segmented: – At the “whole document” level? – For parts of a document? – According to clinical nature within the document? Standardized mapping of specially protected categories to codes would make segmentation more predictable: – For individuals through standard understanding – For providers through standard expectations – For developers, with less confusion about what law requires Currently, not every receiving system can understand 42 CFR Part 2 segmented data, i.e., their system does not recognize that it is receiving data that is subject to heightened protections based on Part 2 law. 30

TECHNICAL APPROACH Data Segmentation for Privacy Initiative 31

 The Patient receives care at their local hospital for a variety of conditions, including substance abuse as part of an Alcohol/Drug Abuse Treatment Program (ADATP).  Data requiring additional protection and consent directive are captured and recorded. The patient is advised that the protected information will not be shared without their written authorization. User Story Example (1) 32

 A clinical workflow event triggers additional data to be sent to Provider/Organization 2. This disclosure has been authorized by the patient, so the data requiring heightened protection is sent along with a prohibition on redisclosure.  Provider/ Organization 2 electronically receives and incorporates patient additionally protected data, data annotations, and prohibition on redisclosure. User Story Example (2) 33

Technical Approach Types of Privacy Metadata used by DS4P 34 Confidentiality Codes: – Used by systems to help convey or enforce rules regarding access to data requiring enhanced protection. Uses “highest watermark” approach. Purpose of Use: – Defines the allowed purposes for the disclosure (e.g. Treatment, Emergency Treatment etc). Obligations: – Refrain Codes: Specific obligations being placed on the receiving system (e.g. do not re-disclose without consent)

DS4P Implementation Guide HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 Voted on and approved at the highest level, to become what HL7 calls a “normative” standard, and has also received ANSI (American National Standards Institute) accreditation. The standard uses vocabularies to convey specific meanings, such as “Do not re-disclose without consent” or “This document is restricted”. 35

36 STANDARD: HL7 Implementation Guide: Data Segmentation for Privacy (DS4P), Release 1 (Includes Content Profile, Profile for Direct, Profile for exchange) Capability Standards/Profiles used by the HL7 DS4P R1 Standard Specific Usage Metadata Vocabularies (for Transport and/or Document Metadata) HL7 RefrainPolicy Conveys specific prohibitions on the use of disclosed health information (e.g. prohibition of redisclosure without consent) HL7 PurposeofUse Conveys the purpose of the disclosure of health information (e.g. treatment, research, emergency) HL7 BasicConfidentialityCodeKind Used to represent confidentiality codes associated with disclosed health information (e.g. restricted) as specified in the HL7 Healthcare Security Classification standard (HCS). HL7 ObligationCode Used to convey specific obligations associated with disclosed health information (e.g. encryption) HL7 ActPolicyType Used to convey a type of policy HL7 SensitivityPrivacyPolicy Used to convey the sensitivity level of a specific policy Selected Standards

37 Other Standards Referenced by the HL7 DS4P Standard: CapabilityStandard/ProfileSpecific Usage Patient Consent Structure HL7 Implementation Guide for CDA®, Release 2: Consent Directives, Release 1 (DSTU) Provides representations for expressing privacy preferences and exchanging privacy policies that can be enforced by consuming systems TransportSOAP Transport-level security TransportSMTP and S/MIME S/MIME attributes are bound to SMTP to provide for the use of secure as the transport mechanism for exchanging patient data Conveying Identity - Cross-Enterprise User Assertion (XUA) - OASIS SAML Specification Version 2.0 IHE XUA Metadata SAML Assertion (SAML Request and Response) Conveying IdentityX.509 Digital CertificatesPKI to support Direct implementations Selected Standards

38 Evolving to Interoperability Roadmap: Framing Consent/Patient Choice Strategy Variation in rules about permission to access, use or disclose makes it difficult to build software systems that accurately capture, maintain, and persist this data. But we need software systems to capture and persist both written individual directions and what is permitted without a written individual direction. Consent ManagementComputable Privacy

CONCLUSION Data Segmentation for Privacy Initiative 39

Conclusion While DS4P can clearly be used, we need to strengthen the standards so that the consent of the patient as required by law can be carried forward. The DS4P pilots give optimism. And, at the same time, policy needs to be harmonized to take full advantage of DS4P. Improving health outcomes for individuals with complex, comorbid conditions depends on the twin goals of: – Efficient, nationwide standards by which individuals can ensure that their specially protected health information flows where they need it to for care. – Appropriate standard controls to respect the privacy of individuals who do not want their specially protected data to flow. How to achieve goals: See Interoperability Road Map 40

QUESTIONS? Data Segmentation for Privacy Initiative 41