Elion
CategoriesNewsletterResources
Elion Reports
July 5, 2024

The EHR Labyrinth: Untangling the myths and realities of Certified Health IT

Bobby Guelich's headshot
Bobby Guelich
CEO, Elion
Brendan Keeler's headshot
Brendan Keeler
Advisor, Elion

Any build/buy decision is hard, especially in enterprise software. Divining the differences between electronic health records, though, is hard mode. Luckily, we live in the era of great content and tools that our forefathers did not. Elion teamed up with Brendan Keeler of Health API guy to provide this comprehensive overview of certified EHRs.

“Do I need a certified EHR?”

One of the most common and foundational decisions in digital health, it’s oft-discussed and written. With the fuel of the pandemic leading to a massive rise in virtual and hybrid care practices, the off-spring of the first generation of Teladocs, Livongos, and Doctor on Demands, the question has only intensified. Several have written about adjacent topics:

While the road to choosing a path has become much more clear, the root question has been of handwavy explanations and quick references to dense regulatory literature:

“To E(HR) or not to E(HR)”

“The Digital Health Provider’s Guide to Selecting an EHR”

Thus, the baseline assumption among prospective EHR users who will be seeing patients who are covered by government programs such as Medicare and Medicaid is that they need one that is “ONC certified. In the EHR build/buy decision, this looming, poorly defined specter is one of the two main drivers that can shift a potential EHR builder to become an EHR buyer.

But if you ask people what “ONC certified” actually means or when it’s truly required, you’ll likely get a blank stare. And for good reason - it turns out that the answer is quite complicated. And shockingly, the statement that “most providers need to use a certified EHR” is perhaps not necessarily true.

We’re truly sorry about that and we’re here to do better.

Let’s right that wrong and finally answer “Do I need a certified EHR”, journeying into the maze a la young Jennifer Connelly and David Bowie in Jim Henson’s (somehow hit) movie Labyrinth. We’ve dug through the regulations and government websites so you don’t have to. By the end of this, you should have a solid understanding of what “ONC certified” means, and, more importantly, what you need to be looking for as you evaluate EHRs.

What does “ONC certification” mean?

In a vacuum, an electronic health record can mean a heck of a lot of different things. “Vertical SaaS but for doctors” cannot possibly do justice to the variety and variation that medicine demands. Just as we divide the animal kingdom all the way down to genus and species, so too can the roles and responsibilities of practitioners and administrative staff in healthcare be fractally divided. Doctors, nurses, schedulers, registrars, revenue cycle managers, and so much more, all packed into a single piece of software? On top of that, you layer in two drastically different domains with barely related workflows between inpatient and outpatient and sprinkle in a variety of specialties that do completely dissimilar things.

Brief Background and History

A large amount of complexity in regards to EHR certification is simply that the internet is cluttered with the exhaust of its 15 years across 3 different administrations. There are countless pages on Meaningful Use, MIPS, MACRA, Cures, and a variety of the sub-components the ONC and CMS have named, renamed, and stitched together. For a deeper dive into regulatory history, this series explains Meaningful Use, Cures, and other regulations in more detail, but for our purposes:

  • Meaningful Use Initial Stages (2011-2017):

    • The Meaningful Use program was rolled out in three stages.

    • Stage 1 (2011-2012) focused on data capture and sharing.

    • Stage 2 (2014-2015) emphasized advanced clinical processes.

    • Stage 3 (2017 onwards) targeted improved outcomes, requiring more comprehensive data sharing and patient engagement. The final rule for this was passed in 2015, so it was integrated/implemented through MIPS/MACRA below.

  • MACRA and the Quality Payment Program (2015):

    • The Medicare Access and CHIP Reauthorization Act (MACRA) of 2015 introduced the Quality Payment Program (QPP).

    • Under QPP, eligible clinicians could participate in the Merit-based Incentive Payment System (MIPS) or Advanced Alternative Payment Models (APMs).

    • Meaningful Use for Medicare providers transitioned into the Advancing Care Information (ACI) performance category within MIPS.

    • The Medicaid EHR Incentive Program continued independently for Medicaid providers.

  • Promoting Interoperability (2018-2021):

    • In 2018, the Centers for Medicare & Medicaid Services (CMS) rebranded ACI to Promoting Interoperability (PI) to emphasize interoperability and the exchange of health information.

    • The PI program streamlined measures, reduced reporting burdens, and focused on key areas like e-prescribing, patient access to health information, and public health data exchange.

  • Changes in 2021:

    • By 2021, the focus on interoperability became more pronounced, aligning with broader goals like patient-centered care and data access.

    • The Medicaid portion of Promoting Interoperability was sunset.

    • The 21st Century Cures Act, which complements the Promoting Interoperability program, mandates the use of APIs to improve data exchange and prevent information blocking, further enhancing interoperability efforts.

