Medical device design verification: protocols, evidence and records

Medical device design verification produces objective evidence that design outputs meet design inputs. Under FDA's Quality Management System Regulation, which incorporates ISO 13485:2016, that means a documented protocol with acceptance criteria stated before testing, results traced to the inputs they verify, and records kept in the design and development file.

This guide covers what the QMSR changed, what a protocol holds, what counts as evidence, where IEC 60601-1 testing fits, and how to capture records while the test runs.

What is design verification for a medical device?

Design verification asks whether the design output meets the design input. The MDSAP audit approach, which auditors follow under the Medical Device Single Audit Program, describes it as obtaining "objective evidence (i.e., data) that design outputs meet design inputs" through tests, measurements and analysis. It adds that verification should be "predictive, not empiric": acceptance criteria are stated in advance and documented in a verification protocol or similar document.

The pre-2026 regulation defined verification as "confirmation by examination and provision of objective evidence that specified requirements have been fulfilled" and design validation as "establishing by objective evidence that device specifications conform with user needs and intended use(s)" (21 CFR 820.3, June 2025 version). The QMSR now takes definitions from ISO 13485 and ISO 9000; the distinction carries over.

Design controls apply to class II and class III devices and to the class I devices listed in 21 CFR 820.10(c), which include any class I device automated with computer software. In the EU, devices covered by the Medical Device Regulation, (EU) 2017/745, are excluded from the Cyber Resilience Act, which sets cybersecurity requirements for most other connected products.

What changed under the QMSR?

FDA's final rule (89 FR 7496) amended 21 CFR Part 820 and took effect on February 2, 2026. It incorporates ISO 13485:2016 by reference and reserves sections 820.20 through 820.30, so design controls now come from ISO 13485 clause 7.3. Four consequences matter for test records:

• The DHF term is gone. FDA dropped the design history file as a defined term. In the final rule, FDA writes that "consistent with the former DHF, Clause 7.3.10 requires the design and development file to contain or reference all the records necessary to establish compliance with design and development requirements." The content requirement remains.
• Records from before 2026 stay in scope. Per FDA's QMSR FAQ, investigators may review records created before February 2, 2026.
• Inspections follow a new program. FDA withdrew the Quality System Inspection Technique and now inspects under Compliance Program 7382.850.
• An ISO certificate is not a substitute. FDA will not require or issue ISO 13485 certificates, and a certificate does not exempt a manufacturer from inspection.

The former 820.30(f) still makes a good minimum. It required verification results to include "identification of the design, method(s), the date, and the individual(s) performing the verification."

What should a design verification protocol include?

A protocol is the plan you can be held to, approved before the first unit is tested.

Write limits the way the result will be judged: 4.75 V to 5.25 V inclusive at full load, not "about 5 V". Decide in advance how measurement uncertainty is handled near a limit. Equipment needs the same care: an instrument out of calibration during a run puts every reading it took into question (calibration status in automated test records).

Risk controls need verification that the control works, not only that the part exists. The MDSAP audit approach uses an enteral feeding tube with a unique connector as its example: verification should show that it is "difficult or impossible" to connect unrelated devices to it.

What counts as objective evidence?

Data. A tick in a "Pass" column is a conclusion, not evidence. Evidence lets a reviewer reach the conclusion again, and re-judge it if a limit changes. Each record should hold:

• The measured value with its unit, and the raw instrument response it came from.
• The limits and comparison, taken from the approved protocol revision.
• The instrument's identity (manufacturer, model, serial number, firmware) and its calibration status at the time.
• The unit's serial number and configuration.
• Test conditions: supply voltage, operating mode, load, temperature.
• The operator, a timestamp, and the protocol revision.
• Failures, retests and deviations, kept rather than overwritten.

Auditors sample. The MDSAP audit approach directs them to verification records for outputs essential to the device's function or tied to the highest risk. Make those the easiest to follow.

How do you trace verification results to design inputs?

The chain runs from user need to design input, design output, verification protocol revision, run, measured value, report and design review. MDSAP auditors are asked to confirm that design outputs "are traceable to and satisfy design input requirements." FDA's final rule adds that design review includes reviewing verification data, so the record is what the review reads.

Four practices keep the chain intact:

1. Give every design input a stable ID and revision. Cite both in the protocol and in every record.
2. Generate the trace matrix from records. A matrix maintained by hand drifts; hardware test traceability explains why.
3. Flag stale results. When a design input changes, mark every result recorded against the old revision for review instead of carrying the old pass forward.
4. Report from the record. Report tables should be views of run data, not retyped values (DVT test report template).

Where does IEC 60601-1 testing fit?

IEC 60601-1 applies to the basic safety and essential performance of medical electrical equipment and medical electrical systems. FDA lists Edition 3.2 (2020-08, consolidated) as recognized consensus standard 19-49, with US national differences applied, and states that it "will accept a Declaration of Conformity to this recognized standard when the US national differences are applied." Collateral standards extend it, including 60601-1-2 (electromagnetic disturbances), 60601-1-6 (usability) and 60601-1-8 (alarm systems), all on the list of standards in FDA's ASCA basic safety guidance. For the emissions tests in 60601-1-2, EMC pre-compliance testing covers scanning on your own bench before formal testing.

Formal conformity testing is often done by an outside lab. Under FDA's voluntary ASCA program, testing laboratories are assessed to ISO/IEC 17025:2017 plus ASCA specifications. When a submission includes a declaration of conformity with an ASCA Summary Test Report, FDA "does not intend to request additional information regarding testing methodologies." (ISO/IEC 17025 records for automated benches covers what accreditation expects.)

The lab still depends on your records. That guidance, issued in 2020 for the ASCA pilot, notes that a clause might read "compliance is checked by inspection of the risk management file and functional tests if necessary." Where the standard permits a clause's test method or acceptance criteria to be modified, it recommends that the submission include "the test plan and procedure, acceptance criteria, and results." Those are the elements of a verification protocol.

Engineering teams can also run electrical safety measurements on the bench before a lab slot. Under its IEC 60601 setting, the Fluke Biomedical ESA615 analyzer names its tests protective earth resistance, earth leakage, touch or enclosure leakage, patient leakage, patient auxiliary leakage and mains on applied part leakage. It runs earth leakage under four outlet conditions: normal and reversed polarity, each with the neutral closed and then open. Its manual says it tests to "parts of IEC 60601-1", which is the right way to treat bench data: engineering evidence under your own protocol, not the conformity test.

The analyzer can be scripted. Its communications interface is a USB port that can appear as a virtual COM port, set to 115,200 baud with hardware handshaking, taking plain-text commands such as STD=601, EARTHL, POL=R, NEUT=O and READ. The document lists READ without specifying its response format, which is the reason to store the raw response next to any parsed value: if the parser is wrong, the record can still be judged again.

What records does design verification produce?

For verification, the design and development file contains or references approved protocols with their revision history, run records and raw data, deviations and dispositions, verification reports, lab reports and declarations of conformity, design review records, and the trace from inputs to evidence.

Retention is long. FDA's QMSR paperwork supporting statement describes ISO 13485 clause 4.2.5 as requiring records to be kept "for at least the lifetime of the medical device, but not less than 2 years from the medical device release (for distribution)," because many devices are labeled for extended periods of use. Records kept electronically also fall under 21 CFR Part 11.

The same statement estimates quality management system recordkeeping at 348 hours per registered establishment per year, across 28,303 establishments: about 9.8 million hours. Paperwork Reduction Act rules let an agency exclude recordkeeping a firm would do in the normal course of business (5 CFR 1320.3(b)(2)), so read the figure as a regulatory estimate, not a measurement of any one team.

The part a test team controls is how data reaches the file. A value typed from an instrument screen is a transcription someone must check; a value written by the test harness at execution time removes that step. The harness is then software in your quality system, and the MDSAP audit approach says such software "must be validated for its intended use according to an established protocol," including software-controlled test equipment.

How do you capture verification records at execution time?

Read the approved limits as data, refuse to run on out-of-date equipment, measure, and append one record holding everything a reviewer needs. This example checks a 5 V rail with a Keysight 34461A over PyVISA (SCPI automation guide):

import getpass
import hashlib
import json
from datetime import date, datetime, timezone
from pathlib import Path
 
import pyvisa
 
