FDA 510k Submission

PHASE I

Stages

Activity

Responsibility

Timeline

1

CLIENT

20 Days

2

CLIENT + I3C

3

CLIENT + I3C

4

CLIENT

PHASE II

5

 I3C

90 Days

6

 I3C

7

I 3 C

8

CLIENT

9

 I3C

10

 I3C

11

CLIENT + I3C

12

CLIENT + I3C

13

CLIENT + I3C

PHASE III

14

 I3C

90 Days

15

 I3C

16

I 3 C

17

 I3C

PHASE  IV

18

CLIENT

20 Days

19

CLIENT

20

 I3C

21

CLIENT

22

CLIENT

PHASE V

23

CLIENT + I3C

24

 I3C

25

CLIENT

510K Section

Topic

510k file Contents

However, Sections E and F can be tricky. It is recommended to take a moment to carefully read and understand these two sections. Section E asks for information about the predicate device, while Section F asks for information about your device.The problem is that both sections are listed one after the other, with no white space to separate them. Although there is a black line separating them, it can still be confusing. As a result, people often make the mistake of adding the predicate device name in Section F instead of their own product name.

• Type of 510(k) Submission: Specify whether it is Abbreviated or Traditional.
• Device Description: Clearly state your device type in common terms.
• Submitter Information: Include the 510(k) submitter’s details.
• Contact Information: Provide the name, title, and phone number of at least one contact person.
• Confidentiality Preference: Indicate your preference for continued confidentiality in accordance with 21 CFR 807.95.
• Recommended Classification: Suggest a classification regulation and class (I, II, or III).
• Review Panel and Product Code: Mention the review panel and FDA product code.
• Prior Correspondence: List any related FDA document numbers from prior formal correspondence (e.g., IDE, pre-IDE, 510(k), PMA, RFD).

Remember that the FDA makes this summary public within 30 days of their decision, so it’s important to balance the inclusion of sufficient details while meeting the FDA’s minimum requirements and maintaining strategic confidentiality.

The summary should encapsulate the essence of your submission, including information from the cover letter, a comparison of substantial equivalence, and a synopsis of the testing performed

• Financial Certification: Used if the payment to clinical investigators was solely for the study costs without additional incentives.
• Disclosure Statement: Required if the clinical investigators were paid beyond the study costs. This form also necessitates details on mitigating potential bias.

The goal here is to give the FDA reviewer a thorough understanding of your device, laying the groundwork for the substantial equivalence Discussion.

• Detailed drawings from design outputs, including dimensions for each model/variant,
• Details about accessories, and components.
• Device specifications of components that come into patient contact.
• Compliance with any device-specific guidance documents, if applicable.

Demonstrate step-by-step how your device is similar or equivalent to the predicate in terms of indications for use, technology, and performance.

Prepare a comparison table made in an easy-to-read table that highlights key similarities and differences without giving exhaustive information

This section encompasses all labels and other written, printed, or graphic matter upon the immediate container of any medical device

Specimen Label (Primary, secondary and or tertiary)
Specimen IFU / Packing inserts in the English language

Name and Place of Business (21 CFR 801.1)
Intended Use 21 CFR 801.4
Adequate Directions 21 CFR 801.5
False or Misleading Statements 21 CFR 801.6
Prominence of Statements 21 CFR 801.15

Exemptions may be granted in those instances where device labelling lacks sufficient space for required labelling under conditions.

Medical devices are sterilized in a variety of ways including using moist heat (steam), dry heat, radiation, ethylene oxide (EtO) gas, vaporized hydrogen peroxide, and other sterilization methods (for example, chlorine dioxide gas, vaporized peracetic acid, and nitrogen dioxide).

Keep in mind that not all products require shelf-life testing. If your product is less likely to degrade over time, explain why shelf-life testing is not applicable.

Device shelf-life claims must be supported with appropriate testing data.

If any part of your device comes into direct or indirect contact with patients, demonstrate that the materials used are safe and compatible with their intended use.

FDA may give an exception if your device is identical in material and manufacturing to the predicate device.

• Overview of significant software features and their functions including images, flow charts, and state diagrams.
• Describe the role of the software, the intended user of the software, and the analysis methodology for the software performance
• Mention the software platforms that are used
• Mention the final release version
• Provide the clinical workflow steps and mention if the device is interoperable

Risk Management File

• Risk management plan
• Risk Assessment
• Risk Management Report

In compliance with ISO 14971 for Safety Risk Management.

Cybersecurity Risk Management File
Cybersecurity plan, security risk assessment demonstrating that risks have been appropriately mitigated and VAPT test report.

Software Requirements Specification (SRS)
The SRS documents the requirements for the software like

