Every EHR sales deck leads with the same line: “we’re ONC-certified.” For a practice comparing vendors, that phrase can sound like a stamp of overall quality — proof the system is good. It isn’t. ONC Health IT Certification, specifically the 2015 Edition Cures Update criteria, is a real and meaningful technical standard, but it tests a narrower set of things than most buyers assume, and it is silent on several of the factors that actually determine whether a system works for a small practice day to day. Knowing exactly what the certification covers — and what it leaves entirely up to the vendor — turns “ONC-certified” from a marketing line into a genuine evaluation criterion.
What ONC Certification Actually Tests
The 2015 Edition Cures Update certification, administered through ONC-Authorized Certification Bodies (ONC-ACBs), checks a defined set of technical capabilities rather than the software as a whole. Three areas matter most for a practice evaluating a vendor:
- USCDI data support. A certified EHR must support the United States Core Data for Interoperability (USCDI), a standardized set of health data classes and elements — patient demographics, clinical notes, medications, allergies, problems, procedures, laboratory results, and imaging reports — that forms the baseline for interoperable data exchange. This is what makes a chart portable between systems in a predictable, structured way, rather than as an unstructured PDF.
- Standardized API access. Under §170.315(g)(10), certified systems must expose standardized APIs for patient and population services using the HL7 FHIR Release 4 standard, built for “plug-and-play” interoperability. In practice, this is what lets a patient pull their own record into an app of their choosing at no cost, and what lets a practice’s other systems connect to the EHR without a costly custom integration for every connection.
- Information blocking rules. As a Condition and Maintenance of Certification, developers are prohibited from engaging in information blocking — practices likely to interfere with the access, exchange, or use of electronic health information. This is a compliance obligation on the vendor, not a feature toggle a practice configures.
These three requirements exist for a reason that lines up directly with how a statewide health information exchange actually functions: a chart is only exchangeable if the data underneath it is structured the same way everywhere, and the connection points are standardized rather than one-off. Certification is the mechanism that keeps a practice’s EHR from becoming an island.
What Certification Does Not Guarantee
This is where most vendor conversations go quiet, and where a buyer needs to keep asking questions. ONC certification says nothing about usability, total cost, or support quality. Early versions of the certification criteria were criticized for effectively “counting clicks” during Meaningful Use rather than evaluating how well a clinician could actually complete a task in the system — a critique that still applies to how narrowly today’s certification is scoped. A vendor can be fully certified and still ship a system that takes twice as long to chart in, prices modules a la carte in ways that balloon the real cost, or routes support tickets through a queue with a multi-day response time. None of that is covered by the ONC-ACB’s test.
| Covered by ONC Certification | Left Entirely to the Vendor |
|---|---|
| USCDI data classes supported | Day-to-day usability and clicks-per-encounter |
| FHIR-based API for patient/population access | Total cost of ownership and add-on module pricing |
| Information-blocking prohibition (Condition of Certification) | Support response time and quality |
| Baseline data exchange standards | Contract terms, data-export fees on termination |
Why It Matters for Connecting to a Health Information Exchange
For a practice planning to connect its EHR to a state or regional health information exchange, ONC certification is close to a prerequisite rather than a nice-to-have. The updated criteria — standardized APIs and USCDI support in particular — are what make it realistic for a system to exchange records with hospitals, labs, and other practices on a shared network rather than through a series of custom point-to-point connections. A practice that chooses an uncertified or outdated system will typically find out the hard way, mid-onboarding to an exchange, that the connection simply is not supported.
Why It Matters for CMS Promoting Interoperability and MIPS
Certification has a second, harder-edged consequence: it is a program requirement, not just a technical nicety. Eligible clinicians participating in CMS’s Promoting Interoperability program (formerly Meaningful Use) and in MIPS are required to use Certified Electronic Health Record Technology that meets the 2015 Edition Cures Update criteria. Providers who report on a system that isn’t certified to that edition risk financial penalties. Within the MIPS Promoting Interoperability performance category specifically, clinicians must use 2015 Edition Cures Update functionality for measures to count at all, and reporting includes attesting to the prevention of information blocking and completing a security risk analysis. A practice that skips verifying certification status before signing a contract can end up compliant on paper with a vendor’s marketing claims and non-compliant on the actual CMS submission.
How to Use This When Comparing Vendors
Certification status is a pass/fail gate, not a ranking criterion — use it to eliminate options, then evaluate everything else separately:
- Confirm the specific edition and criteria version (2015 Edition Cures Update, not an older certification that predates USCDI and the FHIR API requirement).
- Ask the vendor directly whether their §170.315(g)(10) API has been used in a live patient-facing or exchange connection, not just tested in a lab.
- Separately score usability, total cost including add-ons, and support SLAs — none of which certification measures.
- Ask what happens to data export and API access if the practice terminates the contract, since certification doesn’t govern exit terms.
- Confirm the vendor’s certification supports connection to the specific health information exchange the practice intends to join, since exchange participation agreements can have their own technical onboarding requirements beyond baseline ONC certification.
ONC certification is a real floor, not a ceiling. It tells a practice that the data will be structured correctly and the connection points will exist — it says nothing about whether the system is pleasant to use, affordably priced, or well supported once the contract is signed. Treating certification as the finish line rather than the starting point is one of the more common, and more expensive, mistakes practices make when choosing an EHR.