The ONC’s Base EHR

While an EHR can mean a lot of things, a certified EHR is far more concrete, as certification is a function of the Office of the National Coordinator’s regulatory powers. The ONC Health IT Certification Program (link) was launched in 2010. The voluntary program was established by ONC to provide for health IT certification and to support its availability for encouraged and required use under other federal, state, and private programs.

Said more plainly - the ONC is responsible for maintaining the definition of an EHR from a US government perspective. It sets a minimum bar for an electronic health record’s functionalities and features. Within the ONC Health IT Certification Program, these functional requirements are known as “certification criteria.” By demonstrating conformance against these certification criteria (sometimes while relying upon other sub-vendors), developers can have their software certified as Certified Health IT.

Acronyms and dense regulatory references, as far as the eye can see.

Notably, the ONC themselves do not do the certification or directly review software (aside from rare cases) but instead have various private companies who are authorized to perform the testing (ONC-Authorized Testing Laboratories or ONC ATLs) and certification (ONC-Authorized Certification Bodies or ONC-ACB). Today, there are just three remaining companies offering this:

Looking at the data available in theCertified Health IT Product List (a cool tool the ONC makes available publicly for anyone to understand what EHRs and health IT are certified), we can see clearly that Drummond is the clear winner in terms of testing and certification:

Absolute dominance, this is the health IT equivalent of watching MJ in his prime

“Hold up a second,” you may be saying, “Does Certified Health IT equate to a certified EHR?” If only it were that simple and easy. To allow for more best-of-breed, choose-your-own-adventure selection of EHR capabilities, the ONC moved towards a modular approach, where a provider could choose a variety of certified Health IT. Software certified as Certified Health IT is a superset of any application product that is certified to one or more criteria. That does not make them an EHR - it is possible to only certify to a single criteria, be certified Health IT, but not be a full EHR. Similarly, there are more “certification criteria” than those that actually comprise the various definitions of certified EHRs, as some criteria are relics of shuttered programs that are still tracked and other criteria are future-facing, signaling the ONC’s intent to potentially include them in their EHR definition in the future.

While empowering in terms of removing the necessity of monolithic software, the reality is that most traditional providers still use a single EHR that meets all criteria directly (or partnered with another certified vendor under the hood).

If you’re interested in going deeper into the ONC Health IT Certification Program, there’s plenty to explore:

Separate from the individual criteria or the designation of certified health IT, the ONC maintains their “Base EHR” definition (regulatory text version here):

This begs the question - “how many of the certified products are full Base EHRs?” Props to the ONC again for CHPL - it really is a great data tool, with the “big 3” of modalities: an easy-to-use UI, a JSON API, and a bulk export. Exporting all of CHPL’s active products and filtering by the Base EHR criteria, we see that only 173 out of 696 active products across 138 vendors fully fulfill the criteria for Base EHR.

I presume this is what the ONC was going for when naming it Base EHR, right?

Notably, some of the largest EHRs, like Cerner, don’t have a single product that is a full Base EHR. Instead, they’ve splintered their EHR into multiple smaller modules, likely to make recertification more contained and modular:

The CMS’ Certified EHR Definition

Okay, we’ve established a federal agency’s definition of an EHR. That must be what I, a digital health provider, need to use, or the ONC will come after me, right?

The labyrinth does not stop there, friends. While the ONC provides this core definition and a well-structured certification program for health technology developers, its regulatory authority does not lend itself to enforcement, encouragement, or requirements regarding what providers must do, at least regarding certified EHRs.

