ONC certification is one of those topics where the most valuable advice comes before the roadmap: figure out whether you actually need it. For some custom EHRs, certification is essential; for many others, it is an expensive answer to a question nobody asked. If you do need it, the path is structured and demanding, with specific technical criteria, formal testing, accredited certification bodies, and ongoing obligations after you are certified. This guide walks through the threshold question, how the program works, the criteria a custom EHR has to meet, and a practical step-by-step roadmap — written to help you both decide and execute.
A note on scope: this is an educational overview, not legal or regulatory advice. We provide the engineering to build a custom EHR to the certification criteria and prepare it for testing; the certification itself is granted by an accredited body, the attestations are yours, and whether you need certification at all is a determination for your organization and its compliance advisors. The program is administered by ONC (now organized under ASTP/ONC); we use “ONC” throughout as it is commonly known.
First: Do You Even Need ONC Certification?
This is the question that saves the most money, so it comes first. ONC certification is voluntary in itself — what makes it necessary is participation in certain programs that require Certified EHR Technology (CEHRT), most notably the Medicare Promoting Interoperability programs and the Promoting Interoperability performance category of MIPS. If the providers using your custom EHR need to attest in those programs, your software generally needs to be certified to the relevant criteria. If they do not — for example, a specialty system used in a context that does not require CEHRT, or a clinical product whose users have no such program obligation — certification may be unnecessary, and pursuing it would be a significant cost for no benefit.
So the honest starting point is to determine, with your compliance advisors, whether your users’ programs require certified technology. Build the certification effort only if the answer is yes. We have seen organizations assume they need certification when they do not, and the reverse, so this determination is worth doing carefully rather than by default. Our ONC certification services start exactly here.
How the ONC Certification Program Works
If you do need it, here is the structure. The certification criteria are defined in federal regulation (45 CFR Part 170), and the current edition is aligned with the ONC Cures Act Final Rule — the “Cures Update” criteria — which modernized the program around standardized data and APIs (see our overview of 21st Century Cures Act compliance). Certification is modular: you certify to the specific criteria relevant to your product’s functions, not to a single monolithic standard, so a custom EHR is certified against the set of criteria that match what it does.
The mechanics involve accredited third parties. ONC-Authorized Testing Labs (ONC-ATLs) test your software against the criteria, and ONC-Authorized Certification Bodies (ONC-ACBs) issue the certification. Certified products are published on the public Certified Health IT Product List (CHPL). Testing uses defined tools and test procedures — for the FHIR-based API criteria, ONC’s Inferno test suite is central. The key point for a builder: certification is granted by these accredited bodies, not by your development partner; we build and prepare the software to pass, and the ATL and ACB do the testing and certifying.
Key Technical Criteria a Custom EHR Must Meet
The criteria you target depend on your product’s functions, but several are central to the modern, Cures-aligned program. USCDI — the United States Core Data for Interoperability — defines the standardized data classes and elements your system must support, and its versions evolve over time, so building to the currently required version matters. The standardized FHIR-based API criterion (commonly referenced as (g)(10)) requires a FHIR API built to US Core, SMART App Launch for authorization, and FHIR Bulk Data for population-level access — this is one of the most technically demanding criteria and central to the Cures Update. Beyond these, criteria cover areas such as clinical data capture and exchange, security and access, and others depending on your functions. Much of this rests on solid FHIR engineering — see our FHIR API development practice — which is why a custom EHR pursuing certification needs genuine interoperability depth, not just clinical features.
Conditions and Maintenance of Certification
Certification is not a one-time event; it comes with ongoing obligations. The program’s Conditions and Maintenance of Certification include commitments such as attesting to the information blocking condition (not engaging in information blocking — see our information blocking compliance work), meeting API conditions including reasonable and transparent terms, and participating in real-world testing that demonstrates your certified capabilities function in production settings. These are continuing responsibilities, which means certification is a commitment to maintain conformance over time, not a badge you earn once. Budgeting for the ongoing maintenance — re-testing as criteria and USCDI versions update, real-world testing, and attestations — is part of doing this properly.
A Practical Certification Roadmap
Determine Whether You Need Certification
With your compliance advisors, confirm whether your users’ program obligations require certified technology. Proceed only if they do.
Scope the Target Criteria
Identify the specific certification criteria that match your product’s functions, so you certify to the right set rather than over- or under-scoping.
Build to the Criteria
Engineer the software to meet each target criterion — USCDI data support, the standardized FHIR API (US Core, SMART, Bulk Data), security, and the rest — ideally designing to the criteria from the start rather than retrofitting.
Pre-Test Internally
Test against the criteria using the program’s tools, including Inferno for the FHIR API criteria, to find and fix gaps before formal testing.
Engage an ONC-ATL and ONC-ACB
Work with an accredited testing lab to formally test, and an accredited certification body to certify, the conforming criteria.
List on the CHPL and Maintain
Once certified, your product is listed on the CHPL. Then maintain conformance — real-world testing, attestations, and re-testing as criteria and USCDI versions evolve.
Cost and Effort Realities
Certification is a meaningful investment of both engineering and time, concentrated in building to the technical criteria (the FHIR API criterion especially), the testing and certification process, and the ongoing maintenance afterward. We model the effort conceptually with you rather than quoting figures, because it depends entirely on which criteria you target and how close your existing software already is. The honest framing is that certification is a real program, not a checkbox — which is exactly why determining whether you need it (step one) matters so much, and why pursuing it without a genuine requirement is a costly mistake.
The Honest Boundaries
It is worth being explicit about who does what. We provide the engineering — building your custom EHR to the certification criteria and preparing it to pass testing, including the FHIR API and USCDI work. The testing and certification themselves are performed by accredited ONC-ATLs and ONC-ACBs, not by us. The attestations that come with certification are made by your organization. And the determination of whether you need certification rests with you and your compliance advisors. A partner who claims to “certify” your EHR themselves, or who guarantees a certification outcome, is misrepresenting how the program works; the credible role is building and preparing the software and working alongside the accredited bodies and your compliance team.
How Taction Helps
We build custom EHRs and clinical systems to ONC certification criteria and prepare them for testing — engineering the USCDI data support, the standardized FHIR API (US Core, SMART App Launch, Bulk Data), security, and the other target criteria, and pre-testing with tools like Inferno to find gaps before formal testing. We work alongside the ONC-ATL and ONC-ACB who test and certify, and alongside your compliance advisors who own the need-determination and attestations. With deep FHIR and healthcare engineering experience and ISO 27001-certified security, we make the readiness path as smooth as the program allows. Our ONC certification services and custom EHR development practice cover the full picture, within our broader healthcare software work.
Related reading: Custom EHR vs. Epic & Cerner: When Custom Makes Sense · EHR Migration: How to Move Off a Legacy System
Frequently Asked Questions
Does my custom EHR need ONC certification?
Only if the providers using it need certified technology for a program that requires CEHRT, such as the Medicare Promoting Interoperability programs or the MIPS Promoting Interoperability category. If your users have no such obligation, certification may be unnecessary. Determine this with your compliance advisors before investing, because pursuing certification without a genuine requirement is a costly mistake.
What are the most demanding criteria to meet?
The standardized FHIR-based API criterion (often referenced as (g)(10)) is among the most technically demanding, requiring a FHIR API built to US Core, SMART App Launch authorization, and FHIR Bulk Data, alongside full USCDI data support. These require genuine interoperability engineering, not just clinical features.
Who actually certifies the software?
Accredited third parties do: ONC-Authorized Testing Labs test the software against the criteria, and ONC-Authorized Certification Bodies issue the certification, after which the product is listed on the public CHPL. A development partner builds and prepares the software to pass; it does not grant certification itself.
Is certification a one-time thing?
No. It comes with Conditions and Maintenance of Certification — including information blocking attestation, API conditions, and real-world testing — and you must maintain conformance as criteria and USCDI versions evolve. Budget for the ongoing maintenance, not just the initial certification.
Can a vendor guarantee we’ll get certified?
No credible vendor can guarantee a certification outcome, because certification is granted by accredited bodies through formal testing. A partner can build to the criteria, pre-test thoroughly, and maximize your readiness, but claiming to guarantee certification or to certify the software themselves misrepresents how the program works.
How long does it take?
It depends on which criteria you target and how close your software already is, so the timeline varies widely. The bulk of the effort is engineering to the criteria — especially the FHIR API — and the formal testing and certification process. We scope a realistic timeline against your specific target criteria during planning.
Building a custom EHR that may need ONC certification? Schedule a free consultation →
This article is an educational overview, not legal or regulatory advice. Reviewed by Taction Software’s healthcare engineering team. ISO 27001-certified information security management. Certification is granted by accredited bodies; need-determination and attestations rest with your organization and compliance advisors.
