Draft – discussion only Consumer Workgroup STAGE 3 Meaningful Use & 2015 VDT Certification NPRM Review Christine Bechtel, chair April 28, 2015

Consumer Workgroup Members Christine Bechtel, Bechtel Health Advisory Group (Chair) Dana Alexander, Caradigm Leslie Kelly Hall, Healthwise Ivor Horn, Seattle Children’s Erin Mackay, National Partnership for Women & Families Philip Marshall, Conversa Health Amy Berman/Wally Patarawan, The John A. Hartford Foundation Will Rice, Walgreens/Take Care Health Systems Clarke Ross, Consortium for Citizens with Disabilities; American Association on Health and Disability Luis Belen, National Health IT Collaborative for the Underserved Kim Schofield, Lupus Foundation of America (GA Chapter) Program for CDC MaryAnne Sterling, Patient & Caregiver Advocate Nicholas Terry, Indiana University, Robert H. McKinney School of Law Ex Officio Members Cynthia Baur, HHS, CDC Teresa Zayas Caban, HHS, AHRQ Danielle Tarino, HHS, SAMHSA Theresa Hancock, Veterans Affairs Bradford Hesse, HHS, NIH Wendy J. Nilsen, HHS, NIH ONC Staff Chitra Mohla, Office of Policy (Lead WG Staff) 2

3 Agenda I.API Questions and Answers II.Review Objective 5 of Stage 3 of the Medicare & Medicaid Electronic Health Record (EHR) Incentive Program III.Review VDT certification criteria in the 2015 Certification NPRM

API Questions What does it look like when a patient downloads data in regard to privacy & security, data segmentation or computable consent? – What legal framework governs the data that sits in an app? Is there a baseline set of functions that we should be pushing for? From API perspective in stage 3 there are certain requirements – certified, secure. What API calls are available; push for certain minimum number. – Are there still HIPAA logs – if one wanted to see flow of information as you can do in an EHR, are they still able to see who is receiving their info and if there was a breach to have ability to see where breach may have gone. 4

API Questions By choosing one API or another does that limit me to certain apps? How does provider know that the person with the app is the patient? 5

Objective 5: Patient Electronic Access to Health Information 6 Objective: Provide electronic or API access to health information and educational resources. Must meet all measures. MEASURE 1: For > 80% of unique patients, patient provided access to health information within 24 hours of availability 1)Using patient portal 2)Using an ONC-certified API used by 3 rd party app or device MEASURE 2: Use CEHRT to identify patient-specific educational resources & provide electronic access to those material >35% of unique patients Exclusion: EP with no office visits. EP/EH in area with insufficient broadband

Proposed Measure 1 7 MEASURE 1: For > 80% of unique patients, patient provided access to health information within 24 hours of availability To calculate the percentage To calculate the percentage: DenominatorThe number of unique patients seen by the EP or the number of unique patients discharged from an eligible hospital or CAH inpatient or emergency department (POS 21 or 23) during the EHR reporting period. NumeratorThe number of patients in the denominator who are provided access to information within 24 hours of its availability to the EP or eligible hospital/CAH. ThresholdThe resulting percentage must be more than 80 percent in order for a provider to meet this measure. ExclusionAn EP may exclude from the measure if they have no office visits during the reporting period

Request for Comment What additional requirements might be needed to ensure that if the eligible hospital, CAH or EP selects the API option— 1.the functionality supports a patient’s right to have his or her protected health sent directly to a third party designated by the patient; and 2.Patients have at least the same access to and use of their health information that they have under view, download and transmit option. 8

Request for Comment on Alternates to Proposed Measure 1 Proposed: Patient or patient authorized representative is provided access to view online and transmit their health within 24 hours of availability to the provider; or the patient or patient authorized representative is provided access to an ONC-certified API that can be used by third- party applications or devices to provide access to their health information within 24 hours Alternate A Patient or patient authorized representative is provided access to view online and transmit their health within 24 hours of availability to the provider; and the patient or patient authorized representative is provided access to an ONC-certified API that can be used by third- party applications or devices to provide access to their health information within 24 hours Alternate B Patient and patient authorized representative is provided access to view online and transmit their health within 24 hours of availability to the provider; or the patient or patient authorized representative is provided access to an ONC-certified API that can be used by third- party applications or devices to provide access to their health information within 24 hours Alternate C the patient or patient authorized representative is provided access to an ONC-certified API that can be used by third- party applications or devices to provide access to their health information within 24 hours 9 For > 80% of all unique patients seen by EP or discharged from EH, CAH inpatient or ER