Instead, another federal agency, the CMS, has been the primary driver of adoption through a variety of programs since the initial Health Information Technology for Economic and Clinical Health (HITECH) Act. In that initial model, while CMS established the criteria for meaningful use and managed the incentive payments, ONC specified the technical capabilities required for EHR systems to support meaningful use objectives.

Steven Posnack, Deputy National Coordinator of the ONC, has some nice historical perspective on the evolution:

As the nation’s largest payer, the CMS has financial levers to ensure providers are using EHRs and embracing new technologies. This is structured today through two main CMS programs:

  1. Medicare Promoting Interoperability Program – Medicare-eligible hospitals and critical access hospitals must use Certified Electronic Health Record Technology (CEHRT) to avoid downward payment adjustments from Medicare.

  2. Quality Payment Program (QPP) – Medicare-eligible clinicians participating in the Merit-based Incentive Payment System (MIPS) must use CEHRT to receive full points in the Promoting Interoperability category, which ultimately impacts the payments you receive from CMS.

    1. Clinicians who participate in Alternative Payment Models (APMs) are similarly required to use CEHRT. However, the each alternative payment model can have their own definition of CEHRT in order to pull in the criteria that program deems necessary for success.

It is the CMS that defines a certified EHR, which has evolved over the past two decades. This definition began during Meaningful Use and was listed in42 CFR 495 (the regulatory text surrounding the Electronic Health Record Incentive Program). Before 2019, they spelled out a laundry list of specific criteria:

However, that definition shifted in 2019:

The CMS copies this definition into MIPS here, with one addition: any providers participating in Alternative Payment Models have a slightly different definition of CEHRT, where the specific APM can dictate what additional criteria beyond ONC’s Base EHR definition are needed for that payment model:

To summarize, our result, then, is that there are technically four definitions of an EHR by the government:

  • Base EHR

    • The ONC’s definition of certification criteria that forms the lower bound and is often included in other definitions

  • Certified Electronic Health Record Technology (CEHRT) for Medicare Promoting Interoperability

    • The CMS’ definition in 42 CFR § 495

    • This is currently ONC’s Base EHR as well as family health history, PHI capture, measure calculation, and CQM functionality

  • Certified Electronic Health Record Technology (CEHRT) for QPP MIPS

    • The same as “CEHRT” for Medicare P, but redefined in 42 C.F.R. § 414.1305

    • This is currently ONC’s Base EHR as well as family health history, PHI capture, measure calculation, and CQM functionality

  • Certified Electronic Health Record Technology (CEHRT) for QPP APM

    • The CMS’ definition in 42 C.F.R. § 414.1305

    • The ONC’s Base EHR and any additional criteria defined in the specific APM

Of the 173 products that were full Base EHRs, only 133 are fully certified EHRs across 104 vendors by the MIPS and Medicare Promoting Interoperability definition.

Promoting Interoperability Criteria

Folks, this may surprise you, but we’re not done yet. The road is long and winding, filled with twists, turns, acronyms, and compounding regulatory references. In addition to the criteria that make up a certified EHR, the CMS specifically requires additional capabilities to fulfill measures in the Medicare Promoting Interoperability program (inpatient) and Promoting Interoperability requirements for MIPS reporting (outpatient).

Calculus has nothing on parsing the truth from EHR regs

The Medicare Promoting Interoperability program has four main objectives, with measures that change and evolve each year as the CMS adds, removes, or updates them. For 2024, here are the objectives and measures:

Source

These measures are often (but not always) tied to ONC-certified criteria. This linkage is enumerated helpfully by the CMS in the ZIP file here, referencing these criteria:

Noticeably missing from the list is criteria (f)(4) Transmission to cancer registries. This is because, despite nearly identical naming, the criteria required in MIPS Promoting Interoperability diverges from Medicare Promoting Interoperability slightly, subtracting the antimicrobial reporting andadding cancer reporting as an option to Public Health Registry reporting:

Death, taxes, Kyle Meadors from the rafters with obscure CEHRT lore

Overall, the mandatory criteria set is lighter for MIPS Promoting Interoperability, with fewer required public health and clinical data exchange measures. Syndromic surveillance is optional and Electronic Lab Reporting is omitted altogether for MIPS:

When factoring in the Promoting Interoperability measures, only 57 products of the 137 certified EHRs include all necessary criteria, showing that most expect their customers to use other certified products they or partners make alongside the core EHR functionality.

