Here is something that surprises many health IT developers: The Assistant Secretary for Technology Policy and the Office of the National Coordinator for Health Information Technology (ASTP/ONC) does not actually certify your product. It does not test it either.
This is not a minor procedural detail. It forms the structural foundation of the entire ONC Health IT Certification Program. ASTP/ONC sets the regulatory framework and defines the requirements for certified health IT. Once those requirements are established, federally authorized organizations then conduct testing and issue certifications, while CMS determines whether the use of certified technology qualifies providers for federal incentive programs.
These are independent roles performed by independent entities. They intersect, but they are not interchangeable. When developers blur these lines, confusion follows. Questions are directed to the wrong authority. Deadlines are misunderstood. Assumptions are made about who controls what.
Understanding the division of responsibility is not just helpful context, it is the starting point for navigating the program with clarity and confidence.
How the Program Is Structured
The ONC Health IT Certification Program is intentionally structured as a layered oversight model. Each layer serves a defined function, and each organization participates under specific authorization.
At the accreditation level, an ONC-Approved Accreditor evaluates and accredits certification bodies. Separately, the National Voluntary Laboratory Accreditation Program, administered by NIST, accredits testing laboratories. Accreditation verifies that these organizations operate competently and in accordance with the required standards.
However, accreditation alone is not sufficient. After accreditation, organizations must apply to ASTP/ONC for formal authorization to participate in the program. Once approved, they become ONC-Authorized Testing Laboratories (ONC-ATL) and ONC-Authorized Certification Bodies (ONC-ACB).
From a developer’s perspective, the path through this structure is sequential and procedural.
First, a product is submitted to an ONC-ATL for testing. The testing laboratory evaluates whether the product conforms to the applicable certification criteria and technical standards defined by ASTP/ONC. Testing is structured, evidence-based, and documented.
If the product successfully meets the testing requirements, the developer then engages an ONC-ACB. The certification body reviews the testing documentation, verifies that all program requirements have been satisfied, and issues the official certification decision. Only at that point is the product considered ONC certified and eligible to be listed on CHPL.
One organization may hold authorization as both an ONC-ATL and an ONC-ACB, provided it maintains a strict internal separation between testing and certification functions. This organizational firewall ensures independence of decision-making.
What ASTP/ONC is Responsible For
The ASTP/ONC operates through the standard federal rulemaking process. It publishes a Notice of Proposed Rulemaking, solicits and reviews public comment, and ultimately issues a final rule on behalf of the HHS Secretary. That final rule becomes binding and defines what certified health IT must be capable of doing in order to meet federal requirements.
Recent rulemaking efforts, including HTI-1 through HTI-4, have expanded the program’s scope. These updates have addressed interoperability mandates, API requirements, algorithmic transparency expectations for AI-driven decision support tools, electronic prior authorization, and evolving standards version adoption. Each rule does not simply add technical requirements. It reshapes the compliance landscape developers must navigate.
ASTP/ONC also maintains the Certified Health IT Product List ( CHPL). CHPL is the public-facing database of certified products. It functions as more than a static registry. It serves as a transparency mechanism for the market. Each listing identifies the certification criteria met, the testing laboratory involved, the certifying body, surveillance history, and any corrective action plans opened or resolved. Providers, compliance officers, competitors, regulators, and the public at large can view this publicly available information.
If ASTP/ONC determines that a certified product may pose a serious risk to public health or safety, it has Direct Review authority. Through Direct Review, the agency can independently evaluate the product and intervene if necessary. This authority exists as a safeguard. It is not the routine oversight mechanism that governs day-to-day compliance activities.
For developers, the practical impact of this structure is significant. Healthcare providers who use certified products may qualify to participate in the CMS Promoting Interoperability program. That program connects the use of certified health IT to incentive payments and, in certain circumstances, payment reductions. Certification is therefore not a symbolic designation. It directly influences the financial and regulatory position of your customers.
If a product is not certified, providers cannot rely on it to meet federal program requirements. That reality shapes purchasing decisions.
The ongoing administration of testing and certification, however, does not sit with ASTP/ONC alone. That responsibility is delegated to authorized organizations operating under federal oversight.
What an ONC-ACB Is Responsible For
Certification does not conclude when a certificate is issued. It marks the beginning of an ongoing oversight relationship.
Once an ONC-ACB certifies a product, it assumes responsibility for monitoring continued compliance. Federal requirements mandate surveillance activities designed to confirm that certified health IT continues to meet certification criteria outside of a controlled testing environment. In other words, compliance must hold up in real-world production use.
Surveillance activities can take multiple forms. Some are randomized and scheduled. Others are reactive, triggered by complaints, reported issues, or identified risks. The purpose is to ensure that certified functionality remains accurate, reliable, and consistent with program requirements over time.
If nonconformities are identified, the ONC-ACB notifies the developer and works collaboratively to establish a corrective action plan. The developer is responsible for remediation within defined timeframes. If deficiencies are not corrected, the ONC-ACB has authority to suspend or withdraw certification. These decisions are formal regulatory actions with public visibility through the CHPL.
In addition to surveillance, ONC-ACBs support developers in maintaining compliance with Conditions and Maintenance of Certification requirements. These include annual Real World Testing plans and published results, semiannual attestations due in April and October, and participation in the Standards Version Advancement Process when ASTP/ONC adopts newer standard versions. These are not optional administrative tasks. They are ongoing obligations tied to maintaining an active certification.
It is equally important to understand what an ONC-ACB does not do. An ACB does not create certification criteria. It does not determine which criteria apply to federal incentive programs. It does not publish or control the CHPL website. Those responsibilities remain with ASTP/ONC. Likewise, CMS determines whether a provider’s use of certified health IT qualifies for incentive payments.
Clear role boundaries protect the integrity of the program. They also prevent misplaced expectations during certification engagements.
Where Drummond Fits
Drummond operates within this framework as both an ONC-Authorized Testing Laboratory and an ONC-Authorized Certification Body. The organization is authorized by ASTP/ONC to perform testing and certification under the same program while maintaining the required internal firewall between those functions.
Practically speaking, Drummond’s involvement can span the full certification lifecycle. This includes initial conformance testing, certification review and issuance, Real World Testing support, SVAP updates, Conditions and Maintenance of Certification compliance oversight, and required surveillance activities. Developers engage directly with Drummond to interpret criteria, prepare evidence, respond to surveillance, and maintain certification in good standing as ASTP/ONC standards evolve.
What Drummond does not control are the regulatory levers themselves. It does not write certification criteria. It does not determine the timing or substance of ASTP/ONC rulemaking. It does not administer CHPL. It does not define CMS incentive eligibility rules. Those decisions remain federal functions.
Understanding that separation allows developers to align expectations appropriately. A certification engagement addresses conformance and ongoing compliance within the established framework. Broader regulatory change requires direct attention to ASTP/ONC and CMS activity.
Clarity on these roles is not academic. It is operational. And in a program where certification status directly affects market access, operational clarity matters.