ONC certification is voluntary in name only. It requires proving conformance to specific certification criteria through ONC-Authorized Testing Lab evaluation and an ONC-Authorized Certification Body decision, then maintaining that status through ongoing surveillance and disclosures. Skip it, and most hospital systems, health plans, and federal programs simply won't buy your product.
TL;DR:
- The certification process is complex, requiring detailed scope definition, testing with authorized labs, and continuous surveillance to maintain eligibility.
- Certification criteria are outcome-based, focusing on capabilities rather than code implementation, and standards versions prime influence ongoing compliance.
- Certification timelines range from weeks to several months, depending on scope, with internal costs often surpassing testing fees due to engineering and documentation efforts.
- Certification readiness should align with customer needs, emphasizing clinical and regulatory sequencing, not just technical compliance.
- Failing to incorporate maintenance and surveillance processes from the start risks losing certification status and market access, despite its nominal voluntary nature.
Table of Contents
- What Is the ONC Health IT Certification Program?
- Certification Criteria, CCGs, and Standards Versioning
- How Does the ONC Certification Process Work?
- Conditions and Maintenance: Certification Never Really Ends
- What Are the API and Cures Act Requirements?
- Readiness Checklist: Timeline and Cost Planning
- How Should Health IT Teams Prepare for Certification?
- A Founder's Take on Certification Strategy
- How The StartupMD Helps Health IT Teams Get Certification-Ready
- Sources
- FAQ
What Is the ONC Health IT Certification Program?
The ONC Health IT Certification Program is a voluntary, third-party conformity assessment scheme. It confirms that health IT meets the technological, functional, and security requirements adopted by the Department of Health and Human Services. Nobody forces a developer to enter it.
Market forces do the forcing instead. Hospital procurement teams screen out uncertified products before a sales call even starts, and CMS ties its Promoting Interoperability Program to certified technology, which means providers chasing those incentive payments need certified systems in their stack. That single dependency turns a "voluntary" program into a de facto gate for enterprise health IT sales.
Program scope shifts with each federal rulemaking cycle. Recent Final Rules on Health Data, Technology, and Interoperability have added algorithm transparency requirements and adjusted existing criteria, so a certification strategy built for one edition can go stale fast. Before scoping a certification effort, confirm you're building against:
- The current certification criteria set, not a prior edition's list
- The most recent Final Rule amendments affecting your product category
- Any transition timelines ONC has published for retiring older criteria
Certification Criteria, CCGs, and Standards Versioning
Certification criteria are outcome-focused rules. Rather than dictating exact code, ONC's certification criteria define what a Health IT Module must be capable of doing, then leave the implementation to the developer. A criterion might require that a system record, change, and access demographic data in a specific structured format, without specifying the database architecture behind it.
Certification Companion Guides fill the gap between the rule text and the test. Each CCG breaks a criterion into plain-language expectations, clarifies edge cases, and points to the exact test method ONC-ATLs will use. Skipping CCG review before testing is one of the fastest ways to fail an evaluation on a technicality.
Statistic Callout: Federal rulemaking has repeatedly expanded and revised the certification criteria set since the program launched, which is why teams that certified three or four years ago often find their scope has shifted under updated Final Rules.
Standards Versioning also matters more than most product teams expect. The Standards Version Advancement Process (SVAP) lets developers adopt newer versions of standards like FHIR without waiting for a full rulemaking cycle, but it also means "certified" isn't a fixed state. Common criterion families you'll encounter include:
- Privacy and security (encryption, audit logs, authentication)
- API access and data exchange (FHIR-based interoperability)
- Accessibility and usability testing
- Safety-enhanced design for clinical decision support
How Does the ONC Certification Process Work?
Getting a Health IT Module certified follows a defined sequence, and skipping steps out of order usually backfires. Here's the operational path:
- Scope the module. Identify exactly which certification criteria apply to your product's functionality, not the full catalog ONC publishes.
- Engage an ONC-Authorized Testing Laboratory. ONC-ATLs run the approved test tools and methods against each criterion in scope.
- Prepare test artifacts. Assemble documentation, test environments, and sample data that demonstrate the required capabilities under real conditions.
- Submit to an ONC-Authorized Certification Body. The ONC-ACB reviews the ATL's test results and issues the formal certification decision.
- Get listed on the CHPL. Once certified, your product appears on the Certified Health IT Product List, the public registry buyers and auditors check.
- Expect ongoing surveillance. ONC-ACBs conduct in-the-field and randomized surveillance after certification, and a complaint or a detected nonconformity can trigger a targeted review.
Each ONC-ACB sets its own intake process and fee schedule, so the exact paperwork varies by body even though the criteria don't.
Conditions and Maintenance: Certification Never Really Ends
Certification isn't a one-time stamp. It's a continuous compliance obligation, and treating it like a project with a finish line is where most teams get into trouble.
ONC-ACBs run ongoing surveillance programs that can be triggered by complaints, random sampling, or evidence of a product change that affects certified capabilities. When surveillance finds a nonconformity, the ACB issues a corrective action plan with a deadline. Fail to remediate, and certification can be suspended or terminated outright, which knocks your product off the CHPL and out of eligible procurement lists overnight.
Mandatory disclosures compound the workload. Developers must publish accurate information about fees, limitations, and any additional types of costs a customer might incur to fully use a certified capability. Key operational obligations include:
- Keeping CHPL disclosure statements current whenever product functionality changes
- Documenting and publishing any known limitations tied to a certified capability
- Responding to ACB surveillance requests within the timelines the ACB specifies
- Maintaining internal records that prove conformance, not just a memory of passing the original test
Pro Tip: Build a quarterly internal audit against your own CHPL listing. If your product roadmap has drifted from what's publicly disclosed, an ONC-ACB surveillance request will find that gap before you do.
What Are the API and Cures Act Requirements?
Certified API developers carry the heaviest ongoing burden in the entire program, largely because the Cures Act pushed the program toward open, transparent data access. The API Conditions require far more than passing a test once.
Business and technical documentation, including full fee disclosures and the app registration process, must be published publicly and kept current. Operational timelines are specific and unforgiving:
- Verify third-party app authenticity within a specified number of business days of a request
- Enable production registration for a verified app within a short timeframe after verification
- Maintain a service base URL directory so apps can discover your FHIR endpoints without manual coordination
Statistic Callout: Those operational windows for authenticity verification and production registration are fixed obligations under the API Conditions and Maintenance of Certification Fact Sheet, and missing them repeatedly is a common surveillance trigger.
Readiness Checklist: Timeline and Cost Planning
Certification effort scales with scope, not company size. A small module adding one or two criteria moves faster than a full platform certification, and planning around realistic bands avoids blowing your launch date.
- Run a gap analysis first. Compare your current product against the CCGs for every criterion you plan to pursue, focusing early on privacy and security baselines.
- Test internally before the ATL does. Tools like the Inferno test kit let engineering teams catch FHIR conformance failures before paying for formal ATL testing.
- Budget for layered costs. ATL testing fees, ACB certification fees, internal engineering time, and documentation labor all add up separately, and the internal effort is usually the largest line item teams underestimate.
- Plan the timeline in bands. A single added criterion for an existing certified module can move in weeks to a couple of months; a first-time, platform-wide certification more realistically runs several months once documentation and remediation cycles are factored in.
Pro Tip: Run your HIPAA security risk analysis before, not during, ONC test prep. Overlapping the two efforts wastes engineering hours and duplicates evidence collection. Our guide to a defensible HIPAA risk assessment walks through the sequence.
How Should Health IT Teams Prepare for Certification?
Certification scope should follow your customers, not ONC's full catalog. If your buyers are hospital systems chasing Promoting Interoperability incentives, prioritize the criteria those programs actually reference before touching anything peripheral.
Map each certification criterion to a specific product roadmap owner, not a compliance folder nobody checks. Conditions and Maintenance obligations, CHPL disclosure accuracy, API terms publication, surveillance response protocols, need a named owner and a recurring calendar cadence, not a one-time launch checklist.
Bring in outside expertise when the gap is clinical credibility or regulatory sequencing, not just engineering hours. A few areas where advisory support consistently pays for itself:
- Translating clinical workflow requirements into testable certification scope
- Structuring CHPL documentation so it survives ACB surveillance
- Sequencing certification against fundraising or enterprise sales timelines, a topic covered in our healthcare SaaS go-to-market guide
A Founder's Take on Certification Strategy
Certification is a go-to-market decision disguised as a compliance task. I've seen founders treat it as an engineering checkbox, then get blind sided when maintenance obligations, not the initial test, consume their team's bandwidth a year later. Build the disclosure and surveillance response process into product operations from day one. Certify narrow and early for the criteria your actual buyers require, then expand scope only when a specific deal demands it.
— Paul Bergeron MD, MBA
How The StartupMD Helps Health IT Teams Get Certification-Ready
Most healthcare SaaS teams don't fail certification because of a testing tool. They fail because nobody translated the regulatory requirements into a product roadmap before the sales team promised a hospital system a launch date.
The StartupMD works with healthcare SaaS founders and executives on exactly that translation. Through fractional Chief Medical Officer engagements, and advisory support, we help teams run gap analyses against certification criteria, structure CHPL documentation so it holds up under ONC-ACB surveillance, and sequence certification scope against enterprise sales and fundraising timelines. Our team brings extensive combined medical and business experience to that work, which matters most when a criterion touches clinical workflow and your engineering team needs a clinician's read on what "outcome-focused" actually means in practice. If your product roadmap references ONC certification but nobody owns the maintenance obligations that follow it, that's a gap that should be addressed with appropriate clinical leadership support. Review our advisory and fractional consulting services and request a readiness conversation to scope what your certification effort actually requires.
Sources
- About the ONC Health IT Certification Program - ONC
- Certification Process - ONC
- Promoting Interoperability Program — CMS
FAQ
What Are the Requirements to Get ONC Certified?
A developer must conform to applicable certification criteria, complete testing through an ONC-Authorized Testing Laboratory, and receive a certification decision from an ONC-Authorized Certification Body before appearing on the CHPL.
How Long Does ONC Certification Take?
Adding a single criterion to an already-certified module can take weeks to a couple of months; a first-time, platform-wide certification more typically runs several months once gap analysis and remediation are included.
How Much Does ONC Certification Cost?
Costs vary by ONC-ACB fee schedule, ATL testing fees, and criteria scope, but internal engineering and documentation effort is usually the largest cost driver, not the testing fee itself.
What Does It Mean to Be ONC Certified?
It means an ONC-Authorized Certification Body has confirmed, through ONC-ATL testing, that a Health IT Module conforms to specific federally adopted certification criteria, and that the developer has committed to ongoing Conditions and Maintenance obligations to keep that status.
Is ONC Certification Mandatory?
Certification itself is voluntary, but many federal programs, including CMS's Promoting Interoperability Program, and most enterprise healthcare buyers effectively require it for market access.