PROTOCOL = {"id": "DVP-014", "revision": "C"}  # approved before this run
CHECK = {"design_input": "DI-022 rev B", "quantity": "isolated 5 V rail, full load",
         "low": 4.75, "high": 5.25, "unit": "V"}
DUT = {"serial": "SN-0007", "hardware": "B2", "firmware": "1.4.0"}
DMM_SERIAL = "MY12345678"  # the DMM this calibration record belongs to
CAL_DUE = "2027-03-31"  # from your calibration system, looked up for DMM_SERIAL
LOG = Path("records/DVP-014-C.jsonl")
 
 
def append(path: Path, record: dict) -> dict:
    """Append one record, chained to the previous record by SHA-256."""
    path.parent.mkdir(parents=True, exist_ok=True)
    lines = path.read_text().splitlines() if path.exists() else []
    record["prev"] = json.loads(lines[-1])["hash"] if lines else None
    body = json.dumps(record, sort_keys=True)
    record["hash"] = hashlib.sha256(body.encode()).hexdigest()
    with path.open("a") as f:
        f.write(json.dumps(record, sort_keys=True) + "\n")
    return record
 
 
def verify(path: Path) -> bool:
    """Recompute every hash; False if any record was edited, removed or reordered."""
    prev = None
    for line in path.read_text().splitlines():
        record = json.loads(line)
        claimed = record.pop("hash")
        body = json.dumps(record, sort_keys=True)
        if record["prev"] != prev or hashlib.sha256(body.encode()).hexdigest() != claimed:
            return False
        prev = claimed
    return True
 
 
if date.fromisoformat(CAL_DUE) < date.today():
    raise SystemExit(f"DMM calibration expired {CAL_DUE}; do not run {PROTOCOL['id']}")
 
rm = pyvisa.ResourceManager()
dmm = rm.open_resource("TCPIP0::192.168.1.50::hislip0::INSTR",
                       read_termination="\n", write_termination="\n", timeout=10_000)
idn = dmm.query("*IDN?").strip()           # manufacturer,model,serial,firmware
if idn.split(",")[2] != DMM_SERIAL:
    raise SystemExit(f"expected DMM {DMM_SERIAL}, found {idn}; calibration record does not apply")
raw = dmm.query("MEAS:VOLT:DC?").strip()   # for example +5.01234000E+00
value = float(raw)
 
append(LOG, {
    "protocol": PROTOCOL, "check": CHECK, "dut": DUT,
    "instrument": {"idn": idn, "cal_due": CAL_DUE},
    "command": "MEAS:VOLT:DC?", "raw_response": raw, "value": value,
    "verdict": "pass" if CHECK["low"] <= value <= CHECK["high"] else "fail",
    "operator": getpass.getuser(),
    "time": datetime.now(timezone.utc).isoformat(),
})
print("chain intact:", verify(LOG))

• Limits come from the protocol. The record carries them, so a later limit change cannot silently rewrite history.
• The raw response sits next to the value, and *IDN? ties each record to one instrument serial and firmware.
• Calibration is checked before measuring, against a due date from your calibration system, and the connected serial must match the one that date belongs to. Failures are logged like passes.
• The hash chain makes edits detectable, not impossible. Anyone with write access can rebuild it, so keep the latest hash where the test PC cannot modify it.

A flat file is a starting point, not a system: it has no approvals, access control or reports.

How does Galois handle verification records?

Galois is agent-driven test engineering for hardware teams: agents generate tests and instrument drivers, run them on real benches through the open-source galois-edge daemon, and turn the results into reports and a shared engineering record.

In the product today:

• Versioned sequences with explicit limits and comparison operators; production versions can be locked (product).
• Approval before a run. A draft sequence cannot run until an engineer approves it, and a sequence edited after approval must be approved again.
• A per-step record written at execution time: raw command, raw response, measured value, limits and instrument ID, with the operator, DUT serial and timestamps on the run.
• Reports from the record, drafted by Évariste, the agent in the Galois platform, filled from a data-bound LaTeX template, or written in the built-in editor.
• An audit log of every action, with actor, timestamp and resource (security).

Évariste can draft a sequence from a written test objective or generate an instrument profile from a programming manual. A sequence it drafts goes through the same approval gate, and the run record, not Évariste's summary, is the evidence (reviewing an agent-drafted test plan). The next section runs this guide's 5 V rail check with Évariste.