• Inputs and outputs
• Functional and capability requirements that the software will perform
• Software-driven alarms, warnings, and operators’ messages
• Security requirements
• Data definition and database requirements
• Installation and acceptance requirements
• Hardware
• Programming language
• Compiler version
• Performance
• Interfaces between software and the other system
• User interface requirements implemented
• Requirements related to its network aspects.
• Error definition and handling
• Response times
• Intended operating environment
• Safety-related requirements derived from a risk assessment
• Regulatory requirements
• User maintenance requirements

Traceability

• Should trace all the SRS to SDS, Test Case IDs (at each level of testing), Software Version and release, Risk Assessment IDs.

System and Software Architecture Diagram
The roadmap of the device design should include:

• The modules and layers that make up the system and software.
• The relationships among the modules and layers.
• The data inputs/outputs and flow of data among the modules and layers
• How users or external products, including IT infrastructure and peripherals (e.g., wirelessly connected medical devices) interact with the system and software.
• The software architecture diagram may comprise multiple static diagrams, dynamic diagrams, and cybersecurity architecture diagrams to convey the information clearly to facilitate the review process. If more than one diagram is used, the sponsor should provide a high-level diagram that communicates the overview and points to other diagrams, and the relationship between diagrams.
• For multiple-function device products, the system and software architecture diagram should delineate between the device functions under review and the “other functions.”

Software Design Specification (SDS)

Basic Documentation Level
SDS not required as part of the premarket submission. Sponsors should document this information on the design internally via the DHF for the device.

Enhanced Documentation Level

• Technical design details of how the software functions, how the software design completely and correctly implements all the requirements of the SRS, and how the software design traces to the SRS in terms of intended use, functionality, safety, and effectiveness.
• Software functional units or modules and the interfaces identified in the architectural (i.e., high-level) design should be documented with the corresponding detailed (i.e., low-level) design information in the SDS.

Software Development, Configuration Management, and Maintenance Practices
Basic Documentation Level

The summary information should include the following:

• Processes and procedures used in software development, verification and validation.
• Standards (e.g., coding), methods and tools used in software development.
• Main deliverables of the typical activities and tasks involved in software development, verification and validation.
• Processes, procedures, and tools used to link user needs, system requirements, software requirements, software design specifications, software testing and implemented risk control measures (i.e., traceability).
• Processes and procedures used in software configuration and change management.
• Processes and procedures used in software maintenance that include risk assessment of software changes, initial testing that evaluates the correctness of the implemented software change(s) and regression analysis and testing.

Enhanced Documentation Level
Documents implementing the configuration management and maintenance plans should be provided in addition to the summary documentation requested for the Basic Documentation Level.

Or
Compliance to IEC 62304 Software Life cycle

Software Testing as part of Verification and Validation

Basic Documentation Level

• • A summary description of the testing activities at the unit, integration, and system levels. The summary description should include the software version tested and the overall pass/fail test results for all test protocols (i.e., collection of test procedures for specific software functionality) executed. If the device is a modified version of a previously cleared or approved device, provide a summary of the modifications compared with the previously cleared or approved version.
  • Any intentional changes made in response to failed tests and documentation of test results demonstrating that the intentional changes were implemented correctly.
  • A regression analysis and pass/fail test results to account for unintended effects of a software change.
  • System-level test protocol including expected results derived from software requirements, actual results that are observed and recorded, objective pass/fail determination, and a system-level test report. The system-level test report should demonstrate that the protocol has been acceptably executed with passing test results and that any unresolved anomalies have been acceptably deferred based on a risk assessment for the candidate release version.

Enhanced Documentation Level
In addition to the documentation requested for the Basic Documentation Level, Unit level, Integration level, and System level test protocols and reports should be provided including expected results derived from software requirements and design, actual results that are observed and recorded, and objective pass/fail determination.

Software Version History
Revision history tabulating the major changes to the software during the development cycle, including date, version number, a brief description of the changes relative to the previous version, and an indication of the version on which testing was performed.

Unresolved Software Anomalies
A list of unresolved anomalies should document the following items (e.g., in tabular format) for each unresolved anomaly present in the software:

• A description of the anomaly.
• Identification of how the anomaly was discovered and, where possible, identification of the root cause(s) of the anomaly.
• Evaluation of the impact of the anomaly on the device’s safety and effectiveness, including operator usage and human factors considerations.
• Outcome of the evaluation; and
• Risk-based rationale for not correcting or fixing the anomaly in alignment with the sponsor’s risk management plan or procedure(s).

Refer to the FDA’s guidance on software in medical devices and utilize IEC 62304, a recognized standard that outlines the medical device software lifecycle, incorporating a risk-based approach.

Assess and document how your device interacts with other electronic devices. This includes ensuring it does not cause or get affected by electromagnetic interference. Use IEC 60601-1-2 as a reference for EMC requirements and testing.

