Follow Us:

Stages for 510(k) Documentation of Software Device

Phase 1 – Initial Details

Document Requirements

Scope of I3CGlobal

Scope of 510(k) Applicant

1. Intended use
  • Identification of product code

 

  • Provide an appropriate intended use of the Software device.
2. Indication s of Use Statement
(Form 3881)
  • Filling of form based on details provided by the 510(k) applicant.

 

  • Guiding the applicant if required in providing the appropriate Indications for use statement based on intended use and product code
  • Provide appropriate indications for use of the Software device in compliance to intended use.

 

  • Provide Device Name.
  • Confirm the type of Device i.e., Prescription Use or Over the Counter Use.
3. Device Description
  • Review of device description details shared by applicant.

 

  • Preparation of Device Description template as per FDA premarket submission Guidance.
  • Provide the basic details of software device which include features of software.

 

  • Summary of the functions of the device
  • Software description

 

  • Software architecture diagram.
4. Predicate Device
  • Provide the list of potential predicate devices.

 

  • Selection of predicate device by confirmation from applicant.
  • Approval of a suitable predicate device.

 

5. 510(K) Summary
  • Develop a template.

 

  • Fill the manufacturer and device details.
  • Fills the predicate device details
  • Provide details regarding the manufacturer- name, address, contact person at the company, contact number etc.
  • Provide details of medical device like indications of use, the material of construction, any claims etc.
6. Software
  • Documentation Level Evaluation.
  • Share the queries related to level of concern documentation required.
  • Confirmation of Level of Concern Documentation.

 

Phase 2 – Software Supporting Documentation based on Level of Concern

Document Requirements

Scope of I3CGlobal

Scope of 510(k) Applicant

2.1 Proposed Labelling
  • Review the User Manual shared by the applicant.
  • Create a template.
  • Provide User Manual.
  • Provide promotional Material.
2.2 Software Description
  • Provide the list of elements to be include in the device description.

 

  • Prepare the description based on device description details provided by the applicant.
  • Provide the device description details of Device Feature controlled by software, Analysis of Data and Inputs and Outputs.
2.3 System and Software Architecture
  • Provide sample deployment of software architecture.

 

  • Provide the details to be descripted for documentation.
  • Review the document provided by the applicant.

 

  • Provide the software architecture diagram with details regarding

– 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 interact with the system and software.

2.4 Software Requirement Specifications
  • Provide the details to be descripted for documentation.

 

  • Review the document provided by the applicant.
Minor Level of concern:
Summary of functional requirements from SRS.

Moderate and Major:

  • Provide the SRS documents the requirements for the software: detailing the below elements.

– inputs and outputs
– functions that the software will perform
– hardware
– programming language
– compiler version
– performance
– interfaces
– user interaction
-error definition and handling
– response times
-intended operating environment
– safety related requirements derived from a risk assessment.

2.5 Software Design Specifications
  • Provide the list of sections to be descripted for documentation.

 

  • Review the document provided by the applicant.
Minor Level of Concern:
No documentation is required.

Moderate and Major Level of Concern:

  • Provide a singular SDS document or set of SDS documents can be used.

Details to be included are:
– 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 along with the interfaces among them 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.

2.6 Software Development and Maintenance Practices
  • Provide guidance in documentation.
  • Review of documents.
Minor Level of Concern:
No documentation is required.

Major and Moderate level of Concern:

  • Provide a Declaration of Conformity to IEC 62304.

OR

Moderate level of concern:

  • Provide a summary of the life cycle development plan and a summary of configuration management and maintenance activities.

Major Level of concern:

  • All the details of moderate level of concern and Annotated list of control documents generated during development process.
2.7 Software testing as part of verification and validation  

  • Review of documents concern to software testing.
Minor Level of Concern:
System level test plan, including pass/fail criteria and results.

 

Moderate Level of concern:

  • Provide a summary description of the testing activities at the unit, integration, and system levels. System level test protocol including expected results, observed results, pass/fail determination, and system level test report.

Major Level of concern:

  • Complete details as per moderate level of concern and Test protocol, plan and results of unit and integration of software.
2.8 Risk Management File
  • Provide template of Risk management plan and risk management report covering the all the device related risks.

 

  • Review of the documents.
  • Provide a Risk management plan, risk assessment demonstrating that risks have been appropriately mitigated and risk management report.

 

  • Provide the documentation covering cyber security elements like threat modelling, hazard analysis, trace matrix, mitigation measures etc. If possible, should be provide with separate sections for clear understanding.
2.9 Revision History
  • Review of the documents.
  • Provide the 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 indication of the version on which testing was performed.
2.10 Unresolved Anomalies
  • Review of the documents.
Minor Level of Concern:

  • No Documentation is necessary.

Moderate and Major Level of Concern:

  • Provide the List of remaining software anomalies (e.g., bugs, defects) annotated with an explanation of the impact on safety or effectiveness, including operator usage and human factors, workarounds, and timeframe for correction.
2.11 Hardware Requirements
  • Review of the documents.
  • Provide all the hardware involved in the functioning of software device.
2.12 Software Compliance Documents and Certificates
  • Provide the guidance about required elements to be documented in concern to software compliance documents based on the device details provided by applicant.
  • Provide the information relates to certification concern to software device based on device details shared by the applicant.
  • Provide all the compliance documents applicable to the software device.

 

Phase 3 – Initial Documents and Substantial Equivalence Documents

Document Requirements

Scope of I3CGlobal

Scope of 510(k) Applicant

3.1 CDRH Premarket Review Submission Cover Sheet (FDA Form 3514)
  • Fill the FDA Form 3514 based on the details provided by the applicant.
 
3.2 Class III Summary and Certification
  • Not necessary if clinical studies are not required.
 
3.3 Financial Certification or Disclosure statement
  • Not necessary if clinical studies are not required.
 
3.4 Executive Summary
  • Create a template and prepare the document.
  • Justify any differences between the proposed device and predicate device.
  • Comparative study between the proposed device and predicate device chose.
 
3.5 Substantial Equivalence Discussion
  • Create a template and prepare the document.
  • Comparative study between the proposed device and predicate device chose.
 

 

Phase 4 – Administrative Documents

Document Requirements

Scope of I3CGlobal

Scope of 510(k) Applicant

4.1 510(k) Cover Letter
  • Prepare a template which includes details to list in the cover letter.
  • The document printed on company letterhead must be signed and hard copy couriered to the US office.
  • Provide a Soft copy of signed 510(k) cover letter for 510(k)documentation.
4.2 Truthful and Accuracy Statement
  • Provide a template with the required content to be mentioned and document for submission.
  • The document signed by the contact person at the firm should be provided.
4.3 Declarations of conformity and Summary report
  • Create a template listing and prepare the document.
  • The document signed by the contact person at the firm should be provided.
4.4 MDFUSC
(FDA Form 3601)
  • Create medical device user fee cover sheet and PIN.
  • Make payment to FDA. (Before submission of 510(k) file.)

 

Phase 5 – RTA Checklist and E-Copy

Document Requirements

Scope of I3CGlobal

Scope of 510(k) Applicant

5.1 RTA Checklist
  • Create an RTA Checklist Template based on type of submission.
  • Fill the checklist and ensure that mentioned documents to be submitted to the FDA.
  • Approval of Verification of RTA Checklist.
5.2 E-Copy
  • Arrangement of submission folder sections as per FDA Guidance.
  • Convert to e-copy.
  • E-copy submission to US Agent
  • Approval of Final submission Folder documentation.