The CMS and ONC NPRMs

This analysis was written by Micky Tripathi and John Halamka.

On Friday March 20, CMS released the Electronic Health Record Incentive Program-Stage 3 and ONC released the 2015 Edition Health Information Technology (Health IT) Certification Criteria, 2015 Edition Base Electronic Health Record (EHR) Definition, and ONC Health IT Certification Program Modifications.

Perhaps the most important statement in the entire 700+ pages is the following from the CMS rule:  "Stage 3 of meaningful use is expected to be the final stage and would incorporate portions of the prior stages into its requirements."

Providers and vendors alike were all hoping for something lean and clean.  The CMS Stage 3 rule weighs in at 301 pages, but the ONC Certification rule takes the cake at 431 pages.  The JASON Task Force, whose recommendations were unanimously approved by the HIT Standards and Policy Committees, recommended that ONC and CMS make an explicit trade-off:  Decrease the breadth and complexity of the MU program, and in return, increase the expectations in a few key areas, such as interoperability.  The CMS MU Stage 3 rule, for the most part, has adopted this philosophy.  Unfortunately, the same can't be said for the ONC Certification rule.

We provide a brief synopsis of the MU and Certification Rules below, followed by our analysis of these proposals.

CMS Stage 3 MU Rule Synposis

The CMS Meaningful Use Rule is focused and narrowed to 8 objectives.

There is some fine-print though.  Contained within many of the objectives are multiple measures.  Depending on which options one chooses, and whether you are a provider or a hospital, the total number of MU measures could range from 15 to 20, and that's NOT INCLUDING the Clinical Quality Measures, which have always been like a MU menu all of their own, and which are now going to be determined through a different process and won't be defined until later in 2015.

Here is a synopsis of the MU Stage 3 requirements:

Provider-facing EHR functions:

*ePrescribing:  The thresholds have increased to 80% for EPs and 25% for EHs, but overall this is just asking for more of the same.  Of note is that controlled substance prescriptions can now be optionally included in states where it is allowed electronically.

*Clinical decision support:  There are 2 measures:  1) implement 5 CDS interventions tied to 4 quality measures; and 2) turn on drug-drug and drug-allergy interaction alerts for the entire EHR reporting period.  This is aligned with the past trajectory from earlier stages.

*CPOE:  There are 3 measures:  use CPOE on at least 80% of medication orders, 60% of lab orders, and 60% of diagnostic imaging orders.  CMS has given a little flexibility here by now counting entry by "scribes" (personnel with at least a medical assistant credential), excluding standing orders, and including a broader array of imaging such as ultrasound, MRIs, and computed tomography.

Patient-facing EHR functions:

*Patient access to information:  There are 2 measures:   1)  80% of patients must be able to access their records either through the View/Download/Transmit function or through an ONC-certified API; and 2) give 35% of patients access to patient-specific educational resources.  Note, this objective just requires that access is provided to patients.  No patient action is required in order to meet these objectives

*Active patient engagement:  There are 3 measures:  1)  25% of patients must access their records either through View/Download/Transmit or through an ONC-certified API; 2)  35% of patients must receive a clinically-relevant secure message; and 3) provider must incorporate information from patients or "non-clinical" settings for 15% of patients.  These measures do require patient action, though there is some flexibility because provider-initiated messages now count toward the secure messaging measure, for example.  The most challenging measure will be the last one, which requires patient-generated data or data from non-clinical settings such as home health, physical therapy, etc.

Interoperability:

*Health information exchange:  There are 3 measures:  1)  send electronic summary for 50% of TOCs and referrals; 2)  get electronic summary for 40% of TOCs and referrals; and 3)  perform med/allergy/problem reconciliation for 80% of TOCs and referrals.

*Public health and clinical data registry reporting:  There are 6 measures.  "Active engagement" is required for:  1)  immunizations; 2)  syndromic surveillance; 3)  reportable conditions case reporting; 4)  public health registries; 5)  non-public health registries; 6)  electronic lab reporting.  EPs need to choose 3 out of 1-5, and EHs need to choose 4 out of 1-6.  Having witnessed that that there is wide variability in public health capacity across the country, CMS has provided some flexibility here by defining "active engagement" broadly to include either registering, testing, or transacting.  In short, you'll get credit even if you're not actively transacting as long as you are on the path and making a good faith effort.

The CMS rule is laid out logically and pretty easy to follow.  (That is, for a 300+ page federal regulation.)

ONC 2015 Edition Certification Rule Synopsis

We wish we could say the same about the ONC Certification Rule.  Whereas the CMS rule seems to be using MU Stage 3 to stabilize expectations, the ONC rule does the opposite and crams too much into the 2015 Edition Certification.  To make matters worse, the rule isn’t laid out clearly or logically, so it's hard to ascertain how all of the pieces fit together.

There are 68 individual certification requirements described in the ONC rule.  It would be impossible to lay out all of the details here.  The list of all of the requirements is here.

