Design controls training for medical devices: ISO 13485:2016 and the FDA QMSR

Opens with a self-check: what is a design input, how does it differ from a user need, and who decides a design is ready for production? Presents three recent FDA cases: the March 2025 warning letter to Dexcom on design inputs, an inadequately evaluated sensor component change and hazard analyses that missed automated insulin dosing; a July 2026 letter to Koven Technologies, whose manual added fetal heart sounds as a use with no design change records; and an August 2026 letter to Pensar Medical, a maker of wound therapy systems, about software changes. Shows design controls in one picture, as set out in clause 7.3 of ISO 13485 and applied by FDA's QMSR. Introduces PQR Health Inc. in San Francisco, designing a wearable continuous glucose monitor with sensors from a contract manufacturer in Singapore. Ends with the thirteen modules, practice exercises and exam, and a recap.

What you will be able to do

• Explain what recent FDA warning letters reveal about design control failures
• Describe design controls under clause 7.3 of ISO 13485 in one picture
• State why changing a device's intended use is a design change

Why it matters

Seeing what FDA cited at real device makers shows which design records an inspector will ask for at your company.

Practice: Practice: Welcome: why design controls matter · 3 questions

Starts with a choice every start-up faces, told at PQR Health: building prototypes fast and adding design controls after the clinical study, then spending months rebuilding records, versus starting design controls when design starts. Explains who must apply design controls in the United States: since 2 February 2026, section 820.10(c) of the QMSR requires clause 7.3 of ISO 13485 for class two and three devices, class one devices with software and five listed class one types, including devices used in clinical investigations. Covers the ten parts of clause 7.3, from the plan to the design and development file, and how verification asks did we build it right while validation asks did we build the right thing. Shows the outline of PQR Health's design control procedure and how risk management and usability connect to every part. Ends with a simple test and a recap.

What you will be able to do

• Identify which devices must comply with design controls under the QMSR
• List the ten parts of clause 7.3 in order
• Explain the difference between design verification and design validation

Why it matters

Starting design controls when design starts avoids months of rebuilding requirements and test records before a submission.

Practice: Practice: Design controls at a glance · 3 questions

Opens with two versions of PQR Health's first design plan: a schedule written at kick-off and never updated, which loses six months when validation needs production sensors that do not exist, and a plan that names stages, reviews and owners. Explains clause 7.3.2, which asks the plan to document stages, reviews, verification, validation and transfer activities, responsibilities, traceability methods and resources. Shows the stages in PQR Health's plan, from a feasibility bench study of accuracy through verification of each design input, the clinical study and human factors validation test, to validation of sensor manufacturing processes at the contract manufacturer. Covers why stages are your choice, each ending in a documented design review, and how plan size varies, with a hip implant system at a maker in Chicago. Ends with keeping the plan current, a recap and a practice exercise writing a design plan.

What you will be able to do

• Write a design plan covering the six items of clause 7.3.2
• Choose design stages that each end in a documented review
• Keep the plan updated through controlled revisions

Why it matters

A plan the team actually uses, kept current, spots problems like missing production sensors months before validation.

Practice: Practice: The design and development plan · 3 questions

Starts with a design decision at PQR Health: how to warn a user of dangerously low glucose. One team imagines a user awake with the phone's sound on, and night-time alerts go unnoticed; the other studies real users first. Explains that the intended use comes first, described by six elements, and that clause 7.2.1 asks for stated and unstated requirements, regulatory requirements and training. Covers studying and documenting real users and use environments, including foreseeable misuse, as FDA's human factors guidance recommends. Then shows how PQR Health turns one need into inputs, with four examples of the record a company keeps, and how clause 7.3.3 turns needs, risk outputs and regulatory requirements into recorded, approved design inputs, each traced to its source. Ends with a simple test and a recap.

What you will be able to do

• Describe the intended use using its six elements
• Document real users, use environments and foreseeable misuse
• Turn a user need into design inputs traced to their source

Why it matters

Designing for the user you actually have prevents alerts that go unheard at night and failures found late in testing.

Practice: Practice: User needs and design inputs · 3 questions

