Unravelling Meaningful Use Stage 3

January 15, 2016

A brief overview of what it means for Healthcare ISVs

Vijayalaxmi Kudekar

Vijaya is a business analyst with more than 6 years

of experience in Health IT & Technology Strategy. In

her free time she becomes creative with brush and

paints her visualization on the canvas.

MEANINGFUL USE STAGE 3

For Example

CMS will now allow providers to consume APIs to

help meet criteria.

All providers to report on a full calendar year

reporting period (except Medicaid providers,

who would report for every 90 days in their first

year)

Comparative Study based on proposed final rule

Overview

Meaningful Use (MU) stage 3 is the next step to meaning-

ful use stage 1 and meaningful use stage 2 programs.

Most of the modifications proposed in MU3 are designed

to align with the current MU requirements and make it

more practical & flexible. That said, some of the MU2

objectives are retained as such, with small or no modifi-

cation while some have an extended scope.

Health organizations will have option to report in Stage 3 criteria in 2017. They'll be required to do so beginning in

2018, regardless of prior participation/stage of meaningful use.

MU2 modifications (2015 to 2017), major provisions

10 objectives for eligible professionals (EPs) in-

cluding one public health reporting objective,

down from 18 total objectives in prior stages.

9objectives for eligible hospitals (EHs) and critical

access hospitals (CAHs) including one public

health reporting objective, down from 20 total objec-

tives in prior stages.

90 day continuous reporting period in their first

year of eligibility

Clinical Quality Measures (CQM) reporting for both eligi-

ble professionals (EPs) and eligible hospitals/CAHs re-

mains as previously finalized.

Core MU3 objectives highlights

8 objectives for EPs, EHs, and CAHs

>60% of measures require interoper-

ability, up from 33% in MU2.

Public health reporting with flexible options for meas-

ure selection and CQM reporting aligned with the

CMS quality reporting programs.

Finalize use of application program interfaces (APIs)

that aid development of new functionalities to build

bridges across systems. This will help patients have

unprecedented access to their health records to

make key health decisions.

45% of criteria are unchanged or minimally revised for the ambulatory settings.

42% of criteria are unchanged or minimally revised for inpatient settings.

Only need to do ~60% of proposed 2015 Edition criteria to participate in Stage 3.

Minimum requirement for MU3: Ambulatory Vs Inpatient

Certification Reporting Requirements – Summary

Base EHR definition now is an electronic record of health-related information on an individual that:

1. Includes patient demographic and clinical health information, such as medical history and problem lists;

2. Has the capacity to

Provide clinical decision support

Support physician order entry

Capture and query information relevant to health care quality;

Exchange electronic health information with, and integrate such information from other sources; and

3. Has been certified to the certification criteria viz.§ 170.315

(a)(1), (2), or (3); (a)(5) through (9); (a)(11); (a)(15);

(b)(1) and (6);

(c)(1);

(g)(7) through (9); and

(h)(1) or (2)

CCDA creation performance (g)(6)

App. access to common clinical data-set, data cat-

egory request (g)(7-8)

Patient Health Information capture (a)(19)

Implantable device list (a)(20)

Transmission to PHA - Case reporting, Antimicrobial-

use reporting & resistance reporting, healthcare sur-

veys (f)(5-7)

Social, psychological and behavioral data (a)(21)

Decision support (a) (22-23)

DS4P - send/receive (b)(7-8)

CQM filter (C)(4)

‘Structured’ Care plans - (b)(9)

Accessibility centered design (g)(8)

Patient specific education resources(a)(17)

Transitions of care (b)(1)

Data portability (b)(6)

Automated numerator recording (g)(1)

Problem list (a)(6)

Clinical information reconciliation and incorpora-

tion (b)(2)

eRx (b) (3)

CQM record/expert/import/calculate (C)(1,2)

VDT (e)(1)

Transmission to Immunization, Cancer registries,

PHA for syndromic surveillance, reportable Lab

tests/values/results - (f)(1-4)

Safety enhanced design (g)(3)

New Criteria Revised Criteria

* A more elaborate list is in the appendix for your reference

MU3 Objectives