Health IT Module Certification

Looking at the full list of certification criteria maintained by the ONC and filtering out anything included in the three EHR definitions or needed for Promoting Interoperability, we still have 24 certification criteria defined by the ONC that seemingly have no home.

Digging in, certain criteria are dependencies or prerequisites in the ONC’s certified health IT program. Most of these are related to safety, quality, and accessibility, which makes sense. If the government is going to sanction your software with a certification, they want it to not only do certain functionalities, but perform them safely and securely.  For example, the “Health IT Module dependent criteria” that the ONC has defined in 45 CFR § 170.550(g) kick in as soon as you try to certify any other criteria:

Similarly, the ONC has a “Privacy and security certification framework” in 45 CFR § 170.550(h) that activates when certifying different criteria. If pursuing base EHR / CEHRT, these all get pulled in:

Remaining Criteria

This leaves a small grab bag of criteria, which aren’t actively tied to any CMS program or ONC certification step due to varying reasons. Again, shout out to Kyle Meadors for his help here.

Untethered from the ONC’s base EHR definition, any CMS reimbursement program, or the ONC’s criteria for certification, these are truly optional at this point.

Summary

Summing it all up, it looks a little something like this:

The image originally had the dependencies, but it was a bit of an undecipherable shitshow

The ONC:

  • Defines what criteria make up a Base EHR

  • Defines what criteria are required for Health IT Module Certification

  • Implements all criteria needed by their definitions or the CMS’ definitions

The CMS:

  • Defines what criteria make up Certified Electronic Health Record Technology via:

    • Medicare Promoting Interoperability definition

    • QPP MIPS Promoting Interoperability definition

    • Each QPP Alternative Payment Model definition

  • Defines Promoting Interoperability measures that require specific criteria

If I’m an inpatient provider organization, I’m certifying my EHR/Software against the criteria specified in the Medicare Promoting Interoperability Program administered by CMS.

If I’m an outpatient provider organization, I am assessing the criteria in the MIPS Promoting Interoperability program or the QPP Promoting Interoperability program specific to my Alternative Payment Model.

The totally-predictable-in-hindsight reality is that ONC certification is complex, with different definitions of EHR depending on the CMS program and a fair amount of optionality across criteria depending on the provider type. This complexity is tracked in the spreadsheet here:

It’s worth noting that these definitions and criteria will only continue to change. The ONC’s iteration is ongoing, with HTI-1, HTI-2, and other future rules further adding, removing, and updating criteria. In particular, the predictions by John Travis here seem spot on - we can expect criteria related to prior authorization, for sure, but also perhaps CDS Hooks or other advanced FHIR capabilities.

Who does “ONC certification” actually apply to?

With a comprehensive and perhaps overly detailed synopsis of what ONC certification really, truly, and deeply means, the next layer of the EHR onion is who should actually care. The popular narrative (“everyone needs a certified EHR”) isn’t true in a blanket sense as expected.

Insurance Type

First and foremost to that equation is the simple question “Do you see traditional Medicare patients?” While the original Meaningful Use and subsequent programs included Medicaid populations, the federal funding for this slowed and dried up between 2018 and 2021, leading different state Medicaid agencies to end their respective EHR incentive programs in that period. In the current era, Promoting Interoperability and MIPS (as part of QPP) are only focused on Medicare. More specifically, these programs are for Medicare Part A (Promoting Interoperability) and B (MIPS/APM) and not Part C (Medicare Advantage). Thus, if an organization isn’t helping traditional Medicare FFS patients, they aren’t regulated under these programs and they don’t need an ONC-certified EHR.

Care Setting

Inpatient

If you run the numbers quickly, you realize that almost all hospitals end up pursuing Promoting Interoperability and needing a certified EHR. The Emergency Medical Treatment and Labor Act (EMTALA), a U.S. federal law enacted in 1986, mandates that anyone coming to an emergency department (ED) must be provided with appropriate medical screening and stabilizing treatment, regardless of their insurance status or ability to pay, including Medicare patients. Furthermore, Medicare patients are some of the highest acuity and most likely to need inpatient care.