If your device has electrically powered components that are in patient contact, demonstrate their safety. Refer to IEC 60601-1 for general safety requirements, along with its amendments, to ensure compliance with safety standards.

1. EMC related Device characteristics and Intended use environments:
   Overview of devices, their functions and modes with diagrams
   Description of Power supply and wireless technology used
   Description of intentional RF emitters

Statement of Intended Use Environment

2. Risk Assessment of Medical Device

Device design & Test level determination by consensus standards
Non-implantable Medical Devices
The ANSI/AAMI/IEC 60601-1-2 Medical electrical equipment – Part 1-2: General requirements for basic safety and essential performance – Collateral Standard:  Electromagnetic disturbances – Requirements and tests is a collateral standard to the ANSI/AAMI ES 60601-1 Medical electrical equipment – Part 1: General requirements for basic safety and essential performance standard

Active implantable Medical Devices (AIMDs)
ISO 14117 Active implantable medical devices — Electromagnetic compatibility — EMC test protocols for implantable cardiac pacemakers, implantable cardioverter defibrillators, and cardiac resynchronization devices and the ISO 14708 series.

Special Environments
Additional EMC testing required referring to the specific environmental use along with ISO 60601-1-2 (Home and Professional healthcare facility environmental use).

3. Essential performance and Immunity Pass/Fail Criteria
   Essential Performance: Performance can be determined by identifying the performance of the clinical function specifying performance limits for fully functional performance versus loss or degradation of the identified performance evaluating the risk from loss, degradation, disruption, deviation, or over-delivery of the performance.

General guidance and rationale” of ANSI/AAMI ES 60601-1 and Clause 2.3.4 of AAMI CR500:2019 Basic Introduction to the IEC 60601 Series.
Immunity Pass/Fail Criteria:
Detailed with specifications related to

1. Quantitative
2. specific to the medical device and functions, and
3. observable.

These criteria should be determined based on the medical device’s functions, modes, indications for use, intended use, and Essential Performance (if applicable).

4. Medical Device Configuration and Functions Tested

1. A detailed description of the medical device under test, including the configuration, functions, modes, and settings that were tested.
2. The description of the device under test should include the medical device name, model number, manufacturer, and an indication of whether the device is the final production-ready medical device currently under review.
3. If testing not performed on Final Finished device provide scientific justification or explanation how the test results are applicable to finished final product.

5. Results of EMC Testing

1. Summary on the Information of the medical device emissions and the immunity to EM disturbances at test levels appropriate for the medical device’s intended use environments
2. Summary on the results of Emission tests with pass/fail criteria expressed with limits.
3. Summary of results of immunity tests (Should include degradation that were observed both during and after immunity test for continuous phenomena and after immunity test for transient phenomenon).

6. Modifications

Medical Device modifications to meet or pass EMC test, as a result of EMC test failure should be described with analysis.

7. Device Image

This section typically encompasses the majority of your design verification and validation testing. It should include a comprehensive account of the bench testing conducted on your device.
Include detailed protocols, results, analysis, and conclusions from these tests. Bench testing often forms a significant portion of the evidence for your device’s performance.

1. List of Testing being performed.
2. Objective of the Tests
3. Brief description of the test methods, including sample size, devices tested, and consensus standards utilized.
4. Pre-Defined Pass/Fail Criteria
5. Results Summary (Quantitative or Qualitative)
6. Data analysis Plan
7. Protocol Deviation(s) if any exists.
8. Discussion / conclusions

Not all devices require animal testing. If it’s relevant for your device, ensure you follow FDA guidance and potentially engage in a pre-submission process for feedback. Reference applicable guidance documents to understand specific animal testing requirements for your device category.

1. Overview of the purpose of the animal testing and explanation
2. list the specific animal tests conducted.
3. description each test protocol.
4. Results summary.
5. description of analysis; and
6. Conclusions.

Test Protocol

1. objective of the test.
2. test articles used in the test.
3. test methods and procedures (including any specific test conditions);
4. study endpoint, i.e., the specific parameter measured; and
5. pre-defined acceptance or pass/fail criteria.

Location of complete test report should be clearly marked in 510k submission file.

The FDA will consider alternatives to clinical studies if supported by adequate scientific rationale. If clinical testing is necessary, determine whether your study is of significant or non-significant risk, complying with the relevant FDA regulations (21 CFR Parts 50, 56, and 812).

Test Protocol

1. objective of the test.
2. test methods and procedures (including any specific test conditions);
3. study endpoints (usually both safety and effectiveness); and
4. statistical methodology used.

Test Report

1. Overview of the purpose of the clinical testing in comparison to the intended use, indications for use, environmental conditions, risk assessment.
2. List of tests to be conducted
3. Description of each test protocols
4. Summary of Results
5. Description of Analysis
6. Conclusion