Request for Comment on Alternate Proposals Providers to Meet Measure 1 (pp ) Current VDT functions are widely in use and represent current standards for patient access. 1. Alternate A would require both functions to be available instead of allowing the provider to choose between the two; 2. Alternate B would require the provider to choose to have either both functions, or just an API function; and 3. Alternate C would require the provider to only have the API function. For Alternate C, the use of a separate view, download, and transmit function would be entirely at the provider's discretion and not included as part of the definition of meaningful use. Questions: - Whether these two technologies (portal and API) be optional or both required - If API is required, should still be required to offer a portal? - Problems with measuring patient access using an API rather than a portal? 10

Request for Comment on Exclusion Comment on Exclusion 1. Whether an exclusion is still appropriate for providers located in counties with <50% of housing having 4Mbps broadband 2. Whether to create exclusion for EPs having no office visits 11

Patient-Specific Education Materials MEASURE 2: Use CEHRT to identify patient-specific educational resources & provide electronic access to those material >35% of unique patients (Stage 2 was 10%) 12 To calculate percentage: DenominatorThe number of unique patients seen by the EP or the number of unique patients discharged from an EH or CAH inpatient or ED during EHR Reporting period NumeratorThe number of patients in the denominator who were provided electronic access to patient-specific educational resources using clinically relevant information identified by the CEHRT ThresholdThe resulting percentage must be more than 35% in order for the provider to meet the measure ExclusionsAn EP may exclude from the measure if they have no office visits during the EHR reporting period

2015 Edition Proposed Rule Health IT Certification Criteria Review VDT certification criteria in 2015 Certification NPRM ( Reference VDT certification document) Addressing Health Disparities 13

2015 Edition Certification Criteria for VDT Stage 3 MU Proposed Objective “The EP, eligible hospital, or CAH provides access for patients to view online, download, and transmit their health information, or retrieve their health information through an API, within 24 hours of its availability.” 14

2015 Health IT Certification Criteria (1) View, download, and transmit to 3rd party. (i) Patients (and their authorized representatives) must be able to use technology to view, download, and transmit their health information to a 3rd party in the manner specified below. Access to these capabilities must be online and through a secure channel that ensures all content is encrypted and integrity protected in accordance with the standard for encryption and hashing algorithms specified at § (f). 15

View (A) Patients (and their authorized representatives) must be able to use health IT to view in accordance with the standard adopted at § (a)(1), at a minimum, the following data: (1) The Common Clinical Data Set (which should be in their English (i.e., non- coded) representation if they associate with a vocabulary/code set). (2) Ambulatory setting only. Provider's name and office contact information. (3) Inpatient setting only. Admission and discharge dates and locations; discharge instructions; and reason(s) for hospitalization. (4) Laboratory test report(s). Laboratory test report(s), including: (i) The information for a test report as specified all the data specified in 42 CFR (c)(1) through (7); (ii) The information related to reference intervals or normal values as specified in 42 CFR (d); and (iii) The information for corrected reports as specified in 42 CFR (k)(2). (5) Diagnostic image report(s). 16

Download “(1) Patients (and their authorized representatives) must be able to use technology to download an ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) in only human readable format, in only the format specified in accordance to the standard adopted at § (a)(4), or in both formats. The use of the “unstructured document” document-level template is prohibited for compliance with the standard adopted at § (a)(4). (2) When downloaded according to the standard adopted at § (a)(4), the ambulatory summary or inpatient summary must include, at a minimum, the following data (which, for the human readable version, should be in their English representation if they associate with a vocabulary/code set): (i) Ambulatory setting only. All of the data specified in paragraph (e)(1)(i)(A)(1), (2), (4), and (5) of this section. (ii) Inpatient setting only. All of the data specified in paragraphs (e)(1)(i)(A)(1), and (3) through (5) of this section. (3) Inpatient setting only. Patients (and their authorized representatives) must be able to download transition of care/referral summaries that were created as a result of a transition of care (pursuant to the capability expressed in the certification criterion adopted at paragraph (b)(1) of this section).” 17