A subset of hospitals that serve Medicare patients have legitimate reasons that they aren’t using a certified EHR:

  • Insufficient internet connectivity - Basically, if you’re a hospital operating in a rural area where internet connectivity is a problem, you have bigger fish to fry.

    • I’m somewhat floored that there might be hospitals in America without sufficient connectivity - it would be fascinating to know if this exception has ever been used.

    • …One does wonder if the use of Comcast qualifies providers for this, though.

  • Using decertified EHR technology - if the hospital had an EHR, but their vendor was decertified, it’s obviously not their fault.

    • This is relatively rare. Using CHPL, we only see 16 out of 716 certified technology entries have statuses related to decertification.

Listen, no judgement, but if you thought using “Tranquilmoney, Inc’s PracticeTracker” was a good idea, this one might be on you.

  • Extreme and uncontrollable circumstances - A catchall for the uncategorizeable. The CMS recognizes that weird shit happens and is willing to listen.

    • Things like hurricanes and COVID obviously apply here.

    • I bet these stories are riveting, so I submitted a Freedom of Information Act (FOIA) request to see if we can understand which hospitals have received this exception.

Putting our tax dollars to work 💪

Supposing they do not qualify for an exception, eligible hospitals could actively choose to not use a certified EHR, but this would entail a downward payment adjustment for their Medicare populations. I struggled to find precise details on the exact downward payment, so it’s possible that it’s not that high of a penalty. However, slide 19 of this presentation mentions a 75% downward payment, which is substantial.

Thus, it’s unlikely that the burden of using a certified EHR outweighs the regulatory, operational, and financial cost of foregoing Medicare patients for inpatient care.

Outpatient

In the outpatient world, though, there’s far more nuance, in that there are plenty of outpatient providers that do not treat or seek reimbursement from the CMS for Medicare FFS patients. This could be due to their specialty (pediatricians surprisingly don’t take Medicare patients often) or due to their go-to-market (concierge medicine paid out-of-pocket). This is even more true for tech-enabled care providers, which often focus on cash pay and direct employer sales.

Outpatient provider eligibility

Not all outpatient providers that see Medicare patients are eligible for MIPS, though. The CMS imposes additional eligibility filters for outpatient providers within the MIPS program related to specific provider’s or provider organizations’ specialty and patient volume.

The CMS determines providers’ eligibility by reviewing past and current Medicare Part B claims and Provider Enrollment, Chain, and Ownership System (PECOS) data for clinicians and practices twice a year. As a result, the information is laggy - my wife, for instance, doesn’t even show up when checking usingthe MIPS eligibility tool:

Low volume threshold

If you’re not seeing a ton of Medicare patients and billing the CMS for that volume, the act of reporting is not worth your or the CMS’ effort. To allow for that, the CMS defined a low volume threshold, which is exceeded if a provider:

  • Bills more than $90,000 for Medicare Part B covered professional services, and

  • Sees more than 200 Medicare Part B patients, and

  • Provides more than 200 covered professional services to Medicare Part B patients.

MIPS-eligible clinician-type

Historically, certain clinician types and special statuses (detailed here) were exempt from reporting Promoting Interoperability data via MIPS:

Source (2023 Performance Year Promoting Interoperability Requirements)

This is changing in 2024, though. Only clinical social workers remain as an excluded clinician type:

Similar to the situation in the inpatient world, the CMS also enumerates a few exceptions that exempt providers from needing to report MIPS Promoting Interoperability measures:

The last point about lack of control exists in MIPS but not in Medicare PI because an individual provider may not have the authority or decision-making about the choice of their EHR if they are part of a larger practice. In this case, the CMS allows them to avoid being penalized for choices out of their control.

Enrollment Period

The most straightforward piece is just that providers are only eligible when they can be fully measured. MIPS eligibility starts on the first of the year, so providers that enroll in Medicare mid-year aren’t required to report (but may do so voluntarily).

Summary

Looking at all these factors, we get this very simple, straightforward, deeply intuitive decision tree:

