Key Takeaways:

• FDA scales software documentation to risk. Its 2023 software guidance recommends one of two documentation levels. Enhanced applies when a software failure could probably lead to death or serious injury, and both levels still call for a requirements specification with traceability, an architecture chart, a risk management file, and system-level test evidence.
• Recent changes make older 510(k) checklists unreliable. Every 510(k) now goes through FDA’s eSTAR template and a technical screening, the Quality Management System Regulation replaced the old design control section with ISO 13485 in February 2026, and FDA reissued its cybersecurity guidance the following day.
• Most submissions get at least one round of questions. From fiscal 2018 through 2022, 63% to 68% of 510(k)s received an Additional Information request on the first review cycle, and a sponsor gets one complete response, due within 180 days.

If you’re a digital health CTO, medical device product lead, or pharma innovation director preparing your first software-enabled device for market, your 510(k) documentation largely decides how long review takes. FDA aims to decide within 90 FDA days, but that clock stops whenever FDA asks for more information, and average total review times ran from 127 to 159 calendar days between fiscal 2018 and 2022.

FDA expects organized evidence that your device is substantially equivalent to a legally marketed predicate. For software, that means traceability from requirements through validation, cybersecurity documentation required by statute since March 2023, and design records that connect each software function to the clinical claims you’re making. This guide covers the software documentation to have in place before you submit, document by document, with a readiness checklist at the end.

You’ll often hear the outcome called 510(k) approval. FDA’s term is clearance. It clears 510(k)s and approves premarket approval applications, and regulatory reviewers notice the difference.

What the 510(k) Pathway Covers

The 510(k) premarket notification lets a manufacturer market most Class II devices, along with some Class I and Class III devices, by showing substantial equivalence to a device already legally marketed in the United States. Every 510(k) rests on that comparison to a predicate. For software-enabled products, the comparison gets harder when the software itself is what’s new.

Not every piece of health software needs a 510(k). Software is regulated only when it meets the device definition in section 201(h) of the Federal Food, Drug, and Cosmetic Act, and even then some functions are excluded by statute or fall under FDA’s enforcement discretion. Clinical decision support that meets the Cures Act criteria, for example, isn’t a device at all. Software that is a device needs a 510(k) when a suitable predicate exists, a De Novo request when it’s novel and low to moderate risk, and premarket approval when it’s high risk. Dogtown’s guide to software as a medical device covers that classification question in more depth.

Connected diagnostic apps, remote patient monitoring platforms, and software that controls or influences a device’s therapeutic function commonly land in 510(k) territory. Settle the classification question first, because everything below assumes a 510(k) is the right pathway.

Selecting a Valid Predicate When Software Is the Differentiator

Your predicate must share your device’s intended use, and any technological differences can’t raise different questions of safety and effectiveness. For software, the comparison covers algorithms, data processing logic, the user interface, and connectivity architecture. If your device uses machine learning where the predicate used rule-based logic, or adds cloud connectivity to a previously standalone system, document those differences along with the testing that shows they don’t introduce new risks.

The legal standard for a predicate is narrower than many teams assume. A predicate has to have been legally marketed, but it doesn’t have to be on the market today, so a device discontinued for commercial reasons can still serve. Under section 513(i) of the FD&C Act, the exclusions are devices FDA removed from the market and devices a court has found adulterated or misbranded, as Covington’s analysis of FDA’s 2023 proposals explains.

FDA’s preferences go further than the law. A September 2023 draft guidance on predicate selection, which FDA hasn’t finalized, recommends predicates that were cleared using well-established methods, meet or exceed expected safety and performance, have no unmitigated use-related or design-related safety issues, and have no associated design-related recall. The draft doesn’t set bright-line rules, but a predicate that misses these marks invites questions during review. Search FDA’s 510(k) database by product code, then check recall and adverse event data for each candidate before you commit.

Your Design and Development File

Many 510(k) guides still cite the Design History File required under 21 CFR 820.30. That citation is out of date. On February 2, 2026, FDA’s Quality Management System Regulation took effect, incorporating ISO 13485:2016 by reference. Design controls now come from clause 7.3 of ISO 13485, and the regulation no longer uses the term design history file. Its ISO counterpart is the design and development file, and the content expectations carried over largely intact. Plenty of teams still say DHF.