Transmit (C) Transmit to third party. Patients (and their authorized representatives) must be able to: (1) Transmit the ambulatory summary or inpatient summary (as applicable to the health IT setting for which certification is requested) created in paragraph (e)(1)(i)(B)(2) of this section in accordance with at least one of the following: (i) The standard specified in § (a). (ii) Through a method that conforms to the standard specified at § (d) and leads to such summary being processed by a service that has implemented the standard specified in § (a). (2) Inpatient setting only. Transmit transition of care/referral summaries (as a result of a transition of care/referral) selected by the patient (or their authorized representative) in accordance with at least one of the following: (i) The standard specified in § (a). (ii) Through a method that conforms to the standard specified at § (d) and leads to such summary being processed by a service that has implemented the standard specified in § (a). 18

Activity history log (A) When electronic health information is viewed, downloaded, or transmitted to a third-party using the capabilities included in paragraphs (e)(1)(i)(A) through (C) of this section or when an application requests electronic health information using the capability specified at paragraph (e)(1)(iii) of this section, the following information must be recorded and made accessible to the patient: (1) The action(s) (i.e., view, download, transmission, API response) that occurred; (2) The date and time each action occurred in accordance with the standard specified at § (g); (3) The user who took the action; and (4) Where applicable, the addressee to whom an ambulatory summary or inpatient summary was transmitted. (B) Technology presented for certification may demonstrate compliance with paragraph (e)(1)(ii)(A) of this section if it is also certified to the certification criterion adopted at § (d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) is accessible by the patient. 19

Application Access [via an Application Programing Interface] (1 of 2) Patients (and their authorized representatives) must be able to use an application that can interact with the following capabilities. Additionally, the following technical outcomes and conditions must be met through the demonstration of an application programming interface (API) that can respond to requests from other applications for data specified within the Common Clinical Data Set. (A) Security. The API must include a means to establish a trusted connection with the application requesting patient data, including a means for the requesting application to register with the data source, be authorized to request data, and log all interactions between the application and the data source. (B) Patient selection. The API must include a means for the application to query for an ID or other token of a patient’s record in order to subsequently execute data requests for that record in accordance with (e)(1)(iii)(C) of this section. (C) Data requests, response scope, and return format. The API must enable and support both of the following data request interactions: (1) Data-category request. The API must support syntax that allows it to respond to requests for each of the individual data categories specified in the Common Clinical Data Set and return the full set of data for that data category (according to the specified standards, where applicable) in either XML or JSON. (2) All-request. The API must support syntax that allows it to respond to a request for all of the data categories specified in the Common Clinical Data Set at one time and return such data (according to the specified standards, where applicable) in a summary record formatted according to the standard adopted at § (a)(4). 20

Application Access [via an Application Programing Interface] (2 of 2) (D) Documentation. The API must include accompanying documentation that contains, at a minimum: (1) API syntax, function names, required and optional parameters and their data types, return variables and their types/structures, exceptions and exception handling methods and their returns. (2) The software components and configurations that would be necessary for an application to implement in order to be able to successfully interact with the API and process its response(s). (E) Terms of use. The terms of use for the API must be provided, including, at a minimum, any associated developer policies and required developer agreements. 21

2015 Edition Proposed Rule: Addressing Health Disparities 22 Proposed Certification CriteriaWhat the Functionality Can Support Documentation of social, psychological, and behavioral data (e.g., education level, stress, depression, alcohol use, sexual orientation and gender identity) Allow providers and other stakeholders to better understand how these data can affect health, reduce disparities, and improve patient care and health equity Exchange of sensitive health information (data segmentation for privacy) Allow for the exchange of sensitive health information (e.g., behavioral health, substance abuse, genetic), in accordance with federal and state privacy laws, for more coordinated and efficient care across the continuum. Accessibility of health IT Compatibility of certified health IT with accessibility technology (e.g., JAWS text-to- speech application) More transparency on the accessibility standards used in developing health IT More granular recording and exchange of patient race and ethnicity Allow providers to better understand health disparities based on race and ethnicity, and improve patient care and health equity.