To fully recap and bring it all home:

  • Medicare Promoting Interoperability Criteria

    • Certified EHR

      • Base EHR

      • Family health history, PHI capture, measure calculation, and CQM functionality

    • Medicare Promoting Interoperability Measures

      • Clinical information reconciliation and incorporation

      • Electronic prescribing

      • View, download, and transmit to 3rd party

      • Transmission to immunization registries

      • Transmission to public health agencies — syndromic surveillance

      • Transmission to public health agencies — reportable laboratory tests and value/results

      • Transmission to public health agencies — electronic case reporting

      • Transmission to public health agencies — antimicrobial use and resistance reporting

    • Health IT Module Certification criteria

      • Privacy and Security

      • Dependent Criteria

  • Traditional MIPS Promoting Interoperability Criteria

    • Certified EHR

      • Base EHR

      • Family health history, PHI capture, measure calculation, and CQM functionality

    • MIPS Promoting Interoperability Measures

      • Clinical information reconciliation and incorporation

      • Electronic prescribing

      • View, download, and transmit to 3rd party

      • Transmission to immunization registries

      • Transmission to public health agencies — electronic case reporting

    • Health IT Module Certification criteria

      • Privacy and Security

      • Dependent Criteria

  • Traditional MIPS Promoting Interoperability Criteria

    • Certified EHR

      • Base EHR

      • Any additional criteria in the specific APM

    • MIPS Promoting Interoperability Measures

      • Clinical information reconciliation and incorporation

      • Electronic prescribing

      • View, download, and transmit to 3rd party

      • Transmission to immunization registries

      • Transmission to public health agencies — electronic case reporting

    • Health IT Module Certification criteria

      • Privacy and Security

      • Dependent Criteria

ONC Certification Hot Takes

We’ve zoomed in to a tremendous level of detail on what EHR certification is and who it affects, but facts, even simplified, are only so interesting. Analysis and opinions are why you are all here, so let’s stray a bit from God’s light (the federal government regulations), read between the lines a bit for some takeaways, and make some predictions.

  1. The removal of Medicaid means some specialties and their EHRs just don’t care anymore

While Medicare encompasses a broad swathe of specialties, it specifically excludes non-medically necessary dental and vision care:

What a nice advertisement by the CMS for MA plans

This differs a bit from Medicaid, where:

  • States must provide dental care to children and can optionally provide dental care to adults (with all states but the exceeding random trio of Alabama, Delaware, and Maryland providing some level of coverage)

  • Eye exams, eyeglass frames, and lenses are available for children under 21 under the Early and Periodic Screening, Diagnostic, and Treatment (EPSDT) program and 33 states include vision as a benefit

As noted earlier, the Medicaid portion of the Promoting Interoperability program ended in 2021. So it’s unsurprising to see that many dental and vision EHRs have let their certifications lapse:

Fun fact - it is written into the dentistry bylaws that all dentistry EHRs need to include “Dent” in their name, but Eaglesoft uses a little-known loophole that their software is literally 30+ years old

  • Although a few EHRs dropped off from 2014 to now, optometry and ophthalmology-specific EHRs fare a bit better here, with major players like RevolutionEHR, ModMed EMA, and Eyefinity all certified including (g)(10).

The example of dentistry (and to a lesser extent, optometry) shows that the contours and boundaries of the CMS programs do affect vendors’ choices to certify or not.

If you believe that the burden of regulation is a moat against disruption, it logically feels like there’s an opportunity to prove this out with EHRs for these specialties that don’t have certification requirements. The dental and ophthalmology EHRs are pretty mediocre, so go forth and disrupt, young padawan.

  1. Providers and specialty EHR vendors need to pay attention to shifts in MIPS eligibility

The CMS is increasingly looping more and more providers into the certified EHR realm by removing them as exempted provider types. As mentioned before, several specialties were previously exempted, but are included this year and onward.

  • Physical therapists

  • Occupational therapists

  • Qualified speech-language pathologists

  • Qualified audiologists

  • Clinical psychologists

  • Registered dieticians or nutrition professionals

These provider types are also the ones that often have software that’s not the big, generalized EHRs (Epic, Cerner, athenahealth, etc) and instead hyper-specific to their specialty:

It will be interesting to track how EHRs serving these niches handle certification, given that those services are reimbursed under Medicare Part B.

  1. Tech-enabled practices and virtual care companies need to think strategically as they build on a headless or decoupled EHR

The headless EHRs can support elements of CEHRT, but they do not provide fully certified solutions out of the box. For example, Medplum and Aidbox are both compliant with data-oriented criteria like (b)(10)’s EHI Export or (g)(10)’s FHIR API but aren’t certified against any other criteria.

