Draft – discussion only

Consumer WorkgroupSTAGE 3 Meaningful Use

Objective 6: Coordination of Care Through Patient Engagement

Christine Bechtel, chair

April 30, 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) Work@Health 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. Review Objective 6 of Stage 3: Coordination of Care Through Patient Engagement - Workgroup Discussion

II. Review VDT certification criteria in the 2015 Certification NPRM- Continue Workgroup Discussion

Objective 6:Coordination of Care Through Patient Engagement

4

Objective: Use communication functions of certified EHR technology to engage patients or their authorized representatives about patient care. Must meet 2 of 3 measures

MEASURE 1: > 25% of unique patients, either view, download or transmit health information or use ONC-approved API to access information.Stage 2 threshold was 5%

MEASURE 2: For 35% of unique patients, a secure message is sent to patient or in response to secure message sent by patient.Stage 2 threshold was 5%

Measure 3: For 15% of unique patients, either patient-generated health data or data from a non-clinical setting is incorporated in the EHR.

Eligible ProfessionalsRE: Exclusion Criteria

Who is an Eligible Professional under the Medicare EHR Incentive Program?

Eligible professionals under the Medicare EHR Incentive Program include:• Doctor of medicine or

osteopathy• Doctor of dental surgery or

dental medicine• Doctor of podiatry• Doctor of optometry• Chiropractor

Who is an Eligible Professional under the Medicaid EHR Incentive Program?

Eligible professionals under the Medicaid EHR Incentive Program include:• Physicians (primarily doctors of

medicine and doctors of osteopathy)

• Nurse practitioner• Certified nurse-midwife• Dentist• Physician assistant who furnishes

services in a Federally Qualified Health Center or Rural Health Clinic that is led by a physician assistant.

5http://www.cms.gov/Regulations-and-Guidance/Legislation/EHRIncentivePrograms/eligibility.html#BOOKMARK1

EP may exclude from the measure if they have no office visits.

Measure 1 : >25% of Unique PatientsVDT or ONC-Approved API Access

Option 1 and 2: View, Download or Transmit to Third Party

6

To calculate percentage:

Denominator The number of unique patients seen by the EP, or the number of unique patients discharged from an eligible hospital or CAH inpatient or ED during the EHR reporting period.

Numerator Option 1: The number of unique patients (or their authorized representatives )in the denominator who have viewed online, downloaded or transmitted to a third party the patient’s health informationOption 2: The number of unique patients (or their authorized representatives )in the denominator who have accessed their health information through the use of an ONC-certified API

Threshold The resulting percentage must be more than 25% in order for the provider to meet the measure

Exclusions Any EP who has no office visits during the EHR reporting period may exclude from the measure or is in a county with <50% of housing units with 4Mbs broadband

Request for Comment Measure 1Measuring API Use (p. 108)

Recognize there are challenges measuring patient access to CEHRT through an API rather than a portal

Request for comment:• What are the challenges and solutions?• Are there specific requirements around the use of APIs or are

there specific certification requirements for APIs that could make the objective easier to measure?

• Comment on suggested alternate proposals for measuring patient access to CEHRT through third party applications that utilize an API, including pros and cons of measuring a minimum number of patients (one or more) who must access their health information through the use of an API in order to meet the measure for this objective.

7

Measure 2 Secure Messaging

>35 % of unique patients (Stage 2 was 5%)

8

To calculate percentage:

Denominator The number of unique patients seen by the EP, or the number of unique patients discharged from an eligible hospital or CAH inpatient or ED during the EHR reporting period.

Numerator The number of patients in the denominator for who a secure electronic message is sent to the patient, the patient’s authorized representatives, or in response to a secure message sent by the patient

Threshold The resulting percentage must be more than 35% in order for the provider to meet the measure

Exclusions Any EP who has no office visits during the EHR reporting period may exclude from the measure or is in a county with <50% of housing units with 4Mbs broadband. Includes CAH or EH.

Request for Comment on Measure 2Secure Messaging (p. 109)

