For many health IT developers, ASTP/ONC certification is a major milestone, confirming that a product meets federal Health IT Certification Program requirements. What often surprises teams is how structured the path to that milestone actually is.
Testing follows defined procedures, requires specific evidence, and operates very differently from a typical development or QA workflow. Teams that understand this before they begin typically move through certification more efficiently. Those who treat it like a casual feature walkthrough often find themselves adding time they hadn’t planned for.
Inside the Certification Testing Process
The most common misconception among first-time participants is that certification testing is a feature demonstration, a chance to show what the product can do and explain anything that doesn’t go perfectly in the moment.
It isn’t. The proctor runs a defined test script. The developer performs required actions and provides the specified artifacts and evidence. The proctor verifies evidence against the certification criteria. That’s the sequence, and it doesn’t flex.
There is no partial credit. Each step must produce the required behavior and the required evidence. “Almost correct” isn’t a path forward; it’s a source of delays.
The proctor’s role is also more limited than most teams expect. Proctors can clarify how a test step works or what evidence is expected. They cannot walk a team through an implementation gap or explain how to build missing functionality.
Teams that understand this structure prepare accordingly: test environments configured in advance, workflows finalized, required artifacts ready before the session starts.
Three Knowledge Gaps That Catch Teams Off Guard
Across first-time certification engagements, three gaps consistently appear, regardless of how technically experienced the team is.
Confusing regulations with test procedures. The regulation defines what a product must do. The test procedures, tools, and required artifacts define how compliance is verified. They’re not the same document, and they don’t ask the same questions. Teams that focus only on the regulation often find the operational specifics of testing more demanding than expected. The proctor expects specific evidence, in a particular format, at a particular point in the workflow. Missing that detail slows the session.
Underestimating workflow completeness. Core functionality isn’t enough. Testing requires the complete end-to-end workflow: every required data element, user action, output, log, and edge-case behavior. A workflow that functions in 90% of scenarios but misses one critical step will fail. Everything must be demonstrable, not just functional.
Assuming “support” equals conformance. Supporting a standard like FHIR or generating CCDAs is a starting point, not a finish line. Certification testing verifies the correct version, the correct vocabulary, the proper structure, and that the product passes validation and test harness checks. The distance between claiming support and demonstrating verified conformance is where many teams spend unplanned time.
If You’re Prepared, How Long Does Certification Take?
Timelines depend on two factors: the number and complexity of criteria being tested, and how prepared the team is before testing begins.
For engagements that don’t require live testing, expect roughly two weeks from start to completion. For those requiring live testing, the process typically takes six months or more, though upcoming changes with HTI-5 may affect those timelines.
One consistent pattern: preparation before testing almost always shortens total duration. An extra week of focused preparation at the start typically saves more time than addressing gaps mid-session.
Most developers engage Drummond for both ATL testing and ACB certification as a combined process. While using separate testing laboratories and certification bodies is technically possible, it’s uncommon and duplicates legal agreements and cost structures without meaningful benefit.
The Compliance Lifecycle After Certification
For many developers, the biggest post-certification realization is that certification isn’t a finish line. It’s the beginning of a compliance lifecycle.
ONC-ACBs conduct ongoing surveillance. Certified developers must maintain recurring obligations: Real World Testing, semiannual attestations, and updates to align with evolving standards. These don’t ease up after year one. They’re continuous, and they require operational discipline.
What often catches teams off guard is not the list of tasks but more often how those tasks must integrate into everyday product operations.
Every product change, whether a minor bug fix or a major feature release, carries the risk of affecting certified capabilities. Teams that don’t embed certification awareness into their development, QA, and release workflows may encounter corrective actions or delays when gaps surface.
A few areas where this tends to become visible:
- Evidence access and knowledge continuity. Staff turnover or siloed knowledge can slow responses during surveillance or Real World Testing. Teams need processes that don’t depend on any one person.
- Real-world deployment variability. Variations in customer configurations or usage patterns can surface compliance issues that internal testing didn’t catch.
- Standards version updates. Changes to certification criteria often require teams to evaluate whether product updates trigger re-testing or attestation adjustments.
- Cultural mindset. Teams that treat certification as a one-time event rather than an ongoing obligation are more likely to face delays, corrective actions, or missed deadlines.
Sustaining certification requires the same discipline as the initial process demanded, integration into daily workflows, with clear processes for documentation, monitoring, and release management.
Working with Drummond
Certification is a structured, evidence-driven process, and the teams that move through it most efficiently are the ones that understand what to expect before they begin. Knowing how testing works, where preparation pays off, and what the compliance lifecycle requires afterward makes a real difference in how smoothly the experience goes.
Because Drummond serves as both ONC-ATL and ONC-ACB, developers work with a team that understands the full lifecycle—from initial testing through certification issuance and into ongoing surveillance. While the ATL and ACB teams operate independently from each other they both draw from deep Health IT expertise built across years of working in this space.
Certification is a milestone worth reaching, and with the right partner, it’s also the foundation for a compliance program that holds up over time. Drummond’s role doesn’t end when the certificate is issued. It’s built to support developers for as long as their product remains active in the market.