1. Protect Electronic Health Information (ePHI)

Conduct or review a security risk analysis including ad-

dressing the encryption/security of data stored in CEHRT,

and implement security updates as necessary and cor-

rect identified security deficiencies as part of the EP’s,

EH’s, or CAH's risk management process.

2. Electronic Prescribing

EP Measure: More than 80% of all permissible prescrip-

tions, or all prescriptions, written by the EP are queried

for a drug formulary and transmitted electronically using

CEHRT. EH/CAH Measure: More than 25% of hospital dis-

charge medication orders for permissible prescriptions

(for new, changed, and refilled prescriptions) are que-

ried for a drug formulary and transmitted electronically

using CEHRT.

3. Clinical Decision Support

Implementing Clinical Decision Support for national high

priority conditions. EPs must satisfy both below measures

in order to meet the objective.

Measure 1: Implement 5 clinical decision support inter-

ventions related to 4 or more CQMs at a relevant point

in patient care for the entire EHR reporting period.

Measure 2: Enabled and implemented the functionality

for drug-drug and drug-allergy interaction checks for

the entire EHR reporting period.

4. Computerized Provider Order Entry (CPOE)

More than 80% of medication, 60% of laboratory, and

60% of “diagnostic imaging” orders are recorded using

CPOE. EPs, eligible hospital, or CAH must meet all 3

measures

5. Patient Electronic Access to Health Information

EP s/EHs/CAHs must satisfy both measures in order to

meet the objective.

Measure 1: More than 80% of all unique patients seen

by the EP or discharged from the hospital during the

EHR reporting period are provided access to new infor-

mation within 24 hours of its availability to the EP/EH/

CAH, subject to the provider's discretion to withhold

certain information.

Measure 2: Use clinically relevant information from

CEHRT to identify patient specific educational re-

sources and provide electronic access to those materi-

als to 35% of patients.

6. Patient Engagement

EPs/EHs/CAHs must attest to 3 measures, but meet 2 out

of 3 thresholds:

Measure 1: EPs/EHs/CAHs must attest to 3 measures,

but meet 2 out of 3 thresholds. More than 25% of all

unique patients (or authorized representatives) under

the care of the EP/EH/CAH during the EHR reporting

period (1) view, (2) download, or (3) transmit to a third

party their health information. Or enable API and meet

Measure 1 of Patient Electronic Access Objective.

Measure 2: EP/EH/CAHs communicate with patients

electronically through secure messaging for 35% of pa-

tients encountered during the reporting period. In pa-

tient-to-provider communication, provider must re-

spond to patient to receive credit under this objective.

“Communicate” means when a provider sends a mes-

sage to patients OR when a patient sends a message

to the provider and the provider responds.

Measure 3: EP/EH/CAH must use health information re-

ceived electronically from a non-physician source for

15% of patients encountered by EP/EH/CAH in the re-

porting period and must use health information re-

ceived from a patient or from the patient’s caregiver

for 5% of patients encountered by the EP/EH/CAH in the

reporting period.

7. Health Information Exchange

EPs/EHs/CAHs must attest to 3 measures, but meet 2 out

of 3 thresholds:

Measure 1: The EP/EH/CAH that transitions or refers their

patient to another setting of care or to another provider

of care creates and exchanges an electronic summary

of care record for 50% of such transitions of care and

referrals. The electronic summary of care must be sent

in accordance with the standards for transitions of care

set by ONC.

Measure 2: The EP/EH/CAH must receive, request or

query for a patient’s electronic summary of care record

that has been created by another setting of care or

provider of care for 40% of all new patient encounters

during the reporting period. The electronic summary of

care must be accessed in accordance with the stand-

ards for transitions of care set by ONC.

Measure 3: Clinical Information Reconciliation (CIR) –

Providers perform clinical information reconciliation for

more than 80% (percent will be the same as Measure 1)

of transitions of care in which the patient is transitioned

into the care of the EP/EH/CAH. Provider may choose to

reconcile 2 out of 3 of the following - medications, prob-

lems, and allergies.

8. Public Health Reporting

Providers must report data on an ongoing basis to es-

tablished public health registries. Registry options: Im-