Returns to the March 2025 warning letter to a glucose monitor maker, where design inputs did not clearly define the special controls for integrated continuous glucose monitors under section 862.1355 of FDA's rules. Explains clause 7.3.3: inputs that are complete, unambiguous, able to be verified or validated, not in conflict, reviewed and approved. Shows the simple pattern PQR Health uses, a value, the conditions, a method and the source, with four inputs before and after rewriting, and a surgical stapler maker in Los Angeles rewriting the staple line shall be strong. Covers how regulatory requirements and standards become precisely quoted inputs, with three of the rule's accuracy requirements for adults. Then shows a conflict PQR Health found between inputs and the check it runs on its input list. Ends with a recap.

What you will be able to do

• Write a design input with a value, conditions, method and source
• Turn a regulatory requirement into precisely quoted inputs
• Find and resolve conflicts between design inputs

Why it matters

An input is finished when its test is clear; vague inputs are what FDA cited when special controls were not defined.

Practice: Practice: Writing verifiable design inputs · 3 questions

Starts with another finding from the March 2025 letter: sensors accepted on the average coating thickness across a sample, with no criteria for individual sensors. Explains clause 7.3.4: outputs that meet inputs, inform purchasing and production, contain acceptance criteria, specify essential characteristics, are in a form suitable for verification and are approved before release. Shows how essential characteristics move from the risk file into the design, and how outputs speak the same language as inputs, with PQR Health's software specification stating alert timing and referencing DI-031. Covers part of PQR Health's output list, where outputs go and how they stay under control, with a hip implant maker in Chicago marking joint surface finish as an essential characteristic. Ends with the final design output starting the medical device file, and a recap.

What you will be able to do

• Write acceptance criteria that fit how the device can fail
• Identify essential characteristics from the risk file
• Check that each output can be verified against its input

Why it matters

Acceptance criteria based on averages can pass faulty units; criteria that fit how the device fails protect every patient.

Practice: Practice: Design outputs and acceptance criteria · 3 questions

Opens with two versions of the review closing PQR Health's development stage: progress slides that miss an unverified alert sound level with the phone on silent, and a review that walks the traceability matrix input by input. Explains clause 7.3.5: systematic reviews at suitable stages that evaluate results, propose actions and are recorded with the design, participants and date. Covers participants, including the functions concerned, the contract manufacturer in Singapore and other specialists, and why an independent reviewer, though no longer named, remains good practice. Shows how to prepare a review package a week ahead and PQR Health's record for its development stage review. Then builds the traceability matrix linking needs, inputs, outputs, risk controls and tests, and shows how it lets a change review list every test to repeat in minutes. Ends with a recap.

What you will be able to do

• Run a design review that evaluates results and records decisions
• Prepare a review package with matrix, test results and risk file
• Build a traceability matrix from user needs to tests

Why it matters

Reviews that decide and links that hold catch gaps at the review table instead of in the clinical study months later.

Practice: Practice: Design reviews and traceability · 3 questions

Starts with a test method finding from the March 2025 letter: a key method validated by recording only pass or fail rather than measured values, which FDA said could not show repeatable or reproducible results. Explains clause 7.3.6: documented verification plans with methods, acceptance criteria and a rationale for sample size, and records of results and conclusions. Shows part of PQR Health's verification plan, then covers validated test methods, recorded measured values, calibrated equipment and measurement uncertainty. Covers verifying connected devices as connected, sample sizes that follow the risk, with one simple, widely used calculation, and a hip implant maker in Chicago fatigue-testing implants for millions of cycles. Ends with reports filed in the design file and linked to the matrix, every input closed with measured data, a recap and a practice exercise writing a verification plan.

What you will be able to do

• Write a verification plan with methods, criteria and sample size rationale
• Validate a test method using measured values, not pass or fail
• Choose a sample size that follows the risk and record why

Why it matters

Verify the test, then trust the result; an unvalidated method makes every result built on it open to challenge.

Practice: Practice: Design verification and sample sizes · 3 questions

Opens with the March 2025 finding that hazard analyses for the G6 and G7 monitors did not address use with automated insulin dosing systems, cited as a design validation failure. Explains clause 7.3.7: planned validation on representative product, including when connected, completed before release, with records. Covers clinical or performance evaluation under the regulations that apply, which for PQR Health's monitor are specific, including data for children or an accepted justification. Then covers the human factors validation test FDA expects: every critical task, representative users, generally at least 15 participants per group reflecting differences such as age, literacy and dexterity, and the final design, with design fixes before instruction fixes. Shows how PQR Health applies this, a situation from its usability study, and an inhaler maker in London. Ends with a simple test and a recap.

What you will be able to do

• Plan design validation on representative, connected product
• Explain the clinical evaluation needed for the device
• Plan a human factors validation test for every critical task

Why it matters

Real users, final design and real conditions find use errors that bench testing never shows.

Practice: Practice: Design validation and usability · 3 questions

Starts with one more finding from the March 2025 letter: a significant change to a sensor resistance layer component whose equivalence study did not meet its primary endpoints, yet commercial manufacturing continued. Explains clause 7.3.8: transfer procedures that confirm outputs are suitable for manufacturing and production can meet requirements, with results recorded, shown in part of PQR Health's transfer checklist. Covers clause 7.3.9: identifying each change, judging its significance, and reviewing its effect on parts, product in process and product already delivered, risk management and processes, then verifying, validating and approving before implementation, using the traceability matrix to pick the tests to repeat. Shows a filled change record at PQR Health and a dental implant maker in Mumbai moving machining to a new site. Ends with a recap and a practice exercise writing a software change record.

What you will be able to do

• Confirm through transfer that production can meet the design
• Judge the significance of a design change and review its impact
• Write a design change record from significance to approval

Why it matters

No change reaches a patient unreviewed; judging significance properly stops a worse-performing component reaching the market.

Practice: Practice: Design transfer and design changes · 3 questions

Opens with a July 2026 warning letter to a maker of dialysis concentrates whose procedure and quality manual described every design step, yet it could not produce records showing its six marketed devices were developed under the clause. Explains clause 7.3.10: a design and development file for each device type or family, containing or referencing the design and change records, shown in PQR Health's design file index. Covers clause 4.2.3 and the medical device file, the current recipe, which now holds what the former device master record held, and what happened to the old US record names. Then covers the rules for records: legible, retrievable and secure, with changes visible and gaps fixed honestly, never by backdating, with a surgical stapler maker in Paris keeping one file for a family of six sizes. Ends with a simple test and a recap.

What you will be able to do

• Build a design and development file index for a device family
• Explain what the medical device file holds under clause 4.2.3
• Fix gaps in design records honestly, without backdating

Why it matters

If it is not in the file, it did not happen; a complete design file is what lets you answer an inspector in minutes.

Practice: Practice: The design file and the medical device file · 3 questions

Starts with an August 2026 warning letter to a maker of wound therapy pumps, where a firmware change described as clean up all code had no verification record and nobody could explain what changed. Explains that every software change needs a record of what changed, an impact analysis, regression checks and approval before release. Covers clause 7.1 on documented risk management in product realisation, running through inputs, outputs, verification, validation and change, with controls following the order of priority and the danger of controls left in progress. Shows PQR Health's risk control register and how it handles a third-party library update, with an insulin dose calculator app maker in Los Angeles. Then covers connected devices verified and validated as a system and security designed in from the start. Ends with two quick checks, including filtering the register for open controls, and a recap.

What you will be able to do

• Record and analyse the impact of every software change
• Apply risk management through every stage of design
• Check the risk control register for controls not yet closed

Why it matters

Know every version and close every control; an unexplained firmware change is exactly what FDA cited at a pump maker.

Practice: Practice: Software, connected devices and risk · 3 questions

Starts with what FDA treats as the minimum design elements in baseline inspections, following clause 7.3 of ISO 13485, with risk management running through all of them. Brings back the warning letters from the course and the pattern they share: procedures existed, but the work, the records or the timing fell short. Then walks through a worked design review at PQR Health, checking the plan, tracing a sample of user needs through inputs, outputs, verification and validation in the matrix, filtering the risk control register for anything not done, reviewing changes and the file, and shows what the review found. Gives a ten-question checklist in two parts and a road map that fixes what could affect patients first, with an owner and a date for every action. Ends with a recap and the final exam.

What you will be able to do

• Recognise the common pattern behind design control warning letters
• Run a design review that traces user needs to verification and validation
• Use the ten-question checklist on your own projects

Why it matters

Seeing a full design review shows exactly how an inspector tests your design records, and where to start fixing gaps.

Practice: Practice: Putting it together findings and the exam · 3 questions