Thus, if you choose to build on top of a headless EHR and are hoping to participate in MIPS, you’ll need to ensure you fully meet the CEHRT requirements via a combination of your in-house technology and other off-the-shelf solutions.

Similarly, decoupled EHRs like Canvas Medical, Healthie, or Elation range between “almost a base EHR, but needing a Direct messaging partner for (h)(1)” and “certified EHR”, but still require additional certified products for functionalities related to MIPS Promoting Interoperability measures. These vendors typically have preferred partners or complementary vendors that fill those gaps, so make sure to engage your support team to understand their recommended approach here.

  1. Renewed legislative activity to strengthen and expand regulatory authority here could be beneficial for the ecosystem and innovation

There’s a popular take that Meaningful Use was a mistake. The logic goes that the EHR certification program encouraged the adoption of bad technology, in that the software it forced providers to adopt was different from the digital tools they really needed. It argues that the available software at the time was immature and not ready to cross the chasm, but that the tailwinds foisted it upon doctors in a way that now makes it impregnable to disrupt. Thought leaders opine that the current EHR landscape is one of regulatory capture. I find it all particularly tired and misguided.

Looking at the criteria in EHR certification now, it largely lines up with the criteria a modern practice or hospital needs. The criteria are either super basic table stakes (like electronic order entry or the ability to record demographics) or capabilities that the government wants to see at scale (the ability to send data between providers, the ability to report for public health, etc). While it does represent a bar that any competing software has to clear to full displace the incumbent, these are things you will ultimately need to do anyway if you want to make a competing EHR.

Whether they know it or not, startups and other innovators in healthcare actually pine for more, not less, regulation. Digital applications constantly ask for a uniform set of capabilities to connect to EHRs. One path to that outcome is outright and complete dominance by one or two EHR platforms (akin to iOS and Android). Barring that, the EHR certification program is the main mechanism to enforce consistency across a disparate and fragmented landscape. As seen with our dental example, software vendors that are not regulated do not opt to voluntarily expose capabilities, especially standards-based exchange mechanisms. The expansion of regulatory agency authority (such as the aforementioned Behavioral Health Information Technology Coordination Act) to include broader types of providers or even ancillary applications, such as the picture archiving and communication system (PACS), is necessary to promote uniformity.

Tried to fit the impending Chevron Doctrine decision into the meme, but had to leave some things on the cutting room floor

  1. AI companies better pay attention

I didn’t want to dive into the specifics of each criteria in this post, but given no good post can do numbers these days without an AI mention, I think it is important to link to my recent post about Decision Support Interventions (b)(11):

This is a taste - there’s more. If you think it’s salient to you, click the link

“Technology that supports decision-making based on algorithms or models that derive relationships from training data and then produce an output that results in prediction, classification, recommendation, evaluation, or analysis” covers a lot of ground. While the ONC reined in the software explicitly regulated by this in the transition from proposed to finalized rule, it’s still worthwhile for generative AI startups to understand this provision (and perhaps pursue it voluntarily).

As phonetically close as AI is to API, I am still distinctly in amateur status for the former. That being said, it feels like these constraints around sourcing, authorship, equity, and more will be challenging for startups not running their own models.

Conclusion

With that, we’ve done it. We’ve mapped the labyrinth (nearly two decades of overlapping rules), rescuing our baby brother (operating margin) from the clutches of the metaphoric Goblin King (CMS downward payments). We’ve hopefully saved our heroes (your company’s product team) from wandering aimlessly and wasting valuable time.

If you’re an EHR vendor or tech-enabled practice who’s newly considering certification and feeling a bit overwhelmed, feel free to reach out to Brendan and the HTD team:

Contact!

Previous Resource
AI Revenue Intelligence Market Map: Turning revenue insights into millions in savings
Similar Resource
Headless EHRs: A Primer
Next Resource
AI Denials Management Market Map: Recovering lost revenue with robots?
Elion
Subscribe to get our latest insights and research
CategoriesResourcesCareers
LinkedInFollow us on LinkedInXFollow us on X
©2024 Elion, Inc. All rights reserved.
Terms of UsePrivacy Policy