Regulation vs Innovation: The Battles of a Certified EHR in a Meaningful Use World

In the past five years, EHR technology vendors and providers have been struggling with the numerous regulatory requirements, from PQRS and eRx programs to Meaningful Use, value-based modifiers, ICD-10 and more.

As new regulations require new features in a very short timeframe, vendors meet the demands by “gluing” components onto existing platforms, often creating awkward user interfaces that frustrate both users and vendors alike. With strict deadlines, how can vendors and providers innovate in this era of regulatory burden?

Innovative solutions often become apparent when people take the time to step back and identify the real problem. However, stepping back in the heavily regulated EHR space is almost an impossible feat.

With no reprieve in sight, the next few years will continue with this regulatory focus requiring new EHR features and alignment to standards (set by the Office of the National Coordinator) to help support Meaningful Use Stage 3 and the long-term goal of interoperability and quality management.

Proposed ONC Certification Criteria for 2015

On March 20, the ONC released the proposed 2015 Edition Health Information Technology (Health IT) Certification Criteria and 2015 Edition Base Electronic Health Record (EHR) Definition. This not-so-easy-to-read 431-page document describes all of the 68 requirements an EHR must meet in order to be certified. I’ll spare you the requirement details in this blog, but if you feel compelled to dig in, this document covers it nicely.

Even though the proposed MU Stage 3 objectives and measures seem to have become less complex, the proposed certification requirements for EHRs have gotten much harder—partly due to the “decoupling” of CMS and ONC regulations.

Unlike in years past, CMS and ONC have “decoupled” their rules, so that CMS can specify a smaller number of objectives/certification criteria (or a subset of all the ONC requirements) that define a CEHRT. With this decoupling, the ONC’s requirements are agnostic to any program, while CMS leverages certain components to define a certified EHR. This leaves a number of requirements with no MU relationship.

John Halmaka, MD, and CIO of BlDMS and Harvard Medical, summed it up best when he said, “this has the potential to create market confusion, an overwhelming scope for vendors/developers, and a laundry list of requirements that serve narrow interests.”

Of all 68 requirements, only 36 are required for Meaningful Use. New objectives are indicated by an asterisk.

1. Demographics
2. Problem List
3. Medication List
4. Medication Allergy List
5. Smoking Status
6. Implantable Device List*
7. Clinical Decision Support
8. CPOE – medications
9. CPOE – laboratory
10. CPOE – diagnostic imaging
11. Transitions of Care
12. Application Access to Common Clinical Data Set*
13. Direct Project, Edge Protocol, and XDR/XDM
14. Direct Project
15. Clinical Quality Measures – record and export
16. Data Portability
17. Automated Measure Calculation
18. Automated Numerator Recording
19. Patient Health Information Capture*
20. Family Health History – pedigree
21. Family Health History
22. Transmission to Public Health Agencies – health surveys*
23. Transmission to Public Health Agencies – antimicrobial use and resistance reporting*
24. Transmission to Public Health Agencies – reportable condition reporting*
25. Drug-drug, Drug-allergy Interaction Checks for CPOE
26. Transmission to Cancer Registries
27. Transmission to Public Health Agencies – reportable laboratory tests and values/results
28. Transmission to Public Health Agencies – syndromic surveillance
29. Transmission to Immunization Registries
30. Secure Messaging
31. View, Download, and Transmit to 3rd Party
32. Drug-formulary and Preferred Drug List Checks
33. Electronic Prescribing
34. Clinical Information Reconciliation and Incorporation
35. Patient-specific Education Resources
36. Clinical Quality Measures – Report

ONC estimates that the above list will take around 47,000 hours of development. This estimate feels very low when you factor in quality assurance, user acceptance testing, training, implementation, and adoption.

So that leaves us with 32 additional non-related MU requirements:

• 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

ONC estimates that the remainder of the non-MU related requirements will take an additional 44% of development time. That is just shy of 70,000 hours just to complete all 68 items. That would take a team of 10 developers over 3 years to complete (at a very rapid pace). I wonder what amazing health IT solutions could be developed if 3 years were dedicated to really understanding the needs of providers and innovating on their behalf?

Where’s the balance?

As you can see, the next couple of years will really hinder the time, budget, and ability of EHR vendors to innovate and provide the end-user what they need. Instead, EHR vendors will be creating features that will most likely benefit the non-EHR user. For instance, a complex immunization system for a nephrologist who most likely only administers a seasonal flu shot? Who benefits from that?

John Halmaka states that the heavy burden 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 U.S. special interests.” And that the criteria are only designed to “accrue benefits to people who aren’t feeling the opportunity cost.”

This isn’t to say that all regulatory requirements are bad. There are benefits in having a little bit of regulation. For example, the MU program has been a major catalyst in the adoption of EHRs. (EHR adoption rates went from 18% in 2001 to 78% in 2013, and most of that was attributed to MU.) However, where is the fine line between regulation and innovation?

We invite you to share your thoughts on this topic. What features would you have liked to see (or wish didn’t exist) in the list above?

Diana Strubler, Senior Product Analyst, Health IT Standards, joined Acumen in 2010 as an EHR trainer then quickly moved into the role of certification and health IT standards subject matter expert. She has successfully led Acumen through three certifications while also guiding our company and customers through the world of Meaningful Use, ICD-10 and PQRS.