Independent learning for medical-device professionals
SearchCommentaryConsulting
LearningMTL-212 · LEARNING BY ROLE

Verification Engineers and Test Laboratories

How to turn product requirements and safety claims into objective, reproducible and reviewable medical-device evidence.

What you will learn

By the end of this topic, you should be able to explain the verification function’s independence and accountability; develop a risk-informed verification strategy; write executable protocols; establish test readiness; control internal and external laboratory work; handle failures and deviations without weakening acceptance criteria; and produce traceable reports that support product and regulatory decisions.

01

The verification engineer’s role

Verification asks whether specified requirements have been fulfilled. The verification engineer provides disciplined challenge between the design team’s assertion and the evidence used to accept it. That challenge is constructive: clarify ambiguous requirements early, expose untestable claims and design an efficient body of evidence that addresses normal use, foreseeable misuse and credible failure conditions.

Evidence architect

Build a coherent strategy across inspection, analysis, test, simulation and review.

Method owner

Define controlled, repeatable methods and acceptance criteria before seeing results.

Independent witness

Record what occurred, including deviations and unfavourable results.

Decision contributor

Explain what the evidence proves, what it does not prove and what remains unresolved.

02

Build one integrated verification strategy

Begin with MTL-103 — User Needs and Design Inputs, MTL-114 — Medical-device Risk Management and the applicable standards and regulatory claims. Select the most appropriate evidence method for each requirement. Avoid equating verification with bench testing: a justified inspection, analysis, review or validated simulation may be stronger and more efficient.

Plan the order of activities so component evidence reduces uncertainty before expensive integration, system, reliability, transport, safety or external laboratory testing. Identify dependencies, specimen demand, destructive tests, specialised facilities and long-duration work early.

03

Write a protocol another competent person can execute

  • Identify the requirement, risk control and claim being verified.
  • Define the test article, sample size, configuration and representativeness.
  • Specify equipment, fixtures, software tools, environmental conditions and calibration needs.
  • Describe the method, data capture, calculations and statistical treatment.
  • State objective acceptance criteria and the rationale for them.
  • Define handling of preconditions, invalid runs, deviations and unexpected observations.
  • Require independent review and approval before formal execution.

Use MTL-116 — Verification and Validation for the wider distinction between design verification, validation and process validation.

04

Do not test before the evidence system is ready

1

Plan from the claims

Translate requirements, risk controls and regulatory claims into an integrated verification strategy.

2

Define the method

Specify samples, configurations, equipment, conditions, acceptance criteria and analysis before execution.

3

Establish readiness

Confirm approved inputs, representative specimens, trained personnel, calibrated equipment and controlled methods.

4

Execute objectively

Record actual conditions, raw data, deviations, observations and configuration without rewriting history.

5

Conclude explicitly

State whether each acceptance criterion was met and explain anomalies, exclusions and limitations.

6

Preserve traceability

Connect the report to the requirement, risk control, specimen, method, result and released evidence baseline.

A formal readiness review should confirm that the protocol is approved, acceptance criteria are fixed, test specimens are representative and identifiable, known anomalies are understood, equipment is suitable, personnel are competent and the tested configuration can be reconstructed.

05

Control the interface with test laboratories

Accreditation can increase confidence, but it does not transfer the manufacturer’s responsibility for selecting the correct standard, edition, scope, configuration or acceptance criteria. Confirm that the laboratory’s accredited scope covers the specific work, agree the test plan and reporting detail, and control changes made during troubleshooting.

Provide a complete specimen definition, installation instructions, accessories, operating modes, software versions, risk-relevant worst cases and authorised contacts. Review the laboratory report for factual accuracy and limitations; do not ask a laboratory to conceal unexpected behaviour or rewrite a failed requirement as a pass.

06

Protect objectivity during execution

Record raw data, equipment identifiers, environmental conditions, specimen configuration, operator, date and actual sequence. Treat informal adjustments, repeated runs and substituted samples as controlled events. If a method must change, pause, assess the effect, approve the deviation or revised protocol and preserve the original record.

Configuration control through MTL-129 — Configuration and Change Management is essential: a passing report has little value if nobody can establish exactly what was tested.

07

Use statistics to support the claim—not decorate the report

Sample size and analysis should reflect the requirement, variability, confidence needed, risk and decision being made. Define the experimental unit, independence assumptions, distribution, confidence or reliability target and treatment of missing or censored data before testing. A convenient sample size is not a statistical rationale.

Connect the approach to MTL-120 — Statistical Methods and Measurement Assurance.

08

Treat failures and deviations as information

Separate product failure, method failure, equipment failure, specimen damage and protocol deviation. Document the immediate disposition, investigate the cause and assess impact on completed and related evidence. Retesting is justified only after the reason for invalidating or correcting the earlier result is documented. Repeated testing until a favourable result appears is not verification.

09

Make the conclusion reviewable

The report should identify the approved protocol and deviations, tested configuration, samples, methods, raw-data location, results, calculations, anomalies and criterion-by-criterion conclusion. It should distinguish facts from interpretation and state limitations. Traceability must allow a reviewer to move from requirement to result and back again without relying on personal knowledge.

10

Contribute beyond the design-verification campaign

Verification specialists also support design changes, manufacturing test development, method validation, supplier evidence, complaint investigation and post-market corrective action. Reuse is acceptable only when equivalence, configuration and continued applicability are demonstrated. Field information should refine stress conditions and regression scope for future releases.

11

Common misconceptions

“Passing the standard means the device is verified.”

A standard test covers defined aspects; device-specific requirements, risks and claims still require evidence.

“An accredited laboratory owns the result.”

The laboratory owns competent execution within its scope; the manufacturer owns applicability and product conclusions.

“A failed test can simply be rerun.”

Retesting without a documented cause and disposition destroys confidence in the evidence.

REFERENCES

Authoritative starting points

KEY TAKEAWAY

Good verification makes the product claim testable, the test reproducible and the conclusion defensible

Independence is not distance from the design team; it is the discipline to preserve objective evidence and expose uncertainty before release.