munization, syndromic surveillance, ELR, specialized

(PDMP, cancer, etc.)

EP Objective: Report 3 measures from #1-5

EH/CAHs Objective: Report 4 measures from #1-6

Measure 1: Immunization registry reporting

Measure 2: Syndromic Surveillance reporting

Measure 3: Case Reporting

Measure 4: Public Health Registry Reporting

Measure 5: Clinical Data Registry Reporting

Measure 6: Electronic Reportable Laboratory results re-

porting (EH only)

Note:

* Providers may choose to report to more than one pub-

lic health registry to meet the number of measures.

* Providers may choose to report to more than one clini-

cal data registry to meet the number of measures re-

quired to meet the objective.

Changes to Participation Timeline

2015 2016 2017 2018

Attest to modified MU2

with accommodations for

Stage 1 providers

Attest to full version of

Stage 3

Attest to modified version

of Stage 2

Attest to either modified MU2

or full version of Stage 3

Our Analysis (Continued)

1. CCDA

Supporting CCDA V1.1 AND V2.1 for data exchange

With many health-IT systems already certified with

meaningful use stage 2 criteria using CCDA 1.1, we ex-

perienced that many health systems did not adopt a

flexible design which can easily be migrated to support

newer versions and templates. This would mean rewrite

of CCDA specification for many EHR vendors with high

impact on 2014 related data reporting when they mi-

grate to 2015 standard.

This also includes ability to incorporate & reconcile clini-

cal data from both CCDA 1.1 and CCDA 2.1 across

document templates viz. Transition of Care, Referral

Note, CCD and Discharge Summary (for inpatient)

CCDA Verification

MU3 requires users to be able to verify incoming CCDA

and to be able to detect errors in CDA which can help

other party to understand the errors.

This adds an existing burden of validating CDA with re-

spect to template specification and report errors ac-

cordingly. Since CCDA standard are still evolving, prop-

er design consideration shall be made to update vali-

dation specification with updated version.

CCDA data privacy & confidentiality

MU3 has somewhat mitigated the existing vulnerability

in systems supporting CCDA exchange of not being

able to tag a patient data as confidential or sensitive.

The latest mandate is to have ability for a sender to

tag a patient data at document level to be sensitive in

accordance with DS4P standard as outlined in the HL7

Version 3 Implementation Guide: DS4P, Release 1

(DS4P IG), Part 1: CDA R2 and Privacy Metadata.

Also it includes the ability to receive documents with

elements that are subject to restrictions on re-

disclosure according to the standard.

Care Plan

While many EHRs still lack the capability to identify and

track problems, goals, evaluations & interventions for

the patient even as unstructured data, the complexity

level in MU3 has been increased to report and docu-

ment such data in structured format using CCDA ver-

sion 2.1 and CCD template.

Data Export/portability

The scope of data portability through CCDA for multi-

ple patients has been enhanced to support date

based search on clinical data-set along with support

for both real time and automatic creation of such

documents as per user’s set preferences.

Since CCDA creation was more of a manual trigger for

system meeting stage 2 specifications, this is an addi-

tional requirement they will need to add to their CCDA

capabilities.

From the final rule, this is clear that Meaningful Use 3 certification has been aligned to work more extensively with

the data captured or capture some more data and to be able to exchange that data using standards. Below are

the areas of work, we consider of higher impact and complexity. Please note that we have ONLY chosen areas

that we believe might prove to be tricky during implementation and the revised criteria have been already imple-

mented, though excluding the revised portions.

Our Analysis( Continued)

2. Transmissions to Public Health Agencies (PHA)

MU3 takes transmissions to a next level with:

Electronic case reporting involves creating a case

report for patient encounter based on a matched

trigger code based on the parameters of the trig-

ger code table

Antimicrobial use and resistance reporting in the

CDA 2.1 document which involves HAI Antimicro-

bial Use and Resistance (AUR) Antimicrobial Re-

sistance Option Report (Numerator), Antimicrobial

Resistance Option (ARO) Summary Report

(Denominator) and Antimicrobial Use (AUP) Sum-

mary Report (Numerator and Denominator)

Health care surveys information for electronic

