The FDA's Refuse to Accept (RTA) policy for 510(k) submissions is designed to ensure that only administratively complete submissions enter substantive review. Under the policy, FDA reviewers conduct an initial screening of each 510(k) within 15 business days of receipt to determine whether the submission contains all required elements. If the submission is found deficient during this screening, FDA issues an RTA letter and the submission is placed on hold pending receipt of a complete response. An RTA decision effectively restarts the review clock and can add weeks or months to the time-to-clearance timeline, making it one of the most avoidable sources of 510(k) delay.
The RTA Checklist: What FDA Reviews
FDA uses a standardized RTA checklist to evaluate 510(k) completeness. The checklist covers both administrative requirements and basic substantive elements. Key areas include:
- Cover letter and truthful and accurate statement: The submission must include a signed cover letter and the legally required statement of truthfulness and accuracy from an authorized representative
- Device description: A complete description of the device including materials, components, software, accessories, and intended use must be present
- Substantial equivalence comparison: The submission must identify a predicate device and provide a comparison of intended use and technological characteristics
- Performance testing summary: At minimum, a summary of the performance testing performed must be included, even if protocols and full data are not required at the RTA stage
- Proposed labeling: Draft labeling sufficient to assess the intended use and indications for use must be included
- Software documentation: If the device contains software, the appropriate level of software documentation (minor, moderate, or major concern level) must be present
Most Common RTA Failures
Based on FDA's published RTA data and industry experience, the most frequently cited deficiencies in RTA decisions involve inadequate predicate identification - particularly submissions that fail to explain why the predicate is legally marketed and substantially equivalent - incomplete intended use statements, missing or insufficient software documentation for devices with software functions that meet the major concern level threshold, and labeling that does not include all required elements for the device type. Submissions that reference testing that was performed but do not include even a summary of the results are also frequently cited.
Software-Specific RTA Issues
Software documentation has become an increasingly common source of RTA decisions as the proportion of 510(k) submissions involving software-containing devices has grown. FDA's software documentation requirements are tiered by the level of concern, ranging from minor concern (basic documentation sufficient) to major concern (full software documentation including Software Requirements Specifications, architecture design documentation, software development and maintenance plan, and hazard analysis). Manufacturers often misjudge the appropriate level of concern for their device, submitting inadequate documentation for devices that FDA considers to have major concern level software. Engaging a regulatory consultant to assess the software level of concern determination before submission can prevent this category of RTA.
Pre-Submission Strategies to Avoid RTA
The most effective strategy for avoiding an RTA decision is a rigorous internal pre-submission review against FDA's published RTA checklist before the submission is filed. The checklist is publicly available and should be treated as a mandatory compliance document, not an optional reference. For complex submissions - particularly those involving novel device technologies, multiple software functions, or combination products - a pre-submission meeting with FDA (Q-Sub) to align on submission content expectations is worth the additional time investment. FDA's response to a Q-Sub can confirm the predicate strategy, clarify performance testing expectations, and address software documentation questions before the review clock starts. Sequence Group's submission team conducts thorough RTA pre-review as a standard component of all 510(k) preparation engagements.
Frequently Asked Questions
What is the FDA's Refuse to Accept (RTA) policy and how does it affect the 510(k) review timeline?
The RTA policy requires FDA reviewers to screen each 510(k) within 15 business days of receipt to determine whether it contains all required elements. If the submission is found deficient, FDA issues an RTA letter and places the submission on hold. This effectively restarts the review clock and can add weeks or months to the time-to-clearance timeline. An RTA decision is one of the most avoidable sources of 510(k) delay because the deficiencies it cites are typically administrative rather than substantive.
What are the most common reasons a 510(k) submission receives an RTA decision?
The most frequently cited RTA deficiencies involve inadequate predicate identification - particularly submissions that fail to explain why the predicate is legally marketed and substantially equivalent - incomplete intended use statements, missing or insufficient software documentation for devices with major concern level software functions, and labeling that does not include all required elements for the device type. Submissions that reference testing but do not include even a summary of results are also frequently cited.
How are software documentation requirements structured for 510(k) submissions?
FDA's software documentation requirements are tiered by level of concern: minor, moderate, and major. Minor concern devices require only basic documentation. Moderate concern devices require an intermediate level of documentation. Major concern devices require full software documentation including Software Requirements Specifications, architecture design documentation, software development and maintenance plan, and hazard analysis. Misjudging the appropriate level of concern and submitting inadequate documentation is a common source of RTA decisions for software-containing devices.