A compliance-check branch that assembles standards findings and sign-off packages (traceability matrix, attestation) from run evidence is in build. The platform also runs as a dedicated single-tenant cloud or fully on-prem and air-gapped (deployment). Protocols, dispositions, conclusions and signatures stay with your engineers, and so does validating the platform for your intended use, as with any software in a quality system.

How to run this verification check in Galois with Évariste

State the check. Open Évariste from the app sidebar (Ctrl+Shift+E) beside the device's project. Ask it to "List connected instruments" to confirm the 34461A is on the bench, then state the check as the approved protocol states it:

Create a verification sequence for protocol DVP-014 rev C, design input DI-022 rev B. First confirm that the Keysight 34461A's *IDN? reply contains serial MY12345678, and fail that step if it does not. Then measure the isolated 5 V rail at full load in DC volts; pass from 4.75 V to 5.25 V inclusive. The fixture sets full load. Put the protocol and design input IDs in the step names.

What Évariste drafts. A two-step draft sequence:

name: "DVP-014 rev C: DI-022 rev B, isolated 5 V rail"
steps:
  - name: "DVP-014 C: DMM is serial MY12345678"
    type: string_value
    config:
      instrument_id: "dmm"
      command_name: "identify"
      expected_value: "MY12345678"
      comparison: "CONTAINS"
 
  - name: "DVP-014 C / DI-022 B: isolated 5 V rail, full load"
    type: numeric_limit
    config:
      instrument_id: "dmm"
      command_name: "measure_voltage_dc"
      parameters: { range: "10", resolution: "0.0001" }
      low_limit: 4.75
      high_limit: 5.25
      unit: "V"
      comparison: "GELE"

In the meter's profile, identify sends *IDN? and measure_voltage_dc sends MEASure:VOLTage:DC? with the range and resolution.

Review and approve. Check the draft against DVP-014 rev C, not against your prompt: both limits, GELE for inclusive bounds, the unit, the serial, traceable step names, and the 10 V range and 0.1 mV resolution Évariste chose, which the protocol's method should state. Approving the sequence does not approve the protocol, which your quality system approves first. Edits, in conversation or in the sequence builder, become new versions with history and diffs; an edit after approval needs a new approval, and the production version can be locked (reviewing a generated test plan). The sequence is test software in your quality system, so validate it: run it once with a different meter in the slot and keep the failed run.

Run on the bench. First confirm in your calibration system that MY12345678 is in calibration, the check the script makes with CAL_DUE. Put SN-0007 on the fixture at full load, then start the run from Évariste or the app; galois-edge executes it, and Monitor shows the channels live. Each step records the measured value, limits, pass or fail, raw command and response, instrument, operator, DUT serial and timestamps, so the identity step keeps the full *IDN? reply, and its serial and time tie the run to your calibration record. A different meter fails that step and the run. The voltage step still runs and records what that meter read, so the failed run shows what happened; disposition it like any other failure.

Interpret and report. Ask which DI-022 results passed close to a limit across your sample, or to compare SN-0007 with earlier units; answers cite runs, and the protocol's rule for readings near a limit stays yours to apply. Then ask it to "Generate a test report from the last run" for a PDF or HTML report built from the run record and editable in the report editor. Review it before it goes into the design and development file.

You no longer write or maintain the PyVISA session, the *IDN? parsing, the JSONL record and its writer, or a report script. What stays yours: the approved protocol and its limits, the DUT configuration record, calibration status, the fixture and its load, review and approval of each version, confirming dangerous commands, and every disposition and conclusion. Agent-driven test automation covers the wider loop.

When are manual verification records enough?

A paper or spreadsheet process holds up when:

• A few design inputs are verified once, on one bench, by one engineer who also keeps the file.
• An outside lab performs the tests, and its report is the record.
• An electronic quality system already holds protocols and approvals, and the job is feeding it run IDs and raw data.

Even then, record values with units and instrument serials, not ticks, and keep raw data where the record names it. A reviewer can then follow any result back to a measurement, which is most of what design verification asks for.

If you are planning the builds that verification runs on, EVT, DVT and PVT testing covers what each stage has to prove.