transmission

3. Clinical Quality Measures (CQMs)

We have found that CQM’s developed by many EHR

vendors for meaningful use stage 2 requirements over-

looked the design considerations needed for it to be

able to move to new updated standard without much

impact and efforts. Also, we also found that many EHR

vendors overlooked the import functions and were not

saving data in the system in a way it can be filtered

easily and extracted out.

Below are the major changes in eCQM’s related

measures which have major impact in MU 3:

Ability to export and create QRDA data files ac-

cording to Quality Reporting Document Architec-

ture—Category I (QRDA I); Release 1, DSTU Re-

lease 3 (US Realm) (both Volumes 1 and 2); and:

Quality Reporting Document Architecture—

Category III, DSTU Release 1 (US Realm) with Sep-

tember 2014 Errata.

Ability to filter CQM results at the patient and

aggregate levels and be able to create a data

file of the filtered data in accordance with the

QRDA Category I and Category III updated

standards, as well as be able to display the fil-

tered data results in human readable format.

4. Patient information

Patients should be able to access health infor-

mation documents through a reference or link to

the same, shared by providers

Application Access To Common Clinical Data

Set: This requires an EHR to be able to expose an

API which can respond to queries based on indi-

vidual patient matching data, common clinical

set and be able to return patient clinical sum-

mary as per CCDA Version 2.1 in real time.

Application Access to Data Category Request:

The application needs to provide a way for the

provider to view the data category requests for

patient data and respond to those for each of

the individual data categories.

In following the HITSC recommendation for

Health IT Module functionality to store an ad-

vance directive and/or include more information

about the advance directive, ONC replaced

the 2014 Edition “advance directives” certifica-

tion criterion (§ 170.314(a)(17)) and applied it to

various patient health information documents.

A Health IT Module would need to enable a user

to: (1) Identify (e.g., label health information doc-

uments as advance directives and birth plans),

record (capture & store) and access (ability to

examine or review) patient health information

Our Analysis

documents; (2) reference and link to patient health

information documents; and (3) record and access

information directly and electronically shared by a

patient.

Several changes has been proposed in patient de-

mographic some of which are capturing date of

death and ability to add/edit/access social, psy-

chological, and behavioral data including Sexual

Orientation and Gender Identity (SO/GI) of the pa-

tient. While we do not find these changes to be

technically complex, it still needs attention on how

and where EHR decides to capture these additional

demographic information.

5. Clinical Decision Support (CDS)

With MU3, the CDS capabilities have been advanced

with capabilities to record actions for the CDS, support-

ing of knowledge artifacts and decision support service.

CEHRT now needs to demonstrate electronic send/

receive capability for CDS knowledge artifacts in as per

Health eDecisions (HeD) standard.

It also needs to be able to make an information request

with patient data and receive e clinical guidance as

per HeD standard and the associated HL7 IG. ( Please

refer HL7 V3: CDS Knowledge Artifacts Specification

and HL7 IG: Decision Support Service for more)

6. Implantable Device List - To improve care coordina-

tion and patient safety, include UDI(s) of patient’s im-

plantable device list. Supporting UDIs requires integra-

tion with Global UDI database.

Besides above, Health IT Module must be able to send

and receive transition of care/referral summaries

through a method that conforms to the ONC Imple-

mentation Guide for Direct Edge Protocols, Version

1.1. Under revised measures, Health IT module is ex-

pected to update their standards to latest version and

also updated value set of SNOMED CT, LOINC, HL7

Implementation Guide/s.

So how big is it really?

Here is what the Office of the Federal Register (OFR)

thinks about the kind of effort that would go into im-

plementing MU3. These are only a few high-level num-

bers. More details can be found here.

3544* developer

days

For new and revised criteria

* Above number is the mean of the conservative and optimis-

tic numbers from OFR.

While we aren't sure of the assumptions that were

made and the methodology followed by OFR to arrive

at these estimates, we believe that OFR might have

gone a little over the top with these numbers.

Get in touch

580 developer

days

OFR Nalashaa

Are you Interested in knowing the effort to get your

software MU3 certified? We can help you with a free

assessment.

Fill up the form here