For 35% of unique patients, a secure message is sent to patient or in response to secure message sent by patient.• Should it count towards the 35% measure for secure messaging if provider sends an e-mail to another provider or other care team members, and the patient is an active participant in this conversation?

•How can this be captured in the numerator?For example: should only the initiating provider be allowed to include the communication as an action or should any provider who contributes to the message be allowed to count the communication?

9

Measure 3 Patient Generated Health Data

>15 % of unique patients

10

To calculate percentage:

Denominator The number of unique patients seen by the EP, or the number of unique patients discharged from an eligible hospital or CAH inpatient or ED during the EHR reporting period.

Numerator The number of patients in the denominator for whom data from non-clinical settings, which may include patient-generated health data is captured through the certified EHR technology into the patient record

Threshold The resulting percentage must be more than 15% in order for the provider to meet the measure

Exclusions Any EP who has no office visits during the EHR reporting period may exclude from the measure or is in a county with <50% of housing units with 4Mbs broadband. Includes CAH or EH.

Measure 3: Patient-Generated Health Data

11

Information received from non-

clinical setting

Means non-EP, non-EH provider who does

not have access to the EP/EHs EHR

E.g., Nutritionists, physical therapists,

psychologists, home health providers

Information received from

patient

Patient generates the data on their own or at the direction of a care team member

E.g., Recording vital signs, activity and

exercise, medication intake, nutrition

Includes data from either category or both categories listed:

Examples include social service data, advanced directives, medical device data, fitness monitoring

Request for Comment Measure 3 : Patient-generated data capturein EHR (p. 112)

Given the broad range of data, request for comment on:

• Should the data require verification by an authorized provider?

• Should the incorporation of the data be automated?• Should there be structured data elements available for

this data as fields in an EHR?• Should the data be incorporated in the CEHRT with or

without provider verification?• Should the provenance of the data be recorded in all

cases and for all types of data?

12

Request for Comment Measure 3 : Patient-generated data capturein EHR (p. 112, 113 )

• Whether this proposed measure should have a denominator limited to patients with whom the provider has multiple encounters, such as unique patients seen by the provider two or more times during the EHR reporting period.

• Should this data be divided into 2 measures: patient-generated data and all other non-clinical data?

• This would result in the objective including four measures with providers having an option of which two measures to focus on for the EHR reporting period.

• Should this measure apply only to EPs or to hospitals also? If not hospitals should hospitals be required to do both of the remaining measure options (VDT and secure messaging)?

13

2015 Edition Proposed RuleHealth IT Certification Criteria

• Review VDT certification criteria in 2015 Certification NPRM ( Reference VDT certification document)

• Addressing Health Disparities

14

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.”

15

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 § 170.210(f).

16

View

(A) Patients (and their authorized representatives) must be able to use health IT to view in accordance with the standard adopted at § 170.204(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 493.1291(c)(1) through (7);(ii) The information related to reference intervals or normal values as specified in 42 CFR 493.1291(d); and(iii) The information for corrected reports as specified in 42 CFR 493.1291(k)(2).

(5) Diagnostic image report(s).

17

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 § 170.205(a)(4), or in both formats. The use of the “unstructured document” document-level template is prohibited for compliance with the standard adopted at § 170.205(a)(4).(2) When downloaded according to the standard adopted at § 170.205(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).”

18

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 § 170.202(a).(ii) Through a method that conforms to the standard specified at § 170.202(d) and leads to such summary being processed by a service that has implemented the standard specified in § 170.202(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 § 170.202(a).(ii) Through a method that conforms to the standard specified at § 170.202(d) and leads to such summary being processed by a service that has implemented the standard specified in § 170.202(a).

19

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 § 170.210(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 §170.315(d)(2) and the information required to be recorded in paragraph (e)(1)(ii)(A) is accessible by the patient.

20

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 §170.205(a)(4).

21

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.

22

2015 Edition Proposed Rule: Addressing Health Disparities

23

Proposed Certification Criteria What 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.

24

PUBLIC COMMENT