There are 36 of the 68 requirements that are required for Meaningful Use.  ONC introduces the concept of the "Base EHR", which has the following 16 requirements.  New requirements are marked with a *.

 • Demographics
 • Problem List
 • Medication List
 • Medication Allergy List
 • Smoking Status
 • Implantable Device List*
 • Clinical Decision Support
 • CPOE – medications
 • CPOE – laboratory
 • CPOE – diagnostic imaging
 • Transitions of Care
 • Application Access to Common Clinical Data Set*
 • Direct Project, Edge Protocol, and XDR/XDM
 • Direct Project
 • Clinical Quality Measures – record and export
 • Data Portability

But for meaningful use, CMS says that you need the Base EHR, plus 20 more requirements:

 • Automated Measure Calculation
 • Automated Numerator Recording
 • Patient Health Information Capture*
 • Family Health History – pedigree
 • Family Health History
 • Transmission to Public Health Agencies – health surveys*
 • Transmission to Public Health Agencies – antimicrobial use and resistance reporting*
 • Transmission to Public Health Agencies – reportable condition reporting*
 • Drug-drug, Drug-allergy Interaction Checks for CPOE
 • Transmission to Cancer Registries
 • Transmission to Public Health Agencies – reportable laboratory tests and values/results
 • Transmission to Public Health Agencies – syndromic surveillance
 • Transmission to Immunization Registries
 • Secure Messaging
 • View, Download, and Transmit to 3rd Party
 • Drug-formulary and Preferred Drug List Checks
 • Electronic Prescribing
 • Clinical Information Reconciliation and Incorporation
 • Patient-specific Education Resources
 • Clinical Quality Measures -- Report

So what are the additional 32 requirements if they're not required for Meaningful Use?  It's the list below, arrayed in order of decreasing complexity as estimated by ONC.

 • Electronic Submission of Medical Documentation*
 • Accessibility Technology Compatibility*
 • Consolidated CDA Creation Performance*
 • Vital Signs, BMI, and Growth Charts
 • Data Segmentation for Privacy (Federal substance abuse privacy law) – send*
 • Data Segmentation for Privacy (Federal substance abuse privacy law) – receive*
 • Quality Management System
 • Decision Support – knowledge artifact (send CDS interventions)*
 • Transmission of Laboratory Test Reports
 • Clinical Quality Measures – filter*
 • Incorporate Laboratory Tests and Values/Results
 • Safety-Enhanced Design
 • Care Plan  (consolidated from multiple care plans)*
 • Social, Psychological, and Behavioral Data*
 • Decision Support – service (receive CDS interventions)*
 • Healthcare Provider Directory – query response*
 • Healthcare Provider Directory – query request*
 • Clinical Quality Measures – import and calculate
 • Accessibility-Centered Design*
 • Integrity
 • End-User Device Encryption
 • Emergency Access
 • Automatic Access Time-out
 • Amendments
 • Audit Report(s)
 • Auditable Events and Tamper-resistance
 • Authentication, Access Control, Authorization
 • SOAP Transport and Security Specification and XDR/XDR for Direct Messaging
 • Accounting of Disclosures
 • Image Results
 • Patient List Creation
 • Electronic Medication Administration Record

Buried within these 700+ pages of proposed federal regulations are many objectives, measures, and requirements, as well as a lot of hopes, dreams, and aspirations -- what we would characterize as The Good, The Bad, and The Ugly.

The Good

The CMS rule level sets everyone at Stage 3 by 2018.  That makes life easier for providers, vendors, and the government.

Some of the objectives and thresholds need adjustment to align with workflow, change management and market realities, but overall the CMS MU Stage 3 proposal is a good first draft.  CMS deserves a lot of credit for streamlining and consolidating a lot of the stray threads from MU Stages 1 and 2, and making the Stage 3 rule coherent and relatively easy to understand.

Both the MU and Certification rules emphasize application program interfaces (APIs), and do so in a judicious and thoughtful way.  They give credit to those early adopters who may implement APIs ahead of the market, signal toward RESTful FHIR APIs and OAuth as future certification candidates, but don't lock in those standards before they are mature and market-tested.  This glide path is directly in line with recommendations from the JASON Task Force, HITSC and HITPC, as well as the Argonaut Project, and thus has a lot of community momentum behind it.  They seem to have learned the lessons of the Direct standard, which should be commended.

The MU rule makes a practical leap into query-based exchange by requiring receipt of records from other entities.  Few will be able to generate queries electronically at the outset, but it gives credit to those who can, and motivates others to enable workflows and technologies to do so as quickly as possible.

The “Base EHR Definition" was introduced in the ONC 2014 Certification Edition and included all of the security certification criteria and standards.  However, no individual module submitted for certification was required to meet the "Base EHR Definition," nor was any module required to meet any security criteria at all.   Instead, it was up to each purchaser to determine whether the set of modules purchased collectively met the "Base EHR Definition" and therefore would be capable of meeting the requirements of HIPAA. The  ONC 2015 Certification Edition removes security from the "Base EHR Definition" and instead assigns each security requirement to the types of modules where that functionality is most applicable.

Finally, patients are given a high priority, as they should be.  The big problems of health care can't be solved without making patients better custodians of their own care, and the MU and Certification rules give a large boost to those efforts.

The Bad

In the Meaningful Use rule, CMS undermines a bit of the simplicity by allowing a reporting period exception for year 1 Medicaid participants. They should have Medicaid year 1 follow the same requirements as everyone else which will level set everyone.

While it is good to align the CQMs with other CMS quality programs, the detail on CQMs now won't be provided until later this year.  We’re asked to weigh in now on quality measurement policy issues (such as whether all products should be required to support all measures) absent important information such as how many measures CMS is considering, whether they are all well suited to EHRs, and if they would be generally applicable to all EHR products.

There are 3 main issues with the ONC rules.  First is the concept of "decoupling".  CMS and ONC have “decoupled” their rules, so that CMS can specify a smaller number of objectives/certification criteria, while ONC can provide a list of everything health IT could/should/might be, including a broad scope beyond EHRs.  CMS now owns the "CEHRT definition.” CMS sets the program policy requirements for MU and defines what minimally needs to be certified.  This is a change in the directionality of the ONC/CMS regulatory relationship.  In the past two regulatory cycles ONC’s rules have included MU program policy and pointed to CMS for details.  Now, ONC’s rule is agnostic to any program and the CMS MU program points to ONC for certification specifications.  Thus, the ONC rule includes a variety of certification specifications for which there are no corresponding MU requirements from CMS.   This has the potential to create market confusion, an overwhelming scope for vendors/developers, and a laundry list of requirements that serve narrow interests.

Second, if we care about patient health, it's not intuitively obvious why some requirements are where they are.  For example, why is "Vital Signs, BMI, and Growth Charts" excluded on the MU list, but "Transmission to Public Health Reporting -- health surveys" is included on the MU list?

Third, it feels as if every wish of every stakeholder was included in the rule without setting priorities, rather than being specifically focused on functions the directly serve patient care and patient engagement.  There is not a really bad idea among the 68 proposed requirements, but do all of the problems of public health and Medicare FFS post-payment medical documentation review and safety-enhanced design and a host of other needs have to be solved at the same time as MU-related certification?  ONC estimates that all the development they propose would take 23,000 hrs to 47,000 hrs to develop. They have improved at estimating but that is still low (for example, for safety-enhanced design, they estimate 300-600 hrs, but it's taken most vendors >1000hrs in the past and they just doubled the number of things you're expected to summative usability test).  And by ONC's own estimates, vendors will have to spend 44% more development hours to meet all of the non-MU related certification requirements.  It would be much more simple if ONC created a 2015 Edition Rule for only MU-required functions, and then separate rules for the many other non-MU certifications that it would like to propose.

Fourth, while the API part of the Certification Rule seems to reflect the lessons learned from our experience with Direct, other areas seem to be making some of the same mistakes.  By casting the net so widely on the types of functions it wants to certify, the Rule inevitably proposes some standards that are not sufficiently market-tested to be de facto requirements for the entire industry.  The Health IT Standards Committee developed a very thoughtful framework for identifying which standards will have high chances of market acceptance.  Standards for such functions as provider directories, multi-entity care plans, exchange of CDS interventions, submission of FFS post-payment documentation, data segmentation to meet cumbersome federal substance abuse law requirements, etc don’t yet meet that test.  Standards for public health transactions (such as requiring bidirectional interfaces for immunization registries and reportable conditions reporting) are not only novel, they are not even deployed by most public health agencies.  We should have a high bar for anointing a standard to be worthy of federal-level certification, even if such requirements are “voluntary”.  The Rule does much to promote the move to RESTful APIs, and in most cases, we may very well find that following the path of facebook, and google, and twitter will be much faster and valuable than burdening the industry with even more older generation, health-care specific approaches.

The Ugly

If a clinician has 12 minutes to see a patient, be empathetic, document the entire visit with sufficient granularity to justify an ICD-10 code, achieve 140 quality measures, never commit malpractice, and broadly communicate among the care team, it’s not clear how the provider has time to perform a "clinical information reconciliation" that includes not only medications and allergies, but also problem lists 80% of the time.

Maybe we need to reduce patient volumes to 10 per day?  Maybe we need more scribes or team-based care?  And who is going to pay for all that increased effort in an era with declining reimbursements/payment reform?

As one of us wrote about in the Information Week article, Boiling the Frog, each incremental proposal is tolerable, but the collective burden is making practice impossible.

The sheer number of requirements may create a very high, expensive and complex set of barriers to product entry.  It may stifle innovation in our country and reduce the global competitiveness for the entire US Health IT industry by over-regulating features and functions with complicated requirements that only apply to CMS and US special interests.    The certification criteria are often not aligned with what EHR users ask for. In some cases, the criteria are completely designed to accrue benefits to people who aren't feeling the opportunity cost. So if certification is loaded by non-EHR users, EHR users are going to find that even if the MU objectives are fewer in number and more focused, that their EHRs are focused on a lot of things they haven't asked for.

There needs to be a very public discussion with providers as to who should prioritize EHR development -- ONC and the stakeholders they've included, or EHR users.  The work of the country over the next few months needs to be achieving a consensus about what should be in the Certification rule and what should be removed.   If industry, academia, clinicians, payers, and patients can align on a minimal set of requirements, we're confident ONC will listen.