Whatever you call it, the file is a living record of development. For software, it’s how you show that each functional requirement traces forward to implementation, verification tests, and validation results, and that production code traces back to a documented user need. Inspections changed with the regulation too. FDA withdrew its long-standing inspection technique on February 2, 2026, and investigators now assess compliance against the QMSR. An ISO 13485 certificate doesn’t establish QMSR compliance on its own, because the regulation adds FDA-specific requirements on top of the standard.

What the File Contains

For a software device, the design and development file typically holds design inputs documenting user needs and intended use, design outputs such as the software requirements specification and detailed design documents, verification records showing outputs meet inputs, validation records showing the finished device meets user needs in realistic use, design review records, design transfer documentation, and design change records that preserve traceability as requirements evolve. Most of what you submit to FDA is drawn from this file, which is why it has to exist before the submission does.

Documentation Levels: Basic Versus Enhanced

FDA’s Content of Premarket Submissions for Device Software Functions guidance, issued June 14, 2023, replaced the old minor, moderate, and major Level of Concern with two Documentation Levels. Enhanced applies when a failure or flaw in any device software function could present a hazardous situation with a probable risk of death or serious injury to a patient, a user, or others in the environment of use, assessed before risk controls are applied. Basic applies everywhere else. Like all FDA guidance, it’s a recommendation, and it’s also the standard reviewers apply.

The levels differ less than many teams expect.

Documentation element	Basic	Enhanced
Documentation level evaluation	Included	Included
Software description	Included	Included
Risk management file	Included	Included
Software requirements specification, with traceability	Included	Included
System and software architecture design chart	Included	Included
Software design specification	Kept in your design file, not submitted	Submitted
Development, configuration management, and maintenance practices	Declaration of conformity to IEC 62304, or summaries of the life cycle and configuration management	Basic, plus complete configuration management and maintenance plans
Testing as part of verification and validation	Summary of unit, integration, and system testing, plus the full system-level protocol and report	Basic, plus unit and integration test protocols and reports
Software version history	Included	Included
Unresolved software anomalies	Included	Included

Basic still demands full traceability. What it drops is the design specification in the submission and the lower-level test protocols. Submitting Basic documentation for a device that meets the Enhanced threshold is a reliable way to earn deficiencies, so state the level and its rationale up front. FDA’s eSTAR template has incorporated this documentation level approach since version 4.

How to Make the Documentation Level Call

The determination is its own submission element: a statement of the level and the rationale behind it, tied to your intended use and referencing your risk management file and software description. FDA’s guidance sets out how to reach it.

Assess risk before your risk controls. If a failure or latent flaw could present a hazardous situation with a probable risk of death or serious injury without your mitigations in place, the device is Enhanced, however well those mitigations work. FDA defines probable to exclude purely hypothetical risks, and serious injury means an injury that’s life threatening, causes permanent impairment, or requires intervention to prevent permanent impairment. Count reasonably foreseeable misuse, and count the chance that inadequate cybersecurity compromises the device.

The guidance includes worked examples, and several map directly onto digital health products. A prescription computerized behavioral therapy device for psychiatric disorders, an over-the-counter app that flags irregular heart rhythms suggestive of atrial fibrillation, and a phone-based eye movement aid for assessing concussion are all Basic in FDA’s examples. A sepsis alarm for critical care, a continuous glucose monitoring system, and an AI-enabled retinal diagnostic are all Enhanced. FDA cautions that its examples don’t set the level for a device type, so every device gets its own assessment.

A few categories carry a default. FDA generally recommends Enhanced for Class III devices and for device constituents of combination products, though a sponsor can argue for Basic with a detailed rationale. If you’re unsure, a Pre-Submission is the place to settle it before you file.

What Goes Into Each Software Document

FDA’s guidance describes each element in detail. Here’s what it asks for.

Software Description

The description is an overview of significant features and functions, with images, flow charts, or state diagrams where they help. FDA frames it as a set of questions worth answering directly. What role does the software play in the intended use, who uses it, and for which patient population? What hardware and software platforms does it run on, including hosting environments such as cloud infrastructure, and does it use off-the-shelf software? What are the inputs and outputs, who or what provides and receives them, and which manual steps in the clinical workflow does the software automate or replace? Is it interoperable with other devices or systems, such as an EHR integration? For a modified device, cite the earlier submission number and highlight what’s changed since clearance.

Risk Management File

