What it is
The ONC Certification and Compliance Checklist is a buyer-and-administrator guide for confirming that an EHR meets ONC certification requirements and supports the programs that depend on it — Promoting Interoperability, MIPS, and the Cures Act API and information-blocking rules. Its key reframe is that Certified Electronic Health Record Technology (CEHRT) isn't a one-time stamp: it ties to specific certification criteria, real-world testing, and attestation. The checklist helps you verify a product's certification, plan your eCQM reporting, and avoid information-blocking exposure.
The document is structured around certification verification, the key certification criteria to confirm, program-readiness questions, and a compliance-maintenance cycle. Verification starts concretely: confirm the product is listed on the ONC Certified Health IT Product List (CHPL) with its CHPL ID, verify it's certified to the current ONC criteria (the ONC Cures Act Update / §170.315) you actually need, check that the certified version matches what you'll deploy rather than an older listed build, and confirm the standardized FHIR API certification (§170.315(g)(10)) for patient and app access.
Beyond the certification stamp, the checklist drives at program readiness — the reason certification matters in the first place. It asks whether the certified version supports every eCQM you plan to report for MIPS or Promoting Interoperability, whether the EHR can produce a Security Risk Analysis trail and support HIPAA safeguards, whether the vendor enables rather than restricts standardized API and EHI access, and how certification updates are delivered and on whose schedule. The compliance-maintenance cycle reflects the reality that certification is ongoing, with real-world testing and update obligations that continue long after purchase.
What it's used for
Practices and administrators use this checklist to verify certification before purchase and to maintain program readiness after deployment. Because certification is a precondition for major incentive and reporting programs, getting it wrong has direct financial and regulatory consequences.
- ✓ Verifying the product is listed on the ONC Certified Health IT Product List (CHPL) with its CHPL ID, rather than trusting a vendor's certification claim.
- ✓ Confirming the EHR is certified to the current ONC criteria (Cures Act Update / §170.315) you actually need, not an outdated criteria set.
- ✓ Checking that the certified version matches the build you'll deploy, since a listed certification on an older version doesn't cover what you run.
- ✓ Confirming the standardized FHIR API certification (§170.315(g)(10)) so patient and third-party app access meets the Cures Act requirements.
- ✓ Planning eCQM reporting for MIPS and Promoting Interoperability by confirming the certified version supports every measure you intend to report.
- ✓ Confirming the EHR produces a Security Risk Analysis trail and supports HIPAA safeguards, tying certification to your broader compliance obligations.
- ✓ Establishing a compliance-maintenance cycle so certification updates, real-world testing, and attestation obligations are tracked over time rather than assumed handled.
Who uses it
ONC certification matters to the people responsible for buying the EHR, attesting to incentive programs, and staying clear of regulatory exposure, and the checklist coordinates their verification.
Context & good to know
ONC certification exists because federal incentive and reporting programs need a way to guarantee that an EHR can actually do what those programs require — exchange data, report quality measures, and provide standardized API access. Certified Electronic Health Record Technology (CEHRT) is the prerequisite for participating in MIPS and Promoting Interoperability, which is why verification belongs at the front of any EHR purchase. The most common and costly mistake is assuming a vendor's 'ONC certified' claim covers your situation, when in fact certification ties to specific criteria, specific versions, and specific real-world testing that you have to confirm match your needs.
The version-matching trap is subtle and expensive. A product can be listed on the CHPL with a valid certification while the build a practice actually deploys is an older or different version that doesn't carry that certification — meaning the organization could attest against technology that isn't actually certified for what it's running. The checklist's insistence on confirming the certified version matches the deployed build, and on locating the precise CHPL ID, exists to close this gap. The standardized FHIR API certification (§170.315(g)(10)) is singled out because it underpins the Cures Act's patient and app-access requirements and the information-blocking rules.
Certification is also not static, which is why the compliance-maintenance cycle is part of the checklist rather than an afterthought. The ONC program includes real-world testing and ongoing obligations, certification criteria evolve with updates like the Cures Act Update, and vendors deliver certification updates on their own schedules — meaning a practice that verified everything at purchase can drift out of readiness if it doesn't track updates and re-confirm eCQM support over time. Whether the certified product is Epic, eClinicalWorks, or Azalea Health, the practical posture is the same: verify rigorously on the CHPL up front, tie certification to your eCQM and HIPAA obligations, confirm the vendor enables rather than restricts EHI access, and maintain the verification on a recurring cycle.