A Guide to Medical Device Requirements Management

On February 2, 2026, medical device design controls in the United States stopped being their own set of rules. The Food and Drug Administration (FDA) folded them into the Quality Management System Regulation (QMSR), which now sends manufacturers to Clause 7.3 of International Organization for Standardization (ISO) 13485:2016, the quality management standard for medical devices.

What a medical device team has to prove didn’t change. Class II, Class III, and a defined list of Class I devices still have to show that user needs were translated into design inputs, and that design outputs were then verified against those inputs. The finished device still has to be validated against the needs it started from, using acceptance criteria written before any testing began. What changed is the file an investigator opens, the vocabulary that file uses, and how much of the rest of your quality system is now open to inspection.

Meeting that bar comes down to whether the evidence chain from user need through validation was built as the work happened or reconstructed afterwards. This guide covers what the QMSR changed about design control evidence, what a traceability matrix has to prove in both directions, and why records kept in documents fail when they matter most.

What Is Medical Device Requirements Management?

Medical device requirements management is the work of capturing what users need, turning those needs into design inputs, and keeping a trace link from every requirement through design outputs, verification, and validation. The regulatory weight sits on the inputs, which have to be measurable, complete, unambiguous, and free of conflicts. That is why translating user needs into design inputs means turning “Portable” into a weight of 3 lb ± 1 lb.

Every artifact in that chain lands in what Clause 7.3.10 calls the design and development file, the record set most teams still call the Design History File (DHF). It has to contain or point to the records showing the design followed the approved plan, and you have to produce it on inspection. Final design outputs also feed the medical device file, which supplies the specifications for a 510(k). Neither that record set nor the four fundamentals of requirements management behind it is new, and what changed is the regulation they answer to.

What the QMSR Changed About Design Control Evidence

Design control obligations survived the transition, but they no longer sit in their own section of United States regulation. The final rule of February 2, 2024, marked the design controls section as reserved, meaning it now holds no text, and moved the requirements into §820.10(c), which covers the same device classes as before.

The vocabulary changed more than the substance did, and four terms cause most of the confusion, three retired and one renamed.

FDA describes the ISO 13485 recordkeeping requirements as substantively similar to the ones they replaced. The two had been converging for years under FDA 21 CFR Part 820, so a term-by-term rewrite of existing files isn’t what the transition asks for.

Older records do stay in scope, and this is where transition plans tend to be too relaxed. Investigators may review records created before the effective date, so a comparative analysis showing that pre-2026 documents meet QMSR requirements is one way to show compliance.

Inspections changed alongside the regulation, and FDA moved to Compliance Program 7382.850 in February 2026. The new program dropped the exceptions that had kept management review, quality audits, and supplier audit reports out of an investigator’s reach. A trace chain that only holds up under a light look is a bigger liability than it was.

Why Requirements You Can’t Test Break the Evidence Chain

A requirement that can’t be tested can’t be traced to a test result, so requirement quality decides whether the design control file can be built at all. Verifiable requirements avoid vague quantifiers such as “several” and “approximate,” and vague adjectives such as “significant,” “adequate,” and “sufficient.” That list is Rule R7 in the International Council on Systems Engineering (INCOSE) Guide to Writing Requirements. When a design input says the audible alarm shall be “sufficient,” the test engineer who owns verification has no acceptance criterion to write, and the problem surfaces at design verification with the schedule already locked.

Mandatory requirements take “shall” or “must” rather than “should,” and the Easy Approach to Requirements Syntax supplies sentence patterns for ubiquitous, state-driven, event-driven, optional-feature, and unwanted-behavior requirements. A requirement review then has to confirm that each statement can carry a trace link to evidence, and three checks do most of that work:

• Defined source: Every requirement traces up to the user need or higher-level requirement justifying it. A requirement with no parent is either scope creep or a design input nobody captured.
• Measurable acceptance criteria: The statement names a threshold, a tolerance, and a verification method. If the reviewer can’t describe the test, the requirement isn’t finished.
• Conflict check: The statement doesn’t contradict another requirement in the same baseline. Two design inputs with incompatible thresholds both pass verification in isolation, then fail at integration.

Writing the verification method and success criteria alongside the requirement makes the third check easy, because conflicts stay visible while both are still open. Inspectors confirm that acceptance criteria existed before testing ran, so criteria written after a test result are a finding. Clause 7.3.9 of ISO 13485 applies the same discipline to changes, which have to be documented, reviewed, verified or validated as appropriate, and approved before implementation. Only requirements that survive those checks can anchor a trace link, which is what a matrix is built from.

What a Traceability Matrix Has to Prove in Both Directions

A matrix that only runs forward proves half of what a reviewer needs, which is why bidirectional traceability means running it both ways. Forward, every user need reaches design inputs, design outputs, verification, and validation, which confirms coverage. Backward, every test case and design element connects to the requirement that justifies it, which exposes tests with nothing behind them and requirements with no source.

ISO 13485 puts that obligation into design planning, which has to document the methods used to trace design outputs back to inputs. A matrix assembled at the end of a project can’t satisfy a planning requirement.

