How to Set Device Acceptance Criteria Correctly

A verification result is only as defensible as the criterion used to judge it. When manufacturers set device acceptance criteria after testing begins, or phrase them as broad intentions rather than measurable limits, they create an avoidable regulatory and quality risk. The test may produce useful data, but it may not demonstrate that the device meets its established requirements.

For medical devices, acceptance criteria are the predefined, objective conditions a design output, component, subsystem, or finished device must satisfy to be accepted. They turn statements such as “safe,” “accurate,” or “easy to use” into testable evidence. Well-written criteria support design verification, process validation, incoming inspection, final release, and investigation of nonconforming product.

Why acceptance criteria carry regulatory weight

Acceptance criteria establish the decision rule before a result is known. This is fundamental to an impartial verification activity. A protocol should define the test article, configuration, method, environmental conditions, sample size where applicable, measurement equipment, data handling approach, and pass/fail limits. The report then documents whether the observed result met that predefined rule.

Without this structure, a team can be tempted to interpret a marginal result favorably, revise a limit to accommodate performance, or rely on engineering judgment that is not traceable to a requirement. Those practices can weaken design history documentation and complicate a regulatory submission, audit, complaint investigation, or corrective action review.

The appropriate level of detail depends on the device and the claim being supported. A tolerance for an ECG amplitude measurement, for example, requires a different technical basis than an acceptance criterion for ultrasound image quality, endoscope mechanical performance, dielectric strength, or a human factors validation task. The principle remains the same: the criterion must be objective, justified, and appropriate for the intended use and risk profile.

Start with the requirement, not the test result

A common source of weak criteria is beginning with the test equipment or a familiar standard rather than the design input. Start with what the device is required to do. User needs, intended use, labeling claims, risk controls, applicable standards, and regulatory requirements should flow into measurable design inputs. Design outputs and verification protocols then provide the means to demonstrate conformance.

For example, “the system shall provide accurate displayed temperature” is not yet a complete verification requirement. It should identify the operating range, allowable error, relevant environmental conditions, measurement reference, and any stabilization or sampling conditions. A more usable requirement might specify the maximum permitted display error across a defined range when evaluated against a traceable reference under stated conditions.

That specificity makes the acceptance criterion much easier to establish. It also improves traceability. A reviewer should be able to move from the user need or risk control to the design input, test protocol, objective evidence, and verification conclusion without relying on inference.

Separate design verification from validation

Design verification asks whether outputs meet defined inputs. Design validation asks whether the finished device meets user needs and intended uses under actual or simulated use conditions. Both activities need acceptance criteria, but the criteria should not be interchangeable.

A verification criterion may be a quantitative limit, such as leakage current not exceeding a defined value under specified test conditions. A validation criterion may focus on successful completion of critical user tasks without use errors that could result in unacceptable harm. For human factors work, task success alone may not be sufficient. The protocol may need predefined thresholds for critical task failures, observed close calls, user comprehension, and residual use-related risk.

Do not treat a passing verification result as proof of validation, or a favorable usability observation as proof that an engineering specification has been met. The evidence serves different purposes.

Build criteria from risk, claims, and standards

Risk management provides an essential basis for determining how stringent an acceptance criterion needs to be. Under ISO 14971 principles, risk controls must be implemented and their effectiveness verified. Where a device specification functions as a risk control, its acceptance criterion should clearly demonstrate that the control is present and effective across relevant operating conditions.

Claims matter as well. If labeling, promotional materials, or instructions for use state a performance capability, the device should have evidence that supports the claim within its defined scope. A claim about measurement accuracy, therapeutic output, image quality, or battery endurance should not rest on a single nominal result when real-world variables could materially affect performance.

Consensus standards often provide test methods, limits, classifications, or state-of-the-art expectations. They are valuable inputs, but they do not eliminate engineering judgment. A standard may specify a minimum safety requirement while the product’s intended use, risk analysis, or performance claim requires a narrower internal limit. Conversely, a standard test method may need a justified adaptation because of the device configuration. The protocol should document that rationale before execution.

How to set device acceptance criteria that can be tested

An effective criterion answers five practical questions: what is measured, how is it measured, under what conditions, what result is acceptable, and how is the decision made? If any answer is unclear, the criterion is likely to produce inconsistent execution or an ambiguous conclusion.

Quantitative limits should include units, tolerances, ranges, and directionality. “Output shall be acceptable” is not a criterion. “Measured acoustic output shall not exceed the applicable limit under the stated operating mode and measurement configuration” can be one, provided the applicable limit and setup are fully defined in the protocol.

Qualitative criteria can be appropriate when measurement is not purely numerical, but they still require controlled definitions. For visual inspection, define the defect types, inspection conditions, magnification if used, sampling plan, and disposition rules. For image quality, specify phantom configuration, system settings, scoring method, qualified evaluators where relevant, and the threshold for acceptance.

Boundary conditions deserve deliberate attention. Testing only at nominal voltage, room temperature, and a preferred operating mode may leave the most consequential conditions unexamined. The relevant extremes depend on the device, intended environment, transport and storage conditions, energy source, accessories, and foreseeable use. Risk analysis should help determine which conditions must be represented.

Measurement uncertainty also matters when a result approaches the limit. A laboratory should use calibrated equipment and validated or suitable methods, but a reported measurement is not exact. The protocol should state how uncertainty will be considered when conformance decisions are made, particularly for tight tolerances. A decision rule should define whether the uncertainty is incorporated into the acceptance determination and how the associated risk is addressed.

Avoid criteria that cannot survive review

Several recurring practices create unnecessary exposure. One is using “pass” or “fail” as the only criterion, without defining the underlying threshold. Another is referencing a standard without identifying the applicable edition, clauses, test conditions, deviations, or product-specific configuration.

Post-test changes are equally problematic. If a criterion must change because of new information, document the reason, assess the impact on risk and claims, obtain the appropriate approvals, and determine whether testing must be repeated. A revised criterion should not be used simply to convert an unfavorable result into a passing result.

Teams should also avoid acceptance criteria based solely on historical averages. Prior product performance can inform specification development, but an average does not establish a safe or effective boundary. The technical justification should consider design capability, clinical or user need, risk controls, standards, and the consequences of failure.

Document the rationale and preserve traceability

The acceptance limit itself is only one part of the record. The design history file or equivalent design documentation should show why the criterion is appropriate. Useful supporting evidence can include risk analysis outputs, standards assessments, bench characterization, clinical evidence, usability engineering records, tolerance analysis, and engineering rationale.

For externally performed testing, provide the laboratory with the current protocol, relevant device configuration details, applicable standards, required acceptance limits, and any requested decision rule. Early alignment prevents a test report from documenting data that cannot be used efficiently in a verification package. It also reduces the risk of discovering late in the program that the tested configuration, conditions, or reporting format do not support the intended submission.

An ISO/IEC 17025-accredited laboratory can provide disciplined execution, traceable measurements, and technically complete reporting within its accredited scope. The manufacturer, however, remains responsible for defining requirements and ensuring that acceptance criteria reflect the device’s intended use, risk profile, and regulatory strategy.

A useful final check is simple: before testing starts, ask whether an independent reviewer could read the requirement, protocol, raw data, and report and reach the same pass/fail conclusion. If the answer is not clearly yes, refine the criterion before the device enters the lab.