Checklist playbook · New product introduction
Medical Device NPI Checklist
A gate-by-gate launch playbook, from concept approval to the first shipment
Every check says who owns it, whether it's a requirement or good practice, and where it comes from, in current ISO 13485, QMSR and EU MDR terms. Tailor it to your device, track progress as you go, and finish with a case study of a launch that slipped five months.
Notes
Gate names vary between companies; move checks to the gate in your own procedure where they fit. A gate is a business decision, while a design review is a quality record under ISO 13485, so keep them as separate records even if they share a meeting.[1] Ticks are saved in this browser only.
Fit it to your device
Tailor the checklist
Gate 1
Concept approved
Is this a product worth developing, and do we know what it is for?
-
Risk, evidence, the regulatory pathway and every marketing claim depend on this wording.
Read more
- Good practice
- Write the intended use and indications as separate statements, and list users (by training), patients, body sites and use environments explicitly. Have regulatory, clinical and marketing agree the wording before design inputs are written.
- Rule of thumb
- If marketing wants to claim it, it has to fit inside the indications. Write the claims you hope to make on day one and check them against the draft.
- Common pitfalls
- Indications that are broader than the evidence you can afford; vague user groups (“healthcare professionals”) that hide very different training levels; intended use rewritten late, after testing was planned around the old one.
- Evidence to show
- A controlled intended use and indications statement, with an approval record and a change history.
-
The pathway (for example 510(k), De Novo or PMA in the US, or a conformity assessment route in the EU) sets the evidence you need and the earliest realistic launch date.
Read more
- Good practice
- Map each launch market to its classification rule and route, and write down the assumption behind each choice. Revisit the map at every gate, because pathways and rules change.
- Rule of thumb
- Your pathway decides your evidence, and your evidence decides your schedule. Settle it before you commit a launch date.
- Common pitfalls
- Assuming EU classification mirrors the US one; choosing a 510(k) without a solid predicate; forgetting that software or accessories may be classified separately.
- Evidence to show
- A regulatory strategy document with the classification rationale for each market and the planned submission type.
-
Test complexity decides which laboratories can run it, which shapes the market you can sell into.
Read more
- Good practice
- Decide early which complexity category you need, because a waived test needs specific studies showing untrained users get accurate results.
- Rule of thumb
- If the market is clinics and pharmacies, plan for a CLIA waiver from the start.
- Common pitfalls
- Planning point-of-care sales for a test that will be categorized as moderate complexity.
- Evidence to show
- CLIA strategy and, where pursued, the waiver study plan.
-
Feedback from FDA before you test is cheaper than an additional information request during review. See it go wrong in the case study below ↓
Read more
- Good practice
- Compare candidate predicates on intended use, technology and performance before you pick one. Use a Pre-Submission for questions that would change your testing, such as novel test methods or clinical data needs.
- Rule of thumb
- Ask FDA the questions whose answers would change your test plan, not the ones you could answer from guidance.
- Common pitfalls
- Picking a predicate for convenience when its technology differs in ways that raise new questions; asking a Pre-Submission too late to act on the feedback; treating feedback as binding when the design later changes.
- Evidence to show
- Predicate comparison table; Pre-Submission package, FDA feedback and meeting minutes, with how each point was addressed.
-
Needs observed in clinics and homes, not assumed in meetings, become the basis for design validation.
Read more
- Good practice
- Observe users doing the real task in the real setting, including the awkward parts: gloves, poor lighting, interruptions, fatigue. Turn observations into needs written in the user’s terms, and keep the use specification as a controlled document.
- Rule of thumb
- If you haven’t watched at least a few real users do the task, your needs are guesses.
- Common pitfalls
- Needs collected only from key opinion leaders; a use specification that lists one “typical” user; needs written as solutions (“a touchscreen”) instead of outcomes.
- Evidence to show
- Use specification, user research records, and a list of user needs traced to design inputs and validation.
-
Acceptability criteria agreed before analysis keeps later risk decisions consistent and defensible.
Read more
- Good practice
- Agree the acceptability criteria and the method for estimating probability and severity before any analysis, and get top management to approve the policy behind them.
- Rule of thumb
- Decide what “acceptable” means before you see your own numbers.
- Common pitfalls
- Criteria tweaked after the analysis so the results pass; a plan copied from another product with the wrong severity scale; no plan for collecting production and post-production information.
- Evidence to show
- Approved risk management plan, including acceptability criteria, review responsibilities and verification activities.
-
The plan is a controlled record that gets updated as the project changes, not a slide made once for kickoff.
Read more
- Good practice
- Name the phases, the reviews at each, who is responsible for what, and how R&D, quality, regulatory, operations and suppliers hand work to each other. Keep it under document control and update it when the project changes.
- Rule of thumb
- If the plan still matches the kickoff deck six months in, either the project is perfect or nobody is updating the plan.
- Common pitfalls
- A plan that is really just a Gantt chart; interfaces with the contract manufacturer missing; reviews named but never scheduled.
- Evidence to show
- Controlled design and development plan with revision history and evidence of updates at each gate.
-
Engineering trade-offs need a target cost and volume to be made well.
Read more
- Good practice
- Agree a target cost, expected volumes and launch markets early, and treat them as inputs to engineering trade-offs, not just finance slides.
- Rule of thumb
- A design that meets every requirement but can’t be built at the target cost is not done.
- Common pitfalls
- Volume assumptions that never reach the supplier or tooling plans; cost targets set after the design is frozen.
- Evidence to show
- Approved business case, with the assumptions that engineering and operations used.
-
Customers often can’t buy a device they can’t get paid for, however good the clearance.
Read more
- Good practice
- Check early whether existing codes and payment cover the device in each market, and what evidence payers will want, since that can shape the clinical study.
- Rule of thumb
- If nobody can bill for it, clearance won’t sell it.
- Common pitfalls
- Clinical studies designed for clearance only, then repeated for payers; assuming an existing code fits without checking.
- Evidence to show
- Market access plan with coding, coverage and evidence assumptions.
Gate 2
Design inputs approved
Do we know exactly what we are building, how we will prove it works, and who will make it?
-
A requirement nobody can test, or one that contradicts another, tends to surface during verification, the most expensive time to find it.
Read more
- Good practice
- Write each input so it can be verified or validated, trace it to a user need, risk control or regulation, and review the set for conflicts and gaps before approving it.
- Rule of thumb
- If you can’t say how you’ll test a requirement, it isn’t finished.
- Common pitfalls
- Requirements that hide design choices; “TBD” values that stay open until verification; performance targets copied from a competitor’s brochure without knowing the test conditions.
- Evidence to show
- Approved design input document or requirements set, with trace links and the review record.
-
Early hazards drive requirements while the design can still change cheaply.
Read more
- Good practice
- Start the hazard analysis from the intended use, the energy and materials involved, and the use-related tasks, and let it shape the requirements while they are still drafts.
- Rule of thumb
- Every severe hazard should already have a planned risk control by the time inputs are approved.
- Common pitfalls
- Hazard analysis done after the design, to document it rather than shape it; use errors left out because “training will cover it”; risk files that never connect to requirements.
- Evidence to show
- Preliminary hazard analysis and use-related risk analysis, with links to design inputs.
-
The class sets software process rigor, and a cyber device needs cybersecurity documentation in its submission.
Read more
- Good practice
- Assign the software safety class from the hazards the software can contribute to, and decide early whether the device meets the definition of a cyber device. Both drive how much documentation and testing you’ll need.
- Rule of thumb
- Classify for the worst credible harm the software could contribute to, not the harm you hope hardware will prevent, unless that hardware control is independent and verified.
- Common pitfalls
- Assigning a low class to reduce paperwork, then finding a hazard that needs a higher one; ignoring third-party software; treating cybersecurity as a late add-on.
- Evidence to show
- Software development plan with the safety class and rationale; cybersecurity scope and threat model.
-
A late-discovered standard can add months of testing.
Read more
- Good practice
- List the standards that apply to your device and markets, with the edition you will use, and check which are recognized by FDA or harmonized in the EU. Note transitions to new editions.
- Rule of thumb
- Check the edition, not just the standard number. Test labs and reviewers will.
- Common pitfalls
- Testing to an outdated edition; missing a collateral or particular standard; assuming a standard applies to everything when it covers only part of the system.
- Evidence to show
- Standards list with editions, applicability rationale and the test plan for each.
-
Custom parts, tooling and sensors often take longer than the design work around them.
Read more
- Good practice
- Identify parts with long lead times, single sources or custom tooling, and place orders or reservations early. Decide what you will make and what you will buy based on capability, control and cost.
- Rule of thumb
- If a part takes longer to get than to design, order it before the design is final, and accept that some of that money is at risk.
- Common pitfalls
- Discovering a 20-week lead time at pilot build; single-source parts with no qualified alternative; buying off-the-shelf parts without checking the supplier’s change policy.
- Evidence to show
- Make-or-buy decisions, critical components list, lead times and sourcing plan.
-
People who will build and test the device catch problems with fixtures and processes while they are still drawings. See it go wrong in the case study below ↓
Read more
- Good practice
- Choose the manufacturing site or contract manufacturer early enough that its engineers can review drawings, tolerances and test methods before design freeze.
- Rule of thumb
- The people who will build it should see the design while it can still change.
- Common pitfalls
- Selecting a contract manufacturer on price only; involving them after design freeze; no written agreement on responsibilities for validation and records.
- Evidence to show
- Supplier selection record, quality agreement and evidence of manufacturing input to design reviews.
-
Notified body queues can be longer than your design schedule.
Read more
- Good practice
- Confirm the notified body is designated for your device codes, ask about current lead times, and agree the application and review timeline.
- Rule of thumb
- Contact notified bodies before design freeze, not when the file is ready.
- Common pitfalls
- Choosing a body whose designation doesn’t cover the device; discovering long queues after the file is finished.
- Evidence to show
- Notified body agreement, confirmation of scope and the agreed timeline.
-
The notified body needs your SRN and Basic UDI-DI to take the application and issue the certificate.
Read more
- Good practice
- Complete actor registration, name the PRRC, sign the authorised representative mandate if you’re outside the EU, and assign Basic UDI-DIs before you apply.
- Rule of thumb
- Your SRN and Basic UDI-DI come before the application, not before the first shipment.
- Common pitfalls
- Applying before the SRN is issued; Basic UDI-DIs assigned inconsistently with how the technical documentation is grouped.
- Evidence to show
- SRN, PRRC designation, authorised representative mandate and the Basic UDI-DI list.
-
Validation has to use product that represents production, so the build plan and the test plan must agree. See it go wrong in the case study below ↓
Read more
- Good practice
- Plan which verification and validation activities run on which build, and why that build represents production. Include usability, software, biocompatibility, sterilization and clinical evidence where they apply.
- Rule of thumb
- Write down the build for each test now. If the answer is “whatever we have”, plan for repeats.
- Common pitfalls
- Running pivotal tests on engineering prototypes; no plan for changes between builds; validation scheduled before production processes exist.
- Evidence to show
- Verification and validation plan, with a build plan and rationale for each activity.
-
Model performance is only as trustworthy as the data behind it, and reviewers ask how test data was kept independent.
Read more
- Good practice
- Document where data comes from, how it is labeled and checked, how training, tuning and test sets are kept independent, and whether the test data represents the intended users and settings.
- Rule of thumb
- Lock the test set before development starts, and keep it away from the people tuning the model.
- Common pitfalls
- Test data drawn from the same sites or patients as training data; gaps in the populations the device will meet.
- Evidence to show
- Data management plan, dataset descriptions and independence records.
-
Regulation (EU) 2026/1744 postponed the high-risk obligations for AI in products covered by EU product legislation, including medical devices; confirm the application date that applies before planning.
Read more
- Good practice
- Check whether the AI system falls under the AI Act’s high-risk category for regulated products, and plan how its requirements fit into your existing QMS and notified body assessment.
- Rule of thumb
- Plan for one combined technical file where you can, not two separate ones.
- Common pitfalls
- Treating AI Act work as separate from MDR or IVDR compliance; planning around dates that have since changed.
- Evidence to show
- AI Act applicability assessment and the integration plan.
-
Nonsignificant-risk studies have abbreviated requirements; significant-risk studies need FDA approval first, including some that support a 510(k).
Read more
- Good practice
- Decide whether the study is significant risk, and get IDE approval and institutional review board approval before enrolling.
- Rule of thumb
- If in doubt about significant risk, ask FDA early.
- Common pitfalls
- Starting enrollment before approvals; protocol changes without the required notifications.
- Evidence to show
- IDE approval letter, IRB approvals and study records.
-
For Class III and implantable devices, clinical investigations are the default, with limited exceptions.
Read more
- Good practice
- Plan the clinical investigation to answer the questions the clinical evaluation can’t, and check whether any exception for not doing one applies.
- Rule of thumb
- Start talking to the notified body about clinical evidence well before you submit.
- Common pitfalls
- Assuming equivalence to another manufacturer’s device without access to its technical documentation.
- Evidence to show
- Clinical evaluation plan, investigation plan or documented justification.
-
IVDR expects clinical performance studies unless you can justify relying on other sources of clinical performance data.
Read more
- Good practice
- Plan clinical performance studies where existing data can’t show clinical performance for the intended population and specimen types.
- Rule of thumb
- Match the study population to the claim you want to make.
- Common pitfalls
- Studies on populations or specimen types that don’t match the intended use.
- Evidence to show
- Performance evaluation plan and clinical performance study reports.
-
Every EU class needs a clinical evaluation; a late plan usually means late evidence.
Read more
- Good practice
- Write the plan before collecting data: which requirements need clinical evidence, the claimed benefits, outcome measures, acceptance criteria and whether equivalence is realistic.
- Rule of thumb
- If you plan to claim equivalence, check you can get the other device’s technical data first.
- Common pitfalls
- Plans written to match data already collected; equivalence claims without access to the other manufacturer’s documentation.
- Evidence to show
- Approved clinical (or performance) evaluation plan.
-
Record who took part, what was decided and the actions that came out of it.
Read more
- Good practice
- Hold the review with the functions involved in this stage and specialists where needed, record who attended, what was decided and the actions, and close actions before the next review.
- Rule of thumb
- A review with no actions is either a very good design or a very quiet room.
- Common pitfalls
- Reviews that are only status meetings; actions that never close; the same people reviewing their own work every time.
- Evidence to show
- Design review record with attendees, decisions, actions and their closure.
Gate 3
Design freeze
Is the design complete enough to verify, and is everything that could change it under control?
-
Verification only counts if it was done on a known, controlled revision.
Read more
- Good practice
- Release design outputs under document control with clear revision levels, and make sure manufacturing, suppliers and test labs work from released revisions only.
- Rule of thumb
- If it isn’t released, it doesn’t exist for verification.
- Common pitfalls
- Testing on drawings that are still in someone’s inbox; software builds without a recorded version; labeling drafts never placed under control.
- Evidence to show
- Released outputs list, with revisions and approval records.
-
Tracing now shows gaps before verification, not after.
Read more
- Good practice
- Trace every design output to the input it satisfies, and every input to at least one output, with acceptance criteria that verification will use.
- Rule of thumb
- Gaps in the trace now are cheap. Gaps found during verification are expensive. Gaps found by an auditor are worse.
- Common pitfalls
- Trace matrices built at the end to fill a submission; acceptance criteria missing or vaguer than the requirement.
- Evidence to show
- Trace matrix from needs and inputs to outputs and planned verification.
-
For cyber devices, the threat model and software bill of materials are expected in the US submission, so they can’t wait for launch.
Read more
- Good practice
- List every third-party component with its version, requirements and known anomalies, model the threats to the system, and keep the software bill of materials in sync with the build.
- Rule of thumb
- If a library is in the build, it belongs in the software bill of materials.
- Common pitfalls
- Open-source components pulled in without review; threat models done after the design is fixed; an SBOM that doesn’t match the release.
- Evidence to show
- SOUP list with anomaly evaluation, threat model, security architecture and SBOM.
-
Each risk control needs evidence that it is implemented and effective.
Read more
- Good practice
- Analyse how design failures could lead to hazardous situations, link each risk control to a requirement and a planned verification, and update the analysis as the design changes.
- Rule of thumb
- Every risk control needs two pieces of evidence: that it is implemented, and that it works.
- Common pitfalls
- FMEAs scored to make risks look acceptable; controls that rely only on warnings when design changes were possible; analysis frozen while the design keeps moving.
- Evidence to show
- Design risk analysis, risk control trace and planned verification of effectiveness.
-
A surprise in summative testing is the most expensive place to find a user interface problem.
Read more
- Good practice
- Run several small formative studies as the user interface develops, with representative users, and record what changed as a result.
- Rule of thumb
- Test early with rough prototypes. Users find problems in paper mock-ups too.
- Common pitfalls
- Skipping formative work to save time; formative studies only with internal staff; findings logged but not acted on.
- Evidence to show
- User interface specification and formative evaluation records with design changes.
-
Lay users read less, misread more and use devices in uncontrolled settings.
Read more
- Good practice
- Design for people without training, in homes with children, pets, poor lighting and interruptions, and write instructions tested with real lay users.
- Rule of thumb
- Assume lay users will skip the instructions, and design so the device is still safe.
- Common pitfalls
- Instructions written by engineers; reading level too high; no testing in a home-like setting.
- Evidence to show
- Use specification for lay users, labeling comprehension or usability results, and home-use test reports.
-
Sterilization validation, packaging validation and shelf-life aging all depend on the final package. See it go wrong in the case study below ↓
Read more
- Good practice
- Freeze the sterile barrier system and packaging before starting sterilization validation, packaging validation and aging, because each depends on the final configuration.
- Rule of thumb
- Packaging is on the critical path, even when nobody puts it there.
- Common pitfalls
- Changing pouch size or material after validation starts; choosing packaging without checking compatibility with the sterilization method; forgetting the shipping configuration.
- Evidence to show
- Released packaging specifications and the packaging validation plan.
-
A small open item can quietly restart sterilization, packaging or aging work. See it go wrong in the case study below ↓
Read more
- Good practice
- Track each gate condition as an action with an owner and a due date, and check what it could affect downstream, such as validations, tooling or submissions.
- Rule of thumb
- Ask of every open item: if this changes, what would we have to redo?
- Common pitfalls
- Conditions recorded only in meeting minutes; “minor” items that restart validations; conditions quietly rolled forward gate after gate.
- Evidence to show
- Gate conditions log with owners, dates, impact checks and closure evidence.
-
Design change control applies before launch too; many repeated tests come from changes nobody assessed.
Read more
- Good practice
- After freeze, route every change through a change request that assesses impact on verification, validation, risk, labeling, suppliers and submissions before approval.
- Rule of thumb
- After freeze, there are no small changes, only assessed ones.
- Common pitfalls
- Changes made directly to drawings; impact on completed testing not assessed; submissions not updated.
- Evidence to show
- Change records with impact assessments and approvals.
-
A supplier change you hear about after the fact can cost weeks of investigation and requalification. See it go wrong in the case study below ↓
Read more
- Good practice
- Rank suppliers by how much their part affects safety and performance, set controls to match, and put written agreements in place, including notice before changes.
- Rule of thumb
- Your critical suppliers are part of your design. Control them like it.
- Common pitfalls
- Agreements signed after the first problem; no change notification clause; distributors standing between you and the real manufacturer.
- Evidence to show
- Supplier evaluations, approved supplier list, quality agreements and purchasing specifications.
-
Testing on hand-built units can mean repeating it on production units. See it go wrong in the case study below ↓
Read more
- Good practice
- Use units built with production materials, processes and tooling for verification where possible, and document any differences and why they don’t affect the results.
- Rule of thumb
- If a difference could plausibly change a result, assume it does until you show it doesn’t.
- Common pitfalls
- Hand-built units with tighter tolerances than production; prototype materials swapped later; no record of which build was tested.
- Evidence to show
- Build records for verification units and a justification for any differences from production.
-
Material, process and sterilization choices all feed the evaluation.
Read more
- Good practice
- Start the biological evaluation from the materials, processing and patient contact, and use existing data and chemical characterization before planning animal or lab tests.
- Rule of thumb
- Plan the evaluation as soon as materials are chosen. A material change late in development can restart it.
- Common pitfalls
- Testing raw materials instead of the finished, processed device; forgetting colorants, adhesives or processing aids; ignoring the effect of sterilization.
- Evidence to show
- Biological evaluation plan with material characterization and the testing strategy.
-
Record the decision, the open items and who accepted them.
Read more
- Good practice
- Review the frozen design against the inputs, the risk analysis and the verification plan, and record any open items accepted as conditions.
- Rule of thumb
- Freeze means changes now go through formal change control, not a hallway conversation.
- Common pitfalls
- Declaring freeze while key outputs are still changing; no change control between freeze and transfer.
- Evidence to show
- Design review record and the baseline of released outputs.
Gate 4
Verification and validation complete
Have we proven the design meets its requirements and its users’ needs?
-
Every input needs a verification result, or a documented reason why it is covered another way.
Read more
- Good practice
- Verify each input with a method that is suitable and validated where needed, record results and conclusions, and investigate every failure before retesting.
- Rule of thumb
- A retest without an investigation is a coin toss, not verification.
- Common pitfalls
- Sample sizes with no rationale; test methods that weren’t validated; failures explained away; verification on an unreleased revision.
- Evidence to show
- Verification protocols and reports, traced to inputs, with sample size rationale and deviations.
-
Validation shows the device meets user needs and intended uses, not just its specifications. See it go wrong in the case study below ↓
Read more
- Good practice
- Validate on product that represents production, under real or simulated use conditions, with representative users, and record why the units used are representative.
- Rule of thumb
- Verification proves the design meets its inputs. Validation proves the device meets the user’s needs. You need evidence for both.
- Common pitfalls
- Validating on prototypes; validating only in ideal conditions; clinical evidence that doesn’t cover the full intended use.
- Evidence to show
- Validation plan and report, clinical evaluation or performance evaluation, and the rationale for the units used.
-
Studies often follow CLSI methods and should use product made by the production process.
Read more
- Good practice
- Run analytical studies on product made by the production process, using recognized protocols, and report results against predefined acceptance criteria.
- Rule of thumb
- Define acceptance criteria before you run the study, not after you see the data.
- Common pitfalls
- Studies on development lots only; interferents chosen without considering the intended population.
- Evidence to show
- Analytical performance study protocols and reports.
-
Representative users, realistic conditions and production-equivalent devices.
Read more
- Good practice
- Test the critical tasks with representative users, realistic environments and production-equivalent devices, including labeling and training as delivered.
- Rule of thumb
- If the summative test finds a new use error, analyse its root cause and risk; if the risk isn’t acceptable, go back to design.
- Common pitfalls
- Using employees or expert users as participants; testing only the happy path; training participants more than real users will be trained.
- Evidence to show
- Use-related risk analysis, human factors validation protocol and report, with root cause analysis of observed use errors.
-
Patients with implants get MRI scans; missing MR labeling is a common reviewer question.
Read more
- Good practice
- Test magnetically induced displacement and torque, RF heating and image artifacts as relevant, and label the MR conditions clearly on the device labeling and implant card.
- Rule of thumb
- If the device goes into the body, assume it will meet an MRI scanner.
- Common pitfalls
- Testing only one field strength; MR conditions missing from the implant card.
- Evidence to show
- MR safety test reports and MR labeling.
-
Test labs book up early, and a failed EMC test can mean a board respin.
Read more
- Good practice
- Book test labs early, test pre-compliance first, and plan for at least one round of fixes.
- Rule of thumb
- Assume your first EMC test will find something.
- Common pitfalls
- Testing late with no time to redesign; testing a configuration different from the production one.
- Evidence to show
- Electrical safety and EMC test reports for the production configuration.
-
Carriers won’t ship lithium batteries without a UN 38.3 test summary.
Read more
- Good practice
- Check material restrictions, take-back and battery labeling early, and get the UN 38.3 test summary from the battery supplier before the first shipment.
- Rule of thumb
- Ask for the UN 38.3 test summary when you choose the battery, not when you book freight.
- Common pitfalls
- Batteries changed late without new test summaries; WEEE marking missing from labels.
- Evidence to show
- RoHS documentation, WEEE marking, battery labeling and UN 38.3 test summary.
-
In the US, a radio device generally can’t be marketed before its FCC authorization.
Read more
- Good practice
- Plan radio approvals early, test wireless coexistence in realistic environments, and keep the radio configuration fixed once tested.
- Rule of thumb
- Changing the antenna or firmware radio settings can mean retesting.
- Common pitfalls
- Using a pre-certified module but changing its antenna or enclosure; coexistence tested only on a bench.
- Evidence to show
- Radio test reports, equipment authorization and coexistence test results.
-
Release the exact software build that was verified.
Read more
- Good practice
- Verify software against its requirements and risk controls at unit, integration and system level as the safety class requires, and include cybersecurity testing such as penetration testing where applicable.
- Rule of thumb
- The build in the release record should be the same build that’s in the test report.
- Common pitfalls
- Last-minute fixes after verification; third-party software not assessed; known anomalies not evaluated for risk.
- Evidence to show
- Software verification records, anomaly list with risk evaluation, and cybersecurity test reports.
-
IEC 82304-1 covers the product as a whole, around the IEC 62304 software life cycle.
Read more
- Good practice
- Cover the product-level requirements around the software, such as installation, documentation, security and decommissioning.
- Rule of thumb
- Think about how the software is installed, updated and retired, not just how it is built.
- Common pitfalls
- Focusing only on code and forgetting accompanying documents and deployment.
- Evidence to show
- Product requirements and validation records against IEC 82304-1.
-
Testing on the final, sterilized device, or a justification for using existing data.
Read more
- Good practice
- Complete the biological evaluation on the final, sterilized device, combining existing data, chemical characterization and testing, and conclude on biological safety in a report.
- Rule of thumb
- The device that went through the evaluation should be the device you ship.
- Common pitfalls
- Testing an earlier material or process; skipping cumulative-contact considerations for repeat-use devices; a test-only approach with no risk assessment.
- Evidence to show
- Biological evaluation report with the data and rationale behind each conclusion.
-
Phthalates and similar substances can force late design or labeling changes.
Read more
- Good practice
- Screen materials and components early, ask suppliers for substance declarations, and justify and label any restricted substances you can’t avoid.
- Rule of thumb
- Ask suppliers for substance declarations at selection, not after the first audit finding.
- Common pitfalls
- Relying on supplier statements without data; colorants and adhesives missed.
- Evidence to show
- Material screening, supplier declarations and any justification and labeling.
-
For ethylene oxide, residual results can extend aeration and push the schedule. See it go wrong in the case study below ↓
Read more
- Good practice
- Validate the sterilization process for the final product and load configuration, and confirm residuals are within limits after the planned aeration.
- Rule of thumb
- Sterilization validation is only as good as the product and load it was run on.
- Common pitfalls
- Changing load density or packaging after validation; residual testing on the wrong samples; no plan for routine monitoring and revalidation.
- Evidence to show
- Sterilization validation report, residual test results and routine control plan.
-
The expiry date you can claim at launch shapes how much stock to build. See it go wrong in the case study below ↓
Read more
- Good practice
- Validate the packaging system, including transport testing, and start aging on final product as early as possible. Agree the launch expiry date with commercial and supply chain teams.
- Rule of thumb
- Your launch expiry date is set by when aging started, not by when you need it.
- Common pitfalls
- Aging started late on the wrong configuration; accelerated aging run at temperatures that damage materials; real-time aging never followed up.
- Evidence to show
- Packaging validation report, aging protocols and the expiry date justification.
-
Instructions that can’t be followed in a real hospital department will fail in the field.
Read more
- Good practice
- Validate cleaning and disinfection or sterilization instructions with realistic soiling, and write them so a hospital department can follow them.
- Rule of thumb
- If the instructions need equipment the user doesn’t have, they will be ignored.
- Common pitfalls
- Validating with clean devices; instructions that differ from what was validated.
- Evidence to show
- Reprocessing validation reports and the instructions for use.
-
Real-time stability takes as long as the claim, so start it on the first validation lots.
Read more
- Good practice
- Start real-time stability on validation lots as early as possible, and support claims for shelf life, in-use and shipping conditions with data.
- Rule of thumb
- A shelf-life claim can’t be longer than the data behind it, except where a justified accelerated approach is used.
- Common pitfalls
- Shipping stability forgotten; in-use claims based on assumptions.
- Evidence to show
- Stability protocols, data and the justification for each claim.
-
Verification results can change risk estimates; update them before release.
Read more
- Good practice
- Update risk estimates with verification and validation results, evaluate overall residual risk, and document the benefit-risk conclusion before release.
- Rule of thumb
- Test results are new information. If they didn’t change anything in the risk file, check again.
- Common pitfalls
- Risk file updated only at the end, without the evidence trail; residual risks not disclosed in labeling where they should be.
- Evidence to show
- Updated risk management file with evaluation of residual risk and benefit-risk.
-
The notified body reviews this file, and self-certified devices need it too.
Read more
- Good practice
- Build the technical documentation as you go, organised by the annex headings, with the GSPR checklist pointing to the evidence for each requirement.
- Rule of thumb
- If the GSPR checklist says “see test report”, name the report and its revision.
- Common pitfalls
- Files assembled at the end; GSPR entries that don’t point to real evidence; clinical evaluation report out of date with the final design.
- Evidence to show
- Technical documentation, GSPR checklist and approved clinical or performance evaluation report.
-
Labeling controls check printing; this check is about the content, and translations take longer than teams expect.
Read more
- Good practice
- Check label and IFU content against each market’s rules, use standard symbols with an explanation, plan translations early, and confirm whether electronic instructions are allowed for your device and users.
- Rule of thumb
- Start translations as soon as the IFU text is stable; they always take longer than planned.
- Common pitfalls
- Symbols used without a glossary; translations not reviewed by native speakers with product knowledge; electronic instructions offered where paper is required.
- Evidence to show
- Labeling content review record, translations and their verification.
-
Sterilization, biocompatibility, software and cybersecurity sections are common sources of questions. See it go wrong in the case study below ↓
Read more
- Good practice
- Have someone who wasn’t on the project read the submission as a reviewer would, focusing on the areas that most often draw questions.
- Rule of thumb
- If a reviewer has to search for your answer, assume they will ask for it.
- Common pitfalls
- Inconsistent device descriptions across sections; test reports that don’t match the claims; missing rationale for test choices.
- Evidence to show
- Internal submission review record and the final submission package.
-
An unpaid fee or an incomplete eSTAR stops the review before it starts.
Read more
- Good practice
- Use the current eSTAR template, pay the user fee before sending, and apply for a small business determination early if you qualify.
- Rule of thumb
- Check the fee is paid before you submit, not after.
- Common pitfalls
- Outdated templates; missing attachments that eSTAR flags; small business status requested too late to use.
- Evidence to show
- eSTAR submission, payment confirmation and any small business determination.
-
Changes described in an authorized plan can be made without a new submission.
Read more
- Good practice
- Describe the planned modifications, how they’ll be developed and validated, and how their impact will be assessed, and include the plan in the marketing submission.
- Rule of thumb
- Only planned changes described in an authorized plan are covered.
- Common pitfalls
- Plans too vague to authorize; changes made that weren’t in the plan.
- Evidence to show
- Predetermined change control plan in the submission and the authorization.
-
Required for Class C and D devices.
Read more
- Good practice
- Prepare the summary of safety and performance consistent with the technical documentation, in language suited to its readers.
- Rule of thumb
- Draft it alongside the performance evaluation, not after.
- Common pitfalls
- Summaries inconsistent with the performance evaluation report.
- Evidence to show
- Summary of safety and performance submitted to the notified body.
-
Required for implantable and Class III devices; it goes to the notified body with the technical documentation and is published in EUDAMED.
Read more
- Good practice
- Write the summary for its intended readers, including patients where relevant, and keep it consistent with the technical documentation.
- Rule of thumb
- If it contradicts the instructions for use, the notified body will catch it.
- Common pitfalls
- Summaries written in technical language for patients.
- Evidence to show
- Validated summary of safety and clinical performance.
-
Reference laboratory verification adds time to the notified body review.
Read more
- Good practice
- Plan the reference laboratory and common specification steps into the timeline for Class D devices.
- Rule of thumb
- Add time for reference laboratory verification to your EU launch plan.
- Common pitfalls
- Leaving reference laboratory steps out of the schedule.
- Evidence to show
- Plan for reference laboratory involvement and common specification compliance.
-
Confirm every input is verified and every user need validated.
Read more
- Good practice
- Confirm every input has verification evidence, every user need has validation evidence, and the risk file reflects the results.
- Rule of thumb
- If any trace line ends without evidence, the gate isn’t ready.
- Common pitfalls
- Signing off with open test failures; validation pending “after launch”.
- Evidence to show
- Design review record with the trace and evidence summary.
Gate 5
Transfer and production readiness
Can we build, test and release this device consistently, every time?
-
Transfer is a thread through development, not a single handoff at the end. See it go wrong in the case study below ↓
Read more
- Good practice
- Check that each specification can be built and measured on the production line, with the tolerances, fixtures and skills available there, before releasing it for production.
- Rule of thumb
- Transfer is a series of small handovers, not one big one at the end.
- Common pitfalls
- Tolerances only the engineering lab can hold; specifications that assume tools the line doesn’t have; manufacturing seeing drawings for the first time at transfer.
- Evidence to show
- Manufacturability reviews, transfer plan and release records.
-
This is what the old FDA rules called the device master record.
Read more
- Good practice
- Build the medical device file as items are released, with references to controlled documents rather than copies, and assign an owner to keep it current.
- Rule of thumb
- If it takes more than a few minutes to find a current specification, the file isn’t working.
- Common pitfalls
- Files assembled the week before launch; copies that drift from the controlled originals; servicing and installation forgotten.
- Evidence to show
- Medical device file index with links to controlled documents.
-
Bonding, sealing, molding and sterilization usually need validation, not just inspection.
Read more
- Good practice
- Decide for each process whether its output can be fully verified afterwards. Where it can’t, validate it with installation, operational and performance qualification, and define revalidation triggers.
- Rule of thumb
- If you can’t check every unit without destroying it, validate the process.
- Common pitfalls
- Treating inspection as a substitute for validation of sealing, bonding or molding; validating at one set of parameters, then running at others; no revalidation after changes.
- Evidence to show
- Process validation protocols and reports, with parameter windows and revalidation criteria.
-
Test-station and label-printing software is often missed in process validation.
Read more
- Good practice
- List software used in production, testing, labeling and the QMS, and validate each for its intended use, scaled to risk.
- Rule of thumb
- If software makes or records a quality decision, it needs validation.
- Common pitfalls
- Test-station scripts and label templates never validated; spreadsheets used as records without control.
- Evidence to show
- Software inventory and validation records.
-
A method that only works in the engineering lab isn’t ready for the line. See it go wrong in the case study below ↓
Read more
- Good practice
- Validate test and inspection methods on production fixtures, with the operators who will use them, using gauge or measurement system studies where appropriate.
- Rule of thumb
- A test method is part of the product. If it can’t tell good from bad reliably, neither can you.
- Common pitfalls
- Methods developed by one engineer and never transferred; fixtures changed after the study; visual inspection with no defined criteria or training.
- Evidence to show
- Test method validation or gauge study reports and approved inspection procedures.
-
Each process risk control should show up as a check on the line.
Read more
- Good practice
- Analyse how manufacturing steps could lead to hazards, and make sure each process risk control shows up as a check, limit or validated parameter on the line.
- Rule of thumb
- Every process risk control should be visible to an operator.
- Common pitfalls
- Process risk analysis done once and never updated; controls listed in the analysis but missing from work instructions.
- Evidence to show
- Process risk analysis linked to work instructions, inspection points and validated parameters.
-
Choosing good suppliers doesn’t check what they deliver.
Read more
- Good practice
- Define what is checked on receipt for each purchased part, how much, and when you can reduce checks based on supplier performance.
- Rule of thumb
- Reduce inspection only after the supplier has earned it with data.
- Common pitfalls
- No incoming checks for critical parts; certificates accepted without verification.
- Evidence to show
- Incoming inspection procedures, purchasing specifications and inspection records.
-
Calibration status should be visible to the people using the equipment.
Read more
- Good practice
- Qualify production equipment, calibrate measuring equipment against traceable standards, and schedule maintenance, with status visible on the equipment.
- Rule of thumb
- If an operator can’t tell whether a gauge is in calibration, assume it isn’t.
- Common pitfalls
- Equipment used before qualification; calibration intervals copied without rationale; no plan for out-of-tolerance findings.
- Evidence to show
- Equipment qualification records, calibration records and maintenance schedules.
-
Sterilization validation assumes the bioburden stays under control.
Read more
- Good practice
- Define and qualify the environment the product needs, monitor it, and connect results to bioburden and product quality.
- Rule of thumb
- Sterilization validation assumes your bioburden. Monitor it so the assumption stays true.
- Common pitfalls
- Cleanroom classified once and never monitored; bioburden not tracked over time.
- Evidence to show
- Environment specification, qualification and monitoring records, and bioburden data.
-
FDA generally inspects manufacturing before approving a PMA.
Read more
- Good practice
- Prepare manufacturing sites for a pre-approval inspection, with validation, training and records ready for review.
- Rule of thumb
- Run a mock inspection with someone who wasn’t involved in setting up the line.
- Common pitfalls
- Records incomplete because the line was still being set up during review.
- Evidence to show
- Mock inspection report and actions.
-
Train on released procedures, not drafts.
Read more
- Good practice
- Train production staff on released procedures, check their competence, and keep records that show who can perform each task.
- Rule of thumb
- Train on the procedure you’ll use, not the draft you had.
- Common pitfalls
- Training on drafts that later change; competence never assessed; temporary staff missing from the records.
- Evidence to show
- Training records and competence assessments matched to procedures and roles.
-
Checks cover the UDI, expiration date, storage and handling instructions.
Read more
- Good practice
- Inspect labeling for accuracy before release, including the UDI, expiry date and storage instructions, separate different labels physically, and record who released them and when.
- Rule of thumb
- Labeling mix-ups often happen at changeovers. Control the line clearance.
- Common pitfalls
- Old labels left on the line; label artwork approved without checking printed output; no reconciliation of issued and used labels.
- Evidence to show
- Labeling inspection and release records, line clearance records and approved artwork.
-
IVD labeling has its own content requirements on top of the general labeling rules.
Read more
- Good practice
- Check labeling against each element required for IVDs, including intended use, limitations and performance characteristics.
- Rule of thumb
- Build a checklist from the regulation and tick every element before release.
- Common pitfalls
- Performance claims that don’t match study results.
- Evidence to show
- Labeling review record against the requirements.
-
UDI data is needed before labels can be printed and before devices can be registered. See it go wrong in the case study below ↓
Read more
- Good practice
- Assign device identifiers for each model and packaging level, prepare the database records, and check the barcodes print and scan correctly on final packaging.
- Rule of thumb
- Do the UDI data before label artwork is final, not after.
- Common pitfalls
- Data mismatches between labels and the database; packaging levels missed; a new identifier forgotten after a change that requires one.
- Evidence to show
- UDI assignment records, database submissions and label verification.
-
This replaces what the old FDA rules called the device history record.
Read more
- Good practice
- Define what the record for each device or batch contains, including quantities, dates, acceptance results, the UDI and any deviations, and make it easy to retrieve.
- Rule of thumb
- If a complaint arrives, you should be able to pull the full build history within the hour.
- Common pitfalls
- Records scattered across paper and systems; deviations not linked; missing link between a shipped unit and its components.
- Evidence to show
- Record template and a completed example from a pilot or validation lot.
-
Implant traceability has to reach the components and the consignee of each device.
Read more
- Good practice
- Record components, materials and the consignee for each implantable device, so you can trace both ways quickly.
- Rule of thumb
- Test your traceability with a mock recall before launch.
- Common pitfalls
- Distribution records that stop at the distributor.
- Evidence to show
- Traceability records and a mock recall result.
-
You should be able to rebuild exactly what you released.
Read more
- Good practice
- Define how a release is built, versioned, documented and approved, so you can rebuild exactly what you shipped.
- Rule of thumb
- If you can’t rebuild last month’s release, your configuration management isn’t working.
- Common pitfalls
- Releases built on a developer’s machine; release notes missing known anomalies.
- Evidence to show
- Release procedure and release records.
-
The first lots expose tooling, fixture and supplier problems before customers see them. See it go wrong in the case study below ↓
Read more
- Good practice
- Build pilot or validation lots on the production line with production staff and materials, inspect first articles against drawings, and feed findings into fixes before launch.
- Rule of thumb
- The first lots are for learning. Plan time to act on what they teach you.
- Common pitfalls
- Pilot builds run by engineers instead of operators; first article results not reviewed; problems logged but not fixed before launch.
- Evidence to show
- Pilot lot records, first article inspection reports and the list of issues and their resolution.
-
Shipping uncleared devices from the US to the EU needs a specific export route.
Read more
- Good practice
- Confirm the legal route for exporting devices that aren’t yet cleared in the US, and keep the required records.
- Rule of thumb
- Check the export route before the first EU shipment leaves a US site.
- Common pitfalls
- Shipping uncleared devices without checking the export requirements.
- Evidence to show
- Export route documentation and records.
-
Reagent variability between lots is a common source of early complaints.
Read more
- Good practice
- Define lot release tests and show consistency across several validation lots, including different reagent lots where relevant.
- Rule of thumb
- Use more than one lot of critical raw materials in validation.
- Common pitfalls
- Validation lots made from a single lot of each raw material.
- Evidence to show
- Lot release specifications and lot-to-lot study results.
Gate 6
Launch readiness
Can we legally ship, and are we ready for what happens after we do?
-
Inventory can be built before US clearance, but not sold, shipped commercially or taken orders for. See it go wrong in the case study below ↓
Read more
- Good practice
- Confirm the marketing authorization covers exactly the device, configuration and claims you are launching in each market, before the first commercial shipment.
- Rule of thumb
- Ship what was cleared or certified, not what the team improved afterwards.
- Common pitfalls
- Changes made after submission without assessing whether they need a new submission; shipping to a market before the certificate is issued.
- Evidence to show
- Clearance letter, approval or certificate, EU declaration of conformity, and a configuration check against them.
-
Registration and listing are separate from clearance and easy to forget.
Read more
- Good practice
- Register the establishment and list the device with FDA when required, and check that every site involved, including contract manufacturers and sterilizers, is registered where it needs to be.
- Rule of thumb
- Clearance doesn’t register you. Registration is a separate step.
- Common pitfalls
- Forgetting contract sites; listings not updated after changes; missing the annual renewal.
- Evidence to show
- Registration and listing confirmations.
-
New devices have no transition period. See it go wrong in the case study below ↓
Read more
- Good practice
- Register the actor and the device in EUDAMED, with the Basic UDI-DI and UDI-DI data, before the first unit is placed on the EU market, and keep the data current after changes.
- Rule of thumb
- Since 28 May 2026, no registration means no first shipment of a new device in the EU.
- Common pitfalls
- Assuming the old voluntary rules; data that doesn’t match the labels or the technical documentation.
- Evidence to show
- EUDAMED actor and device registration records.
-
Micro and small enterprises may have the PRRC permanently available externally rather than on staff.
Read more
- Good practice
- Designate the person responsible for regulatory compliance with the required expertise, and appoint authorised representatives and agents where the manufacturer is outside the market.
- Rule of thumb
- Name a deputy too. Regulatory responsibilities don’t pause for holidays.
- Common pitfalls
- Naming someone without the required qualifications; agreements with representatives that don’t cover their legal duties.
- Evidence to show
- Designation records, qualification evidence and representative agreements.
-
Calls treated as tech support are still complaints. See it go wrong in the case study below ↓
Read more
- Good practice
- Define what counts as a complaint, make the route for logging one easy for everyone who talks to customers, and cover every component, accessory and software release.
- Rule of thumb
- Any report that a released device fell short is a complaint until you’ve decided otherwise. When in doubt, log it and close it with a reason.
- Common pitfalls
- Service calls and sales conversations that never reach the complaint system; procedures written only for the main component; no link to reportability decisions.
- Evidence to show
- Complaint procedure, training records for customer-facing staff and the complaint log.
-
These operators share your obligations but won’t meet them unless the agreements spell them out.
Read more
- Good practice
- Agree in writing what importers and distributors must do: check CE marking and labeling, add importer details, forward complaints, keep storage conditions and records.
- Rule of thumb
- Your importer is your first line of EU compliance. Brief them like it.
- Common pitfalls
- Importer details missing from packaging; complaints stuck at distributors.
- Evidence to show
- Importer and distributor agreements and their EUDAMED registrations.
-
The new EU Product Liability Directive also covers software, for products placed on the market or put into service after 9 December 2026.
Read more
- Good practice
- Arrange product liability cover proportionate to the device’s risk and your company size, and check how new rules covering software affect it.
- Rule of thumb
- Check the cover includes software and AI features, not just hardware.
- Common pitfalls
- Policies that exclude software or the EU.
- Evidence to show
- Insurance certificate or equivalent financial coverage.
-
Deadlines start when you become aware of an event, not when the investigation ends.
Read more
- Good practice
- Write procedures that identify, evaluate and report events within the required timelines in each market, and practise them before launch.
- Rule of thumb
- The reporting clock starts when the company becomes aware, which is usually earlier than when the report reaches quality.
- Common pitfalls
- Treating “still investigating” as a reason to wait; unclear criteria for what is reportable; no one trained to submit reports.
- Evidence to show
- Reporting procedures, decision criteria and training records.
-
Define what “higher than expected” means before the data arrives.
Read more
- Good practice
- Plan which data you will collect after launch, how often you will analyse it, and the thresholds that trigger action, and connect it to the risk file.
- Rule of thumb
- Define “higher than expected” before the data arrives.
- Common pitfalls
- Plans that list sources but no analysis; thresholds missing; field data never fed back to risk management.
- Evidence to show
- Post-market surveillance plan, with trend methods and thresholds.
-
Know who decides and who reports before you need to.
Read more
- Good practice
- Define who decides on corrections and removals, who reports them, and how you will find affected devices and customers.
- Rule of thumb
- Run a short tabletop exercise before launch. It’s cheaper than learning in a real recall.
- Common pitfalls
- No traceability to customers; unclear decision authority; reports filed late.
- Evidence to show
- Procedure for corrections and removals and the traceability approach.
-
Many changes to a PMA device need FDA approval before they’re made.
Read more
- Good practice
- Set up the processes for annual reports and for deciding when a change needs a PMA supplement, before the first change arrives.
- Rule of thumb
- For a PMA device, assume a change needs FDA input until you show otherwise.
- Common pitfalls
- Changes made under internal change control without assessing supplement requirements.
- Evidence to show
- Procedures for PMA reports and supplements.
-
A reusable display or handpiece needs a repair and loaner process on day one.
Read more
- Good practice
- Set up servicing, repair and loaner processes for reusable or serviceable parts, with records, and decide which service events need evaluation as complaints.
- Rule of thumb
- Every service event is field data. Look at it.
- Common pitfalls
- Service handled by a separate team that never reports trends; repairs without records; no spare parts plan.
- Evidence to show
- Servicing procedure, service records template and the link to complaint handling.
-
Under the QMSR, FDA can review management review and internal audit records.
Read more
- Good practice
- Run an internal audit across the QMS, hold a management review before launch, make sure CAPA is working, and have the required certificate in place.
- Rule of thumb
- Find your own gaps before an auditor or investigator does.
- Common pitfalls
- First internal audit scheduled after launch; CAPA system set up but never used.
- Evidence to show
- Internal audit report, management review record, CAPA records and certificates.
-
The first patch is usually needed sooner than planned.
Read more
- Good practice
- Define how field problems are logged, evaluated for risk, fixed, verified and released, and how users are told.
- Rule of thumb
- Plan your first maintenance release before launch.
- Common pitfalls
- Hotfixes released without verification; problem reports not linked to complaints.
- Evidence to show
- Software maintenance plan and problem resolution records.
-
Required in US submissions for cyber devices (devices that include software, can connect to the internet and could be vulnerable to cybersecurity threats); EU Annex I also requires IT security for devices with software.
Read more
- Good practice
- Monitor known vulnerabilities in your software and its components, disclose and patch in a coordinated way, and keep the software bill of materials current.
- Rule of thumb
- Your software bill of materials is only useful if someone checks it against new vulnerabilities.
- Common pitfalls
- An SBOM produced for the submission and never updated.
- Evidence to show
- Postmarket cybersecurity plan, SBOM and vulnerability management records.
-
Claims beyond the authorized intended use are a common launch-week mistake.
Read more
- Good practice
- Review every promotional piece against the authorized intended use and indications, and keep records of approvals.
- Rule of thumb
- If the claim isn’t in the indications, it doesn’t go in the brochure.
- Common pitfalls
- Social media posts written by sales; trade-show demos showing unapproved uses; old materials still in circulation.
- Evidence to show
- Promotional review procedure and approval records.
-
Patients keep the card, so its content has to be ready before the first implant.
Read more
- Good practice
- Prepare the implant card and patient information with the required content, and plan how they reach the patient.
- Rule of thumb
- Check the card is readable by patients, not just accurate.
- Common pitfalls
- Cards not supplied with the device; information inconsistent with labeling.
- Evidence to show
- Implant card, patient information and their review records.
-
FDA can order tracking for Class II or III devices whose failure would likely have serious adverse health consequences, or that are life-sustaining or life-supporting and used outside a device user facility.
Read more
- Good practice
- Check whether FDA has ordered tracking for your device type, and if so set up the tracking system and records before launch.
- Rule of thumb
- If tracking applies, test that you can locate devices quickly.
- Common pitfalls
- Assuming distribution records meet tracking requirements.
- Evidence to show
- Tracking procedure and records.
-
The people customers call first need to know what counts as a complaint. See it go wrong in the case study below ↓
Read more
- Good practice
- Train sales, customer service and clinical trainers on the device, the instructions for use, and how to recognise and log a complaint.
- Rule of thumb
- The first person a customer calls should know what to do with the call.
- Common pitfalls
- Training focused only on selling; no refresher when the instructions change.
- Evidence to show
- Training materials and records.
-
You should be able to find every shipped device or batch quickly.
Read more
- Good practice
- Release inventory only after acceptance activities are complete, and make sure distribution records let you trace devices to customers.
- Rule of thumb
- You should be able to find every shipped unit of a batch quickly.
- Common pitfalls
- Shipping before release; distributor records you can’t access; returns not traced.
- Evidence to show
- Release records and distribution records.
-
The review confirms the plan was carried out, overall residual risk is acceptable, and post-production methods are in place.
Read more
- Good practice
- Review that the risk management plan was carried out, that overall residual risk is acceptable, and that methods to collect production and post-production information are in place, and approve the report.
- Rule of thumb
- The risk management report is the summary an auditor reads first. Make it stand on its own.
- Common pitfalls
- Report written as a formality; post-production information collection not actually set up.
- Evidence to show
- Approved risk management report.
-
This is what the old FDA rules called the design history file, and auditors often ask for it first.
Read more
- Good practice
- Keep the design and development file current through the project, with links to each record rather than copies.
- Rule of thumb
- If it takes more than a few minutes to show the evidence for a requirement, the file isn’t ready.
- Common pitfalls
- Files assembled the week before launch; missing records of design changes.
- Evidence to show
- Design and development file index with links to records.
-
From launch on, every change to the device goes through design change control.
Read more
- Good practice
- Hold a launch review that confirms every check is done or has an accepted owner and date, and hand over to change control and post-market surveillance.
- Rule of thumb
- After launch, every change is a design change until you show otherwise.
- Common pitfalls
- Open items left without owners; changes made in the first weeks without going through change control.
- Evidence to show
- Launch review record and the handover to sustaining.
After the last gate
Launch is where NPI ends and two other processes take over. Every change to the device, its labeling, its suppliers or its manufacturing now goes through design change control, including a check on whether the change needs a new submission. And the post-market surveillance plan starts collecting the field data that will confirm, or challenge, the risk estimates made before launch.[1][3]
Hold a short retrospective a few weeks after the first shipment, while the details are fresh. Which checks were done late, which were done twice, and which were missing from this list? Fold the answers into your own gate template before the next project starts.
Case study
The Launch That Slipped Five Months
What happens when these checks are skipped? No single disaster delayed the Tavora. Eight ordinary problems did, each one small when it started, and together they pushed the launch back five months. Here is the launch, gate by gate: what happened, and which check would have caught it earlier.
The Tavora, its team and its timeline are fictional. The problems are composites of failure patterns common in device launches, and the regulatory requirements cited are real.
The plan
The Tavora is a sterile, single-use scope for looking inside the bladder in a urology clinic, paired with a reusable handheld display that shows and records the image. Each scope is built by a contract manufacturer, packed in a sealed pouch, sterilized with ethylene oxide (EtO) and thrown away after one procedure. The display is charged, wiped down and used again.
That mix made the Tavora a typical new product introduction (NPI): electronics and software from the development team, a molded and bonded scope built by someone else, a sterile barrier and a shelf life to prove, labeling with unique device identifiers (UDIs), and a 510(k) in the US followed by CE marking in the EU. The plan gave each of those a lane, with a US launch in September 2025.
Here's how the plan and reality compare. The numbered markers match the sections below.
Scroll sideways to see the whole timeline.
1 · January 2025 · Design freeze
The freeze that wasn't
The design freeze gate passed “with conditions.” Two items were still open: the adhesive for the scope's bending section, and the size of the sterile pouch. Neither looked serious. Both were written into the gate minutes, and neither had an owner or a due date.
The pouch was the one that hurt. In April, packaging engineering moved to a larger pouch so the scope's cable wouldn't kink. A sensible change, but the sterilization validation, the packaging validation and the shelf-life aging all depend on the final pouch, and none of them could start until it was settled. Nobody at the gate had asked what the open items could invalidate downstream.
What would have caught it
Treat every gate condition as a tracked action with an owner, a date and a list of what it could affect. If closing a condition could restart sterilization, packaging or aging work, it isn't a minor condition; it's a reason to hold the gate, or to start that work at risk with eyes open.
2 · March–July 2025 · Design validation
Validated on the wrong scopes
To save time, the team ran summative usability testing and its design validation on scopes hand-built in the engineering lab. The contract manufacturer's first production scopes arrived a month later, and urologists who tried them noticed straight away: the bending section was stiffer.
ISO 13485 requires design validation on product that represents production, such as early production units or an equivalent, and the team must record why its choice qualifies.[1] The team had no rationale that would stand up, because the units weren't equivalent. Part of the validation had to be repeated on production scopes, which cost five weeks.
What would have caught it
Decide at planning time which build each verification and validation activity will use, and write down why that build represents production. If the production process isn't ready, the honest choice is usually to wait, or to run the test early as a formative study and repeat the part that counts.
3 · May 2025 · Pilot build
A supplier change nobody announced
During the first pilot build, some scopes came out of sterilization with hazy edges on the image. It took three weeks to trace: the camera module supplier had switched the adhesive that holds the lens, a change it considered minor. The new adhesive didn't tolerate the EtO cycle as well as the old one.
The purchase agreement didn't require the supplier to report changes. Where it applies, ISO 13485 expects a written commitment from the supplier to warn the manufacturer before making any change that could affect whether its part still meets requirements.[1] Reverting the adhesive, requalifying the module and rebuilding the pilot lot took seven weeks in all.
What would have caught it
Rank suppliers by how much their part affects safety and performance, and put change notification into the agreements with the critical ones before the first pilot build, not after the first surprise. For the Tavora, the camera module, the bending section, the pouch and the contract sterilizer were all critical.
4 · June 2025 · Design transfer
Transfer treated as a handoff
The plan showed design transfer as a single box near the end: hand the drawings, specifications and test methods to the contract manufacturer, and start building. In practice, the leak test that checks every scope's seal failed its first gauge study on the manufacturer's line. It had been developed in the engineering lab on a different fixture, by the engineer who designed it.
ISO 13485 expects a team to show, before release, that its design outputs can be built to specification on the production line, and that the line can do it consistently.[1] A test method that only works in one person's hands isn't ready. Redesigning the fixture and repeating the study took three weeks, mostly hidden behind the supplier problem.
This kind of problem doesn't always stay hidden. When FDA reviewed 437 Class II recalls from October 2019 to September 2020, the most common root cause was process control: how devices are made, rather than how they were designed.[55]
What would have caught it
Run transfer as a thread through development, not a box at the end. Bring manufacturing and quality engineers in before design freeze, validate test methods on the production fixtures with the people who'll use them, and check the medical device file is complete as items are released, not all at once.[1]
5 · July–October 2025 · Sterilization and shelf life
Sterile, but for how long?
Because the pouch changed late (section 1), the EtO validation started two months behind plan. The first runs showed EtO residuals above the team's acceptance limits, which are based on ISO 10993-7.[28][32] The larger pouch and the denser shipping carton slowed aeration. Longer aeration fixed it, but the validation had to be partly repeated.
The shelf-life plan had a second problem. Accelerated aging, which uses heat to simulate time, can only start once the final product and sterile barrier exist. ASTM F1980 describes the method, and ISO 11607-1 accepts accelerated aging as evidence for the sterile barrier's expiry date while real-time aging continues. The device's own stability needs its own evidence.[33][14] With the late start, an aging temperature limited by the lens adhesive, and only the data in hand by the time of the 510(k) response, the team could support just a six-month expiry at launch instead of the planned two years. Nobody had told the commercial team, who had planned inventory around two years.
What would have caught it
Put sterilization, packaging validation and aging on the critical path from day one, and work out the expiry date you can support at launch from the date aging can start. Share that date with the commercial and supply chain teams; a short expiry changes how much stock to build and where to hold it.
6 · July 2025–January 2026 · 510(k)
Ninety days isn't three months
The plan assumed clearance three months after submission. FDA's review goal for a 510(k) is counted in FDA days, and the clock stops while a submission is on hold waiting for answers.[56] The Tavora went on hold about two months into review, with an additional information request covering EtO residuals and software documentation. A submission on hold has 180 calendar days to respond; the team took eleven weeks, partly because the repeated sterilization work in section 5 meant new residual data had to be generated.[56]
Clearance came in mid-January 2026, and the first commercial shipment left in February. Until clearance, the team could build inventory but couldn't sell or ship it commercially.
What would have caught it
Plan launches around a realistic clearance range, not the review goal. Assume at least one round of questions, and have the evidence most likely to draw them, such as sterilization, biocompatibility, software and cybersecurity, reviewed by someone outside the project before you submit.
7 · February–March 2026 · US launch
Ready to ship, not ready to support
In the first week, three clinics called about the display freezing mid-procedure. The calls went to sales, who treated them as tech support: they talked the clinics through a restart and moved on. The complaint handling procedure had been written with the single-use scope in mind and didn't mention the display at all.
The gap surfaced a month later, in an internal audit. Every one of those calls should have been logged and evaluated as a complaint, including whether it needed a medical device report.[1][44][49] They were logged late, investigated (a firmware timing fault) and judged not reportable, but the late records became an audit finding.
What would have caught it
Make post-market readiness part of the launch gate, with the same weight as inventory. Before the first shipment, everyone who talks to customers should know what counts as a complaint and where it goes, and the procedure should cover every part of the system, including accessories and reusable components.
8 · April–July 2026 · EU launch
A regulatory assumption that went out of date
The EU launch slipped behind the US one while the notified body finished its review. By the time the certificate arrived, the rules had changed under the plan's feet. Since 28 May 2026, the first four EUDAMED modules have been mandatory, and a new device must be registered in EUDAMED before the first unit is placed on the EU market. There's no transition period for new devices.[48][3]
The launch plan, written in 2024, had assumed registration could follow later. Registering the device in EUDAMED, with its Basic UDI-DI and UDI-DI data, added three weeks before the first EU shipment in July.
What would have caught it
Re-check regulatory assumptions at every gate, not just at the start. A launch plan can easily outlive the rules it was written under, as US teams also found when the QMSR replaced the old quality system regulation on 2 February 2026.[57]
What added up to five months
None of the eight problems was a delay of five months on its own. They stacked: an open condition at design freeze moved the pouch, the pouch moved sterilization, sterilization moved the submission and the expiry date, and the hold moved clearance. Meanwhile, the supplier and test method problems ate the slack that might have absorbed the rest.
In their retrospective, the team agreed on a short list of changes for the next product:
Each one gets an owner, a date and an impact check, and the next gate starts by closing them.
Decide which build each verification and validation activity uses, and why it represents production.
Change notification and quality agreements are in place before the first pilot build.
Manufacturing owns test methods and fixtures from design freeze, and the medical device file grows as items are released.
Packaging is frozen first, and the launch expiry date is agreed with commercial teams early.
Launch dates assume a round of questions, not the review goal.
Complaint handling covers every component and every person who talks to customers, before the first shipment.
Each gate confirms the regulatory assumptions are still current in every market.
Questions worth asking at your next gate review
Copy these into your gate template and see how many your team can answer with evidence, not opinion. For the full list, use the gate-by-gate checklist above.
- Which open items are we accepting as conditions, and what work could each one restart?
- Which build will each remaining verification and validation activity use, and why does it represent production?
- Do our critical suppliers have to tell us about changes before they make them?
- Has every test method been validated on the production fixture, by the people who'll run it?
- What expiry date can we support at launch, and do the commercial and supply chain teams know it?
- What clearance range are we planning around, and what happens to the launch if we get questions?
- Does complaint handling cover every component, and does everyone who talks to customers know how to log one?
- Which regulatory assumptions in this plan have changed since we wrote it?
References
- ISO 13485:2016, Medical devices — Quality management systems — Requirements for regulatory purposes. Incorporated by reference into 21 CFR Part 820 since 2 February 2026. www.iso.org/standard/59752.html
- 21 CFR Part 807 (establishment registration and device listing; Subpart E, premarket notification), Part 814 (premarket approval) and Part 860 Subpart D (De Novo classification). www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-807
- Regulation (EU) 2017/745 on medical devices (EU MDR), including Articles 1, 7–11, 13–15, 18–20, 25, 27–29, 31–32, 51–52, 61–62, 84–89 and 117, and Annexes I–III and XIV. eur-lex.europa.eu/eli/reg/2017/745/oj
- U.S. FDA, CLIA Categorizations. www.fda.gov/medical-devices/ivd-regulatory-assistance/clia-categorizations
- U.S. FDA, Requests for Feedback and Meetings for Medical Device Submissions: The Q-Submission Program, guidance for industry and FDA staff. www.fda.gov/regulatory-information/search-fda-guidance-documents/requests-feedback-and-meetings-medical-device-submissions-q-submission-program
- IEC 62366-1:2015+AMD1:2020, Medical devices — Part 1: Application of usability engineering to medical devices. webstore.iec.ch/en/publication/67220
- ISO 14971:2019, Medical devices — Application of risk management to medical devices. www.iso.org/standard/72704.html
- IEC 62304:2006+AMD1:2015, Medical device software — Software life cycle processes. webstore.iec.ch/en/publication/22790
- U.S. FDA, Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions, final guidance, February 2026 (section 524B of the FD&C Act, cyber devices). www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket
- Regulation (EU) 2024/1689 laying down harmonised rules on artificial intelligence (AI Act), as amended by Regulation (EU) 2026/1744. eur-lex.europa.eu/eli/reg/2024/1689/oj
- 21 CFR Part 812, Investigational device exemptions. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-812
- Regulation (EU) 2017/746 on in vitro diagnostic medical devices (EU IVDR). eur-lex.europa.eu/eli/reg/2017/746/oj
- IEC 60601-1-11, Medical electrical equipment — Requirements for medical electrical equipment and medical electrical systems used in the home healthcare environment.
- ISO 11607-1:2019+Amd 1:2023, Packaging for terminally sterilized medical devices — Part 1: Requirements for materials, sterile barrier systems and packaging systems. www.iso.org/standard/70799.html
- ISO 10993-1:2025, Biological evaluation of medical devices — Part 1: Requirements and general principles for the evaluation of biological safety within a risk management process, November 2025. www.iso.org/standard/84512.html
- U.S. FDA, Testing and Labeling Medical Devices for Safety in the Magnetic Resonance (MR) Environment, guidance for industry and FDA staff. www.fda.gov/regulatory-information/search-fda-guidance-documents/testing-and-labeling-medical-devices-safety-magnetic-resonance-mr-environment
- ASTM F2503, Standard Practice for Marking Medical Devices and Other Items for Safety in the Magnetic Resonance Environment.
- IEC 60601-1:2005+AMD1:2012+AMD2:2020, Medical electrical equipment — Part 1: General requirements for basic safety and essential performance, and IEC 60601-1-2:2014+AMD1:2020 (electromagnetic disturbances). webstore.iec.ch/en/publication/67497
- Directive 2011/65/EU on the restriction of hazardous substances in electrical and electronic equipment (RoHS). eur-lex.europa.eu/eli/dir/2011/65/oj
- Directive 2012/19/EU on waste electrical and electronic equipment (WEEE). eur-lex.europa.eu/eli/dir/2012/19/oj
- Regulation (EU) 2023/1542 concerning batteries and waste batteries. eur-lex.europa.eu/eli/reg/2023/1542/oj
- 49 CFR 173.185, Lithium cells and batteries (including the UN 38.3 test summary). www.ecfr.gov/current/title-49/subtitle-B/chapter-I/subchapter-C/part-173/subpart-E/section-173.185
- Directive 2014/53/EU on radio equipment (RED). eur-lex.europa.eu/eli/dir/2014/53/oj
- 47 CFR Part 2, Subpart J, Equipment authorization procedures, and § 2.803 (marketing of radio frequency devices prior to authorization). www.ecfr.gov/current/title-47/chapter-I/subchapter-A/part-2/subpart-I/section-2.803
- U.S. FDA, Radio Frequency Wireless Technology in Medical Devices, guidance for industry and FDA staff. www.fda.gov/regulatory-information/search-fda-guidance-documents/radio-frequency-wireless-technology-medical-devices-guidance-industry-and-fda-staff
- IEC 82304-1:2016, Health software — Part 1: General requirements for product safety. webstore.iec.ch/en/publication/26120
- Regulation (EC) No 1907/2006 (REACH), Article 33. eur-lex.europa.eu/eli/reg/2006/1907/oj
- ISO 11135:2014+Amd 1:2018, Sterilization of health-care products — Ethylene oxide — Requirements for the development, validation and routine control of a sterilization process for medical devices. www.iso.org/standard/56137.html
- ISO 11137-1:2025, Sterilization of health care products — Radiation — Part 1: Requirements for the development, validation and routine control of a sterilization process for medical devices.
- ISO 17665:2024, Sterilization of health care products — Moist heat — Requirements for the development, validation and routine control of a sterilization process for medical devices.
- ISO 11737-1, Sterilization of health care products — Microbiological methods — Part 1: Determination of a population of microorganisms on products.
- ISO 10993-7:2026, Biological evaluation of medical devices — Part 7: Ethylene oxide sterilization residuals. It replaced the 2008 edition in April 2026; the case study, set in 2025, used the 2008 edition. www.iso.org/standard/84824.html
- ASTM F1980-21, Standard Guide for Accelerated Aging of Sterile Barrier Systems and Medical Devices. store.astm.org/f1980-21.html
- U.S. FDA, Reprocessing Medical Devices in Health Care Settings: Validation Methods and Labeling, guidance for industry and FDA staff. www.fda.gov/regulatory-information/search-fda-guidance-documents/reprocessing-medical-devices-health-care-settings-validation-methods-and-labeling
- ISO 17664-1:2021, Processing of health care products — Information to be provided by the medical device manufacturer for the processing of medical devices — Part 1: Critical, semi-critical and non-critical medical devices. www.iso.org/standard/81720.html
- 21 CFR Part 801, Labeling. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-801
- ISO 15223-1:2021, Medical devices — Symbols to be used with information to be supplied by the manufacturer — Part 1: General requirements.
- Commission Implementing Regulation (EU) 2021/2226 on electronic instructions for use of medical devices, as amended by Implementing Regulation (EU) 2025/1234 (applies to devices under the MDR). eur-lex.europa.eu/eli/reg_impl/2021/2226/oj
- U.S. FDA, eSTAR Program. www.fda.gov/medical-devices/how-study-and-market-your-device/estar-program
- U.S. FDA, Medical Device User Fee Amendments (MDUFA), including small business determination. www.fda.gov/industry/fda-user-fee-programs/medical-device-user-fee-amendments-mdufa
- U.S. FDA, Marketing Submission Recommendations for a Predetermined Change Control Plan for Artificial Intelligence-Enabled Device Software Functions, final guidance, December 2024, updated August 2025 (FD&C Act section 515C). www.fda.gov/regulatory-information/search-fda-guidance-documents/marketing-submission-recommendations-predetermined-change-control-plan-artificial-intelligence
- Global Harmonization Task Force, SG3/N99-10:2004, Quality Management Systems — Process Validation Guidance (hosted by IMDRF). www.imdrf.org/sites/default/files/docs/ghtf/final/sg3/technical-docs/ghtf-sg3-n99-10-2004-qms-process-guidance-04010.doc
- ISO 14644-1, Cleanrooms and associated controlled environments — Part 1: Classification of air cleanliness by particle concentration.
- 21 CFR Part 820, Quality Management System Regulation: § 820.35 (control of records) and § 820.45 (device labeling and packaging controls). www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-820
- 21 CFR 809.10, Labeling for in vitro diagnostic products. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-809
- U.S. FDA, Unique Device Identification System (UDI System): 21 CFR 801.20 and Part 830, including the Global Unique Device Identification Database (GUDID). www.fda.gov/medical-devices/device-advice-comprehensive-regulatory-assistance/unique-device-identification-system-udi-system
- Federal Food, Drug, and Cosmetic Act sections 801(e) and 802 (21 U.S.C. 381(e), 382), export of devices. uscode.house.gov/view.xhtml?req=granuleid:USC-prelim-title21-section382
- Health Products Regulatory Authority (Ireland), Mandatory use of EUDAMED modules for medical devices. www.hpra.ie/news-events/news/article/mandatory-use-of-eudamed-modules-for-medical-devices
- 21 CFR Part 803, Medical Device Reporting, including § 803.17 (written MDR procedures). www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-803
- 21 CFR Part 806, Medical devices; reports of corrections and removals. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-806
- 21 CFR Part 814, Premarket approval of medical devices, including § 814.39 (PMA supplements) and § 814.84 (reports). www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-814
- U.S. FDA, Quality Management System Regulation: Frequently Asked Questions. www.fda.gov/medical-devices/quality-management-system-regulation-qmsr/quality-management-system-regulation-frequently-asked-questions
- U.S. FDA, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, guidance for industry and FDA staff. www.fda.gov/regulatory-information/search-fda-guidance-documents/deciding-when-submit-510k-software-change-existing-device
- 21 CFR Part 821, Medical device tracking requirements. www.ecfr.gov/current/title-21/chapter-I/subchapter-H/part-821
- U.S. FDA, Office of Medical Device and Radiological Health Operations, Recalls presentation (Class II recall analysis, October 2019–September 2020), OMDRHO virtual conference, 23 June 2021. www.fda.gov/media/150413/download
- U.S. FDA, FDA and Industry Actions on Premarket Notification (510(k)) Submissions: Effect on FDA Review Clock and Goals, guidance for industry and FDA staff. www.fda.gov/regulatory-information/search-fda-guidance-documents/fda-and-industry-actions-premarket-notification-510k-submissions-effect-fda-review-clock-and-goals
- U.S. FDA, Medical Devices; Quality System Regulation Amendments, final rule, Federal Register 89 FR 7496, 2 February 2024 (effective 2 February 2026). www.federalregister.gov/documents/2024/02/02/2024-01709/medical-devices-quality-system-regulation-amendments
The Tavora, its team and its timeline are fictional and do not describe any real product or company. This checklist is general guidance, not legal or regulatory advice. Gate names and the order of items are illustrative; adapt them to your own procedures, device type and markets. Requirements are paraphrased; check the current text of each standard and regulation before relying on it.