Missing links in either direction can stay hidden until review, long after development is closed. When a 510(k) submission draws an Additional Information request, the review clock stops until you answer, and reviewers raise those requests even when the data exists, because poor cross-referencing makes the evidence hard to follow. Verification confirms the product was built correctly and validation confirms the right product was built, so a matrix blurring the two invites exactly those questions.

Trace links created as requirements are written give you change impact analysis before a change is committed, because they identify every affected design output, test case, and risk item. For software-containing devices, International Electrotechnical Commission (IEC) 62304 requires the development plan itself to address traceability between system requirements, software requirements, software system tests, and risk controls built in software.

Risk belongs inside that chain rather than beside it. Under Clause 7.3.3, the outputs of risk management are design inputs, so hazard analysis has to happen before design outputs exist. ISO 14971:2019 then expects the risk management file to trace each hazard through its evaluation, the verification of its controls, and its residual risk. A Failure Mode and Effects Analysis run after the design freezes arrives too late to shape any requirement, and it looks only at single-point failures, so it can’t carry the standard alone.

Why Spreadsheets and Word Documents Fail an FDA Inspection

Spreadsheets and Word documents hold requirements as text, with no link between them that updates on its own. Each edit needs a manual matrix update, downstream owners get no notification that their test case is now out of date, and the matrix drifts from the design it describes. Two failure modes follow directly from that break in the chain:

• Late assembly: Maintaining traceability in Excel gets burdensome enough that the matrix stays unfilled until a project is nearly complete. It becomes an auditor-facing artifact rather than a design tool, the opposite of what Clause 7.3 assumes.
• Electronic records shortfalls: Spreadsheet controls alone may not meet 21 CFR Part 11 requirements for electronic records and signatures, so the approval evidence is as questionable as the matrix.

Neither failure mode announces itself before an investigator or a reviewer asks a question the records can’t answer, and by then the cost is counted in review cycles rather than engineering hours. A design input corrected at verification ripples through every linked design output, test case, and risk item, while the same fix during authoring touches one line.

A February 2026 warning letter to Longhorn Vaccines and Diagnostics LLC shows what that looks like. The inspection ran while the previous regulation was still in force, and FDA found the firm had written its design control procedures during the inspection itself. Any corrective action it proposes now has to meet QMSR requirements. Teams carrying that exposure move risk files and trace matrices into a system that maintains the links as work happens. BrightInsight reduced risk assessment activities by 50% and pulled project timelines in by three to six months after moving to Jama Connect®, a web-based requirements management and traceability platform for regulated product development.

How Jama Connect Supports Medical Device Requirements Management

Jama Connect ships with a pre-built medical device framework whose Traceability Information Models (TIMs) define the relationships design controls require. A user need, its design inputs, its verification and validation records, and its linked hazards sit in one structure the software enforces, rather than three systems reconciled by hand before a submission. The framework aligns to ISO 13485:2016 and ISO 14971:2019, and Review Center holds electronic approval with an audit trail on the same items.

Because those relationships are enforced rather than maintained by hand, Live Traceability™ flags every downstream artifact as suspect when an upstream item changes. A changed design input surfaces the hazard analysis and test cases it affects while there is time to act, which keeps the design and development file current rather than something you compile before a submission.

Building an Evidence Chain That Holds Up Under Inspection

Clause 7.3 didn’t change what a medical device team has to prove. It changed the file an investigator opens and how much of the quality system comes with it. The first full inspection cycle under the QMSR will settle what “contains or references” means in practice, and teams whose evidence is already linked will spend that cycle answering questions rather than assembling answers.

If your quality and regulatory affairs group rebuilds the trace chain every time a submission date moves, you can start a free 30-day trial and run one of your own requirement sets through it.

Frequently Asked Questions About Medical Device Requirements Management

What should a QMSR gap analysis check in a legacy design file?

Clause 7.3 of ISO 13485 is the checklist. Confirm that the file for each device type or family contains or points to the records establishing compliance under Clause 7.3.10, and that validation used representative product, not a prototype. Because investigators may review records created before February 2, 2026, a written mapping from your Design History File structure to Clause 7.3 is worth producing before an inspection, not during one.

How does IEC 62304 software safety classification change what you have to trace?

IEC 62304 assigns software a Class A, B, or C classification based on how badly a failure could injure someone, and software with no documented classification is treated as Class C. For Class B and C software you have to show that every risk control built in software was tested and shown effective, with traceability from hazard to requirement to code to test. Every piece of Software of Unknown Provenance (SOUP) also has to be documented and assessed, which for a connected device means the operating system and any open-source libraries. A chain split across a spreadsheet and a risk file gets rebuilt every release, which is the argument for one data model such as Jama Connect.

What does the EU MDR expect from a traceability matrix?

Under the European Union Medical Device Regulation (EU MDR), the mapping sits in the technical documentation rather than a standalone matrix. Annex II, Section 4 asks for every general safety and performance requirement that applies, plus an explanation of why the others don’t. For each one it wants the method used to demonstrate conformity, the harmonised standards applied, and the documents holding the evidence. A traceability matrix carrying method and evidence columns can produce that mapping directly.

This article was authored by Tom Rish and published on August 20, 2026.