For many health IT developers, certification feels like the milestone, the point where the hard work pays off and the product is ready for market. In practice, that is where the ongoing work begins. ONC requires that certified capabilities hold up in real-world use, where workflows are less predictable, configurations vary, and the stakes are higher than any controlled test environment.
That’s where certification surveillance begins.
Surveillance follows a defined structure, with specific inputs, timelines, and decision points that determine how issues are surfaced, investigated, and resolved. Teams that understand this can prepare accordingly. Those that don’t risk delays and uncertainty they didn’t plan for.
Certification Triggers Surveillance
Surveillance begins after formal certification. Before issuing any new certificate, Drummond requires two key documents from the developer.
First, a Complaint Certification Information Review (CCIR) form detailing how the vendor handles customer complaints. This CCIR must highlight how the developer will address safety-related capabilities (e.g. drug-allergy checking, medication list management) that ONC deems high-priority.
Second, the developer must submit its mandatory disclosures, including any additional costs a user may incur to purchase certified capabilities and applicable API terms of use. These disclosures are recorded on the CHPL at listing time.
Developers are also required to provide API documentation supporting certified functionality. The Master Services Agreement (MSA) further obligates the developer to maintain a complaint log and cooperate with Drummond’s surveillance.
Surveillance is continuous, not just an annual check. A developer’s CCIR and disclosures form the foundation for later audits, but those documents may be updated over time. If a complaint arises, Drummond compares the developer’s actions against its current documented processes, disclosures, and certification obligations.
These foundations determine how every issue is surfaced and classified, whether it arrives as a complaint that demands investigation (reactive surveillance) or as a signal caught through ongoing monitoring (proactive surveillance).
Reactive vs Proactive Surveillance
Drummond’s surveillance falls into two modes.
Reactive surveillance is complaint or event-driven. When Drummond learns (via an end-user email or inherited certification request) of an issue, it must investigate.
Triggers include: an end-user complaint about a certified function; multiple inherited certification requests for the same product; a self-reported non-conformance; or a missed deadline such as a late attestation or RWT submission.
In each case, Drummond first assesses validity. Not every complaint leads to action.
Proactive surveillance is Drummond-initiated, looking ahead rather than reacting. Drummond regularly monitors its certified products by reviewing websites for proper ONC certification marks and required disclosures, making sure links associated with active CHPL listings are functional, ensuring quarterly and semi-annual attestations are filed on time, and checking RWT compliance.
Those attestation requirements are an important part of ongoing surveillance. Each quarter, developers must submit an Attestation of Adaptations and Updates identifying any changes made to certified products. Drummond reviews these submissions and may retest a product if an update could affect certified functionality.
In addition, developers must submit semi-annual attestations confirming compliance with all applicable Conditions and Maintenance of Certification requirements, including obligations related to information blocking and APIs.
On a schedule (at least annually per product), Drummond reviews a sample of certified products to confirm that mandatory disclosures and certification marks are properly displayed. Each product is classified as either “Compliant” or “Non-Compliant”.
Products classified as Non-Compliant are notified by email and given 10 business days to correct the issue; regardless of the nature of the deficiency. If no response is received within that window, Drummond follows up by phone. If no action is taken after follow-up, a Corrective Action Plan may be opened.
Drummond also reserves the right to retest any product when its quarterly attestation reports a change.
In short, proactive checks (routine site reviews, attestation monitoring, disclosure reviews, and compliance verification) help ensure certified products remain compliant over time, not just when a complaint arises.
Reactive actions (complaint investigations, ICS-triggered audits, etc.) take a deeper look when a specific issue, event, or circumstance requires additional review. Together, both approaches help ensure certified capabilities remain reliable over time.
Complaint Intake and Investigation Steps
If an issue arises that a developer cannot resolve directly with their customer, Drummond’s complaint process kicks in. When an end user contacts Drummond or ONC (which will refer it back to the ACB), Drummond follows a formal workflow:
- Initial Screening: Drummond logs the complaint and confirms it pertains to certified functionality. Drummond then clarifies details by contacting the complainant and the developer. If needed, Drummond helps set up a direct discussion between the user and vendor to attempt an immediate resolution (which often happens).
- Evaluation: If the issue persists, Drummond evaluates whether it “has merit” i.e. it potentially violates a certified criterion. This involves reviewing the complaint against the product’s certification scope.
- Investigation: When justified, Drummond launches a thorough investigation. Staff works with all relevant personnel (users, vendors, testers) and examines logs, screenshots, and workflows. They verify what was certified and how the product is supposed to behave. They also review the developer’s complaint handling: Drummond compares what happened to the process in the developer’s CCIR and complaint log. The aim is to determine if a non-conformity within scope of certified functionality has occurred.
- Field Testing (if needed): If the problem cannot be replicated in a lab, Drummond may perform in-the-field testing at a client site. Observers follow real clinical workflows, using realistic (or fictitious) patient data. This may include gathering end-user feedback or capturing screenshots. Drummond also checks whether PHI appears during testing; it may see PHI under HHS oversight rules (45 CFR 164.512(d)) but never records it. Field testing focuses on the reported issue, but may include related prioritized criteria.
- Closure Criteria: A complaint is not considered closed until Drummond verifies the user is satisfied with the resolution. If no response is received from the user within a reasonable timeframe, the complaint may be closed on that basis. If no non-conformity is found, Drummond documents this outcome and reports it in its surveillance report, and no CAP is issued. The user can still escalate to ONC if unsatisfied. If a non-conformity is identified, Drummond prepares a Non-Conformance Finding (NCF) and moves to corrective action.
At each step, Drummond’s priority is accuracy and fairness: one complaint doesn’t automatically mean a failure. But once a real NCF is confirmed, Drummond must take action. The attention to process (logging, investigation, and documentation) ensures that any decision is justified.
When a complaint has gone through these steps and Drummond still cannot resolve its case, testing moves to the place where the system is actually used.
In-Field Testing Methodology
When an issue under investigation can’t be resolved in the lab, Drummond may conduct in-the-field surveillance. This may mean deploying Drummond test personnel and tools at a live site (an office, hospital, etc.) where the product is in use.
In-field findings are reported just like lab findings. Any NCF discovered triggers the same CAP process. If field tests find no fault, Drummond still logs the activity and reports it in the quarterly surveillance update.
Non-Conformities and Corrective Actions
If Drummond’s surveillance (reactive or proactive) finds a true non-conformity (a certified criterion that the product no longer meets) Drummond initiates its corrective action procedure by issuing a NCF to the developer.
The NCF document describes exactly what certification requirement failed and summarizes the evidence (test logs, interviews, etc.).
Once the NCF is issued, the developer must submit a Corrective Action Plan (CAP), typically within 30 days. Drummond provides a CAP template outlining required information. The CAP must cover:
- A clear description of the identified NCF(s).
- Assessment of how many and which customers are affected.
- How affected users will be notified, and how the developer will confirm all are notified.
- Remediation steps: how each NC will be addressed
- A firm timeline for completion.
- Any other relevant details (e.g. root cause analysis).
Drummond reviews the draft CAP and may request clarifications or changes. Once Drummond approves it, both parties sign off. Drummond then monitors implementation.
The developer must notify affected customers of the NCF and the remediation plan, and later attest that the work is done. When the developer believes all fixes are complete, it submits a Corrective Action Plan (CAP) attestation of completion. Drummond may re-test the product (in lab and/or field) to verify the fixes.
If the developer cannot meet the agreed timeline, they must formally request a CAP amendment; Drummond may then extend or adjust the plan. If the developer fails to deliver a CAP in time or leaves NCFs unresolved, Drummond will suspend or withdraw certification as allowed by ONC guidance.
At each stage, Drummond keeps ONC informed: it updates the CHPL when issuing the NCF, when the CAP is signed, and when the NCFs are resolved.
Reporting to ONC and CHPL Updates
Drummond follows a strict reporting schedule. Key events in surveillance are publicly posted on the Certified Health IT Product List (CHPL). Specifically, Drummond adds notices to the CHPL when it issues an NCF, when a CAP is signed, and when the NCF(s) are resolved.
This transparency lets users see if a product they rely on has open CAPs or unresolved issues.
In addition, Drummond submits comprehensive reports to ONC every quarter. These cover all surveillance activities (complaints received, investigations done, CAPs opened/closed) during that period.
In each report, Drummond highlights NCF trends, CAP statuses, and even whether developers followed their own documented complaint process.
Taken together, these reporting and oversight activities create a continuous cycle of visibility between developers, certification bodies, and ONC.
This is where issues tend to emerge, not in the process itself, but in expectations about how it works in practice.
For that reason, it’s worth highlighting the most common misunderstandings that lead to avoidable findings, delays, and escalations.
Common Misconceptions About Certification Surveillance
Most surveillance issues don’t come from a single major failure. They come from small misunderstandings about how ongoing obligations actually work in practice. The points below highlight the most common pitfalls organizations should avoid.
- Certification is the finish line. Certification is not a one-time achievement. It is the start of an ongoing compliance cycle where systems are expected to remain conformant in real-world use.
- API compliance ends after certification. Developers certified to g.10 (Standardized API for Patient and Population Services) have ongoing responsibilities under the APIs Condition and Maintenance of Certification, including requirements related to application registration, authenticity verification, and customer-specific service base URLs.
- Every complaint becomes a formal investigation. Complaints are first logged and assessed by the ACB. Many are resolved during the validation stage and never progress to surveillance or enforcement.
- Reporting and attestation deadlines are administrative formalities. Missed quarterly attestations, semi-annual maintenance requirements, or Real World Testing submissions can themselves trigger corrective action, even when no product defect exists.
- Inherited certification carries no surveillance risk. After every third Inherited Certified Status request for the same product, Drummond flags it for review. Developers who rely on ICS to maintain certification should expect periodic retesting as part of that process.
- Real World Testing non-conformities can wait until the next reporting cycle. Developers who identify a non-conformity during Real World Testing must notify Drummond within 30 days. Missing that window is itself a non-conformity to Conditions and Maintenance of Certification, separate from the underlying issue.
- Surveillance only happens after a complaint. Proactive surveillance is built into the program. ACBs routinely review disclosures, certification marks, attestations, and Real World Testing obligations.
- Disclosure and documentation requirements are secondary to product functionality. Missing or incomplete mandatory disclosures, criteria-specific documentation, or API documentation can be treated as non-conformities during routine review.
- The CCIR is a one-time certification requirement. Drummond compares a developer’s complaint-handling practices against its documented complaint process as part of ongoing surveillance activities.
- Surveillance issues stay between the developer and the ACB. Unresolved or escalated issues can move to ONC Direct Review, where outcomes may include suspension or termination of certification.
Taken together, these misconceptions highlight an important reality: maintaining certification is not just about meeting technical requirements. It is about understanding and fulfilling the ongoing obligations that come with certification long after the initial testing is complete.
Successful Surveillance Starts with Understanding
Continued certification success is rarely about avoiding surveillance. It is about understanding how surveillance works. Organizations that stay ahead of reporting obligations, documentation requirements, and corrective actions are far more likely to navigate the process smoothly and maintain certification without interruption.