Following ISO 14971, FDA recommends a risk management plan with acceptability criteria set before the first risk evaluation, a risk assessment, and a risk management report confirming the overall residual risk is acceptable. The assessment covers hazards and foreseeable misuse, risk estimation and severity, risk controls in priority order (design first, then protective measures, then information for safety), verification that each control was implemented and works, and residual risk. Because software failure probabilities are hard to estimate, FDA notes it can be prudent to assume a failure will occur, setting its probability to 1, and to focus on the consequences.

Software Requirements Specification

The SRS covers inputs and outputs, functions, hardware, performance, interfaces, user interaction, error handling, the intended operating environment, safety requirements derived from the risk assessment, and every range, limit, default, and specific value the software accepts. Give each requirement a unique identifier, make it testable, and describe your identification and tracking method. FDA accepts the artifacts modern teams already produce, including well-elaborated user stories, use cases, screen mockups, and data flows. It also recommends flagging the requirements most critical to safety and effectiveness so reviewers can find them quickly.

System and Software Architecture Diagram

The diagram is a roadmap: the modules and layers of the system, how they relate, how data flows between them, and how users and external products, including cloud infrastructure and connected devices, interact with it. FDA warns that a diagram that’s too high-level, too detailed, or illegible can trigger requests for more information, so keep notation consistent, define acronyms, and reference related documents. For an app-based product, show the mobile app, the cloud services, and any connected devices as distinct modules.

Software Design Specification

The SDS explains how the software implements each requirement in the SRS. For Enhanced devices, it’s submitted, and FDA expects it to have been written prospectively and used to guide development, with minimal ad hoc design decisions. For Basic devices, it stays in your design file, where FDA can request it during review.

Version History and Unresolved Anomalies

The version history is a line-item table of every tested version, with dates and a brief description of changes, ending with the release version and any differences between it and the last tested build. The unresolved anomalies list covers every known defect you’ve chosen not to fix: a description, how it was found and its root cause where known, its impact on safety and effectiveness including human factors, and the risk-based rationale for leaving it. FDA suggests classifying defects with a taxonomy such as ANSI/AAMI SW91 and referencing any communication to users about workarounds.

A Worked Traceability Example

FDA’s guidance illustrates traceability as a chain of identifiers. A hazard (HAZ-XXX) traces to a design control in the requirements (SRS-XXX) and design specification (SDS-XXX), which traces to unit, integration, and system tests (UT-XXX, INT-XXX, SYS-XXX). Here’s how one row might look for a hypothetical remote monitoring app that alerts a care team when a patient’s readings cross a threshold.

Link in the chain	Example entry
Hazard	HAZ-014: A dropped Bluetooth connection goes unnoticed, so out-of-range readings never reach the care team
Requirement	SRS-022: The app alerts the patient within 60 seconds of losing the sensor connection and logs the gap
Design	SDS-031: Connection watchdog service, alert manager, and gap log
Tests	UT-118 watchdog timer, INT-045 sensor-to-alert path, and SYS-207 end-to-end disconnect scenario, all passing
Residual risk	Acceptable under the risk management plan, with labeling that describes the alert

Repeat that for every hazard and requirement and you have a requirements traceability matrix. FDA lets sponsors present it as a separate document, and it becomes the single artifact a reviewer can use to follow any requirement from intent to evidence without searching hundreds of pages.

Software Verification and Validation

FDA distinguishes verification, which confirms each design output meets its design input at the unit, integration, and system levels, from validation, which confirms the finished device meets user needs and intended uses in realistic conditions. Every software 510(k) needs evidence of both, scaled to its documentation level.

At the Basic level, FDA expects a summary of testing at all three levels, the full system-level protocol and report, documentation of any intentional changes made after failed tests, and a regression analysis showing which tests you reran after each change. Enhanced adds the unit and integration test protocols and reports.

Validation Under Real Use Conditions

Validation has to reflect how the device is actually used. For a clinical decision support tool, that means clinicians working with the interface under time pressure with realistic patient data. For a remote monitoring platform, it means connectivity on poor networks, battery performance over extended sessions, and whether users understand alerts and notifications. If your intended users include older patients, include older patients. If the device will be used in emergency departments, validate in time-constrained, high-distraction settings.

Validation that rests entirely on benchtop testing or simulated users can draw scrutiny. The results need to show that the device meets its requirements and that intended users can operate it safely and effectively. Where use errors could cause harm, plan human factors work alongside software validation.

Off-the-Shelf Software and Third-Party Components

Very little medical software is built from scratch. An app-based product runs on iOS or Android, calls cloud services, and depends on open-source libraries. FDA treats all of that as off-the-shelf software: generally available components the manufacturer can’t claim complete life cycle control over. The international software standard IEC 62304 calls the same thing SOUP, software of unknown provenance.

FDA’s off-the-shelf software guidance, updated August 11, 2023 to match the Basic and Enhanced framework, asks for a description of each component and what you do to keep using it safely, a risk assessment of each component inside your risk management file, and testing commensurate with your documentation level. Enhanced documentation adds assurance about the component developer’s methodologies and your plan for continued maintenance and support.

The level can vary by component. In an Enhanced device, an AI/ML library that drives the clinical function follows Enhanced documentation, while an operating system or cloud platform whose failure wouldn’t create unacceptable risk can follow Basic, as MD101 Consulting’s analysis of FDA’s examples shows. Either way, plan for each dependency’s life cycle. Operating system updates, deprecated libraries, and vendor end-of-support dates all become change-control events, and the same component inventory feeds your SBOM.

Cybersecurity Documentation

Section 524B of the FD&C Act, enacted December 29, 2022, made cybersecurity a statutory premarket requirement for cyber devices starting March 29, 2023. A device is a cyber device when it meets every part of the statute’s definition: it includes software validated, installed, or authorized by the sponsor, it can connect to the internet, and it has technological characteristics that could be vulnerable to cybersecurity threats. FDA reads the connectivity element broadly, so treat Wi-Fi, cellular, Bluetooth, and wired network connections as in scope, and check update mechanisms and service ports as well. Products built around medical wearables and phone pairing often qualify.

For a cyber device, section 524B requires the premarket submission to include:

• A postmarket vulnerability plan covering how you’ll monitor, identify, and address vulnerabilities and exploits, including coordinated vulnerability disclosure.
• Processes for reasonable assurance of cybersecurity, including making updates and patches available.
• A software bill of materials that includes commercial, open-source, and off-the-shelf software components.

What FDA’s Guidance Adds

FDA’s current cybersecurity guidance, reissued February 3, 2026 to align with the QMSR, explains how FDA expects you to meet those obligations. It organizes secure design around a set of security objectives: authenticity including integrity, authorization, availability, confidentiality, and secure and timely updatability and patchability. Your submission should show how the architecture achieves each objective, document the threat model behind your risk assessment, and demonstrate that controls were designed in from the start.

The guidance also asks more of the SBOM than the statute’s minimum. FDA recommends an SBOM that includes the NTIA minimum elements and each component’s level of support and end-of-support date where known. It also applies its recommendations to devices with cybersecurity risk that don’t meet the cyber device definition, so a device without internet connectivity isn’t automatically exempt from security documentation.

Vulnerability Management

Your postmarket plan should describe how you’ll monitor sources such as the National Vulnerability Database, how quickly you can develop, test, and release patches, how you’ll communicate security issues to users, and how outside researchers can report problems through a coordinated disclosure policy. Suppliers belong in the plan too, since a vulnerability in a third-party library becomes your vulnerability once it ships in your device.

Documentation for AI-Enabled Software

AI-enabled device software needs everything above plus disclosures about the model itself, and some of that is already expected under final guidance. The 2023 software guidance’s description questions ask AI-enabled sponsors which methods, models, and frameworks they used, what data informed the model and how, when, and where it was collected, what steps they took to identify and address bias, and how they provide transparency about the model’s development, performance, and limitations.

FDA’s January 2025 draft guidance on AI-enabled device software functions goes further and covers the whole product life cycle. It recommends documenting data management, including how training, tuning, and test data were collected and how the test data were kept independent. It also covers a description of the model and how it was developed, performance validation that includes results across relevant patient subgroups, a plan for monitoring performance after launch, AI-specific cybersecurity threats such as data poisoning, and labeling and public summaries that explain how the model works and where its limits are.

It’s still a draft. FDA put finalizing it at the top of its fiscal 2027 guidance priorities, published October 1, 2026, alongside a planned draft on evidence for generative AI conversational devices for mental disorders. Treat the current draft as the direction of travel, and teams building mental health chatbots should watch for the generative AI draft.

An AI function that informs a diagnosis can easily reach the Enhanced level, as FDA’s retinal screening example does. If you expect to retrain or update the model after clearance, build a predetermined change control plan into the original submission. Without one, a significant model change can require a new 510(k). Dogtown’s AI-powered healthcare app development work plans for that from the first model design review.

How to Package It: eSTAR

Every 510(k) now goes through eSTAR, FDA’s electronic Submission Template And Resource, which has been mandatory since October 1, 2023 unless an exemption applies. eSTAR is an interactive template that organizes content into the sections FDA reviews, prompts for required attachments, and checks completeness as you build it.

It also changed acceptance review. eSTAR submissions don’t go through the traditional refuse-to-accept checklist. FDA instead runs a virus scan and a technical screening within about 15 days. If the eSTAR is incomplete, FDA identifies what’s missing and places the submission on hold, and a complete replacement eSTAR has to arrive within 180 days or the 510(k) is considered withdrawn.

Inside eSTAR, traceability is still the organizing principle for software. Lead with the documentation level and its rationale, then cover the software description, the requirements specification, the architecture chart, the design specification for Enhanced devices, development and maintenance practices, verification and validation evidence, the risk management file, off-the-shelf software documentation, cybersecurity documentation and the SBOM for cyber devices, the version history, and the unresolved anomalies list. Keep terminology and identifiers identical across every section, because a reviewer following one requirement through five attachments will notice when they don’t match.

Review Timelines and What Triggers Delays

FDA’s user fee commitments target a decision on 95% of 510(k)s within 90 FDA days. FDA days pause while a submission is on hold, and most submissions spend time on hold. According to FDA’s MDUFA V performance reporting, as summarized by Hyman, Phelps & McNamara, 63% to 68% of 510(k)s submitted from fiscal 2018 through 2022 received an Additional Information request on the first review cycle, and average total time to decision ran from 127 to 159 calendar days.

An Additional Information request stops the clock and gives you a maximum of 180 calendar days to respond. You get one complete response, with no option to answer part now and the rest later, and if the response doesn’t resolve every deficiency, FDA can find the device not substantially equivalent. FDA typically offers a short call within 10 days to clarify what it’s asking for, and a Submission Issue Request lets you get feedback on your plan to resolve deficiencies before you respond.

For software devices, deficiencies tend to cluster in familiar places: traceability gaps between requirements and tests, validation that doesn’t reflect real use, thin or missing cybersecurity documentation, a substantial equivalence argument that doesn’t explain how the software differs from the predicate, unresolved anomalies without risk justification, and a requirements specification too vague to show what the device actually does.

Use a Pre-Submission

A Pre-Submission lets you put your predicate choice, substantial equivalence rationale, documentation level, testing strategy, and cybersecurity approach in front of FDA before you file. There’s no fee, and FDA aims to send written feedback within about 70 days. FDA’s feedback is nonbinding, and its value lies in surfacing fundamental disagreements while they’re still cheap to fix.

Build the Documentation as You Build the Software

Regulatory consultants can shape submission strategy and format, but the technical evidence FDA reviews has to come from your engineering process: traceability built in from the first requirement, a design and development file maintained as the device evolves, verification and validation run against documented protocols, and cybersecurity controls designed alongside the architecture.

FDA’s software guidance makes the timing point itself. It warns that design documentation “created retrospectively,” or long after development, could raise concerns about whether a developer has adequate control of its design process. Teams that start assembling 510(k) documentation a few weeks before a planned submission often find gaps in traceability, test coverage, and design rationale that take months to close. Planning documentation during the requirements phase, following ISO 13485 and IEC 62304 practices, and validating security controls as you build them keeps a submission date realistic.

A Pre-Submission Readiness Checklist

Before you file, confirm each of these is in place.

• Pathway confirmed. The software meets the device definition, isn’t excluded or under enforcement discretion, and a 510(k) is the right route.
• Predicate selected and vetted. It shares your intended use, technological differences are documented, and its recall and adverse event history has been checked.
• Documentation level determined. The level and rationale are written down, assessed before risk controls, and consistent with the risk management file.
• Core documents complete. The software description, risk management file, SRS, architecture diagram, development practices or IEC 62304 declaration, version history, and unresolved anomalies list are ready, plus the SDS for Enhanced devices.
• Traceability closed. Every requirement traces to a passing test and every hazard to a verified control, with nothing orphaned in either direction.
• Testing evidence assembled. The system-level protocol and report and the regression analysis are done, plus unit and integration protocols for Enhanced devices.
• Off-the-shelf components documented. Each one is described, risk-assessed, and tested at the right level.
• Cybersecurity package ready. Cyber devices have a threat model, security architecture, SBOM, and postmarket vulnerability plan.
• AI disclosures prepared. AI-enabled functions have a model description, data management documentation, subgroup performance results, and a change control plan if the model will be updated.
• eSTAR built and cross-checked. Every attachment sits in its slot, and identifiers and terminology match across sections.
• Pre-Submission considered. Open questions on predicate, testing, or documentation level have gone to FDA before filing.

Why Partner With Dogtown Media

Dogtown Media builds medical device apps, software as a medical device, remote patient monitoring platforms, digital therapeutics, and clinical decision support tools for organizations ranging from early-stage startups to major health systems. Our healthcare portfolio spans consumer wellness products through medical-grade software that requires FDA submissions.

A 510(k)-ready software product depends on engineering and regulatory work moving together. We help teams build FDA-ready software architecture and documentation for medical device applications, with regulatory planning starting at the requirements phase. For products adding AI or machine learning, our AI compliance and risk mitigation practice covers model documentation and change control planning.

If you’re preparing a software 510(k), request a free consultation to talk through your regulatory pathway and documentation plan.

Frequently Asked Questions

Do I need a new 510(k) for every software update?

No. FDA’s 2017 guidance on deciding when to submit a 510(k) for a software change asks whether a change introduces a new risk or modifies an existing one in a way that could cause significant harm, changes a risk control that prevents significant harm, or could significantly affect clinical functionality or performance. Changes that meet those tests generally need a new 510(k). Bug fixes, cosmetic changes that don’t affect function, and infrastructure changes with no effect on safety or effectiveness often don’t, but document the rationale in your change records, measured against the most recently cleared version. For changes you can foresee, a predetermined change control plan cleared with your 510(k) lets you make them later without a new submission. FDA issued draft guidance on these plans for all devices in August 2024, and its final guidance for AI-enabled devices, first issued in December 2024, was updated in August 2025.

When a change does need a new submission, a Special 510(k) is often the faster route. It’s available when you’re changing your own legally marketed device, performance data are either unnecessary or come from well-established methods, and the results can be reviewed in a summary or risk analysis format. FDA generally reviews Special 510(k)s within 30 days of receipt, against 90 days for a Traditional 510(k). Changes that hinge on detailed new performance data, such as clinical results, belong in a Traditional 510(k) instead, as FDA’s 2019 Special 510(k) guidance explains.

Can I use agile development and still meet FDA documentation expectations?

Yes. FDA’s software guidance says it doesn’t recommend any particular life cycle model, naming agile alongside waterfall and spiral. Agile works as long as the documentation shows design controls were followed: user stories and acceptance criteria detailed enough to serve as testable requirements, documented sprint reviews that function as design reviews, and automated test results captured and traced to requirements. At each release, you still need validation against user needs.

What happens if my predicate device is recalled after I submit?

A recall doesn’t automatically invalidate a pending submission or an existing clearance. A device FDA removes from the market, or one a court finds adulterated or misbranded, can’t serve as a predicate, and FDA’s 2023 draft guidance recommends choosing a different predicate when yours has a design-related recall and a valid alternative exists. If the recall stems from a design issue your device shares, expect FDA to question your substantial equivalence argument. Monitor FDA’s recall database for your predicates and be ready to explain why your device doesn’t carry the same risk.

Do I need clinical data for a software-only 510(k)?

Often not. Many software 510(k)s rely on verification, validation, and performance testing, and FDA asks for clinical data when that testing can’t establish substantial equivalence. It’s more likely when the device informs a diagnosis, uses a novel algorithm without a well-established predicate, carries higher risk, or rests its equivalence argument on better performance than the predicate. FDA released a 2023 draft guidance on clinical data in 510(k)s alongside its predicate proposals. If you do need clinical evidence, plan the study with your clinical trial and regulatory teams early.

Can I reference another company’s records in my 510(k)?

You can’t reference another manufacturer’s design file. You can reference your predicate’s public 510(k) summary and FDA-recognized consensus standards. If you use a component another company supplies, that supplier may hold a device master file with FDA that you can reference with the supplier’s written authorization, which keeps their proprietary details confidential while giving FDA what it needs. You remain responsible for integrating the component safely and validating the complete device.