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, 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 healthcare 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.

 

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 three 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 >1,000hrs 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 percent 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, healthcare specific approaches.

 

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 percent 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 U.S. 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.

 

This analysis was written by Micky Tripathi and John Halamka. Click here to see the original post.