Upload
phambao
View
214
Download
0
Embed Size (px)
Citation preview
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