The Food and Drug Administration (FDA or the Agency), the US regulating authority in the sphere of medical devices, has published a guidance document dedicated to the content of premarket submission for device software functions. The document is intended to provide additional clarifications about the scope of documents to be submitted by the applicant, as well as recommendations to be considered to ensure completeness of the application dossier. Due to its legal nature, the guidance is non-binding and is not intended to introduce new rules or requirements. Moreover, an alternative approach could be applied, provided such an approach complies with the respective legislation and has been agreed with the authority in advance.
Table of Contents
Software Description
First of all, an applicant should provide a detailed and accurate description of the software subject to review. Such a description should cover the most important features of the software and include various images, diagrams, and flowcharts necessary for the FDA to conduct a review. In case the submission describes modifications to software already placed on the market, it will be also necessary to indicate the appropriate reference number and outline the changes in comparison to the initial product.
The present FDA guidance provides an overview of the information to be submitted by an applicant about the software in question. At the same time, the authority acknowledges that the examples provided in the document do not cover all possible situations, so they should be taken into consideration while the actual decision should be made on a case-by-case basis.
For multiple function devices, the document refers to the appropriate guidance document issued by the FDA, where additional recommendations are provided.
According to the guidance, a software description should address, inter alia, the following aspects:
- Software specifics. In this section, an applicant shall describe the programming languages operating systems, and hardware platforms used, and also provide additional information on the release version. Should the device use Off-The-Shelf (OTS) software, it should be indicated accordingly.
- Software operation. This section should provide details about the way the software should be operated, as well as about its intended users. In case the software is intended to analyze data, the description of the methodology applied should be provided (including the reference to the appropriate evidence). Additional information would be also needed in case the software is intended to impact or replace various actions usually performed manually. In case the software utilizes Artificial Intelligence / Machine Learning technologies, a detailed description of datasets used to train the model should be provided, together with the information on measures implemented to mitigate potential bias.
- Software inputs and outputs. In this section, an applicant should describe the way the software in question receives input data, and also the way it provides output data. For both cases, the appropriate formats used should be indicated. The authority additionally emphasizes the importance of indicating to whom these outputs are provided (e.g., healthcare professionals, patients). The section should also contain a general description of the information flow, together with the details on the way the product interacts with other devices.
In case any of the details outlined here in above are provided in another document also included in the submission dossier, the appropriate reference should be provided by the applicant.
System and Software Architecture Diagram
Another important document to be submitted by the applicant in the system and software architecture diagram. According to the guidance, it should provide comprehensive information on such aspects as:
- 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; and
- How users or external products, including IT infrastructure and peripherals (e.g., wirelessly connected medical devices) interact with the system and software.
As it is stated in the document, the information provided by the applicant should be detailed enough for the FDA to complete a review of the software and components it includes, otherwise the authority would request additional information to be provided. In the case of several diagrams provided, it should be one high-level diagram covering all important aspects. To ensure the information is clear and understandable, the applicant should provide the appropriate notes and comments.
Concerning the way the diagrams should be prepared, the Agency emphasizes the following:
- Visual Considerations. It should be consistent with elements and content to ensure correct interpretation of the information the diagrams contain. Consistency is also required in terms of the level of detail. In case the diagram describes several modules, they should be duly grouped. Apart from signs and other visual elements, colors should be used to provide additional information and improve the overall readability. The scaling of the diagram should correspond to the scope of information it provides.
- Language Considerations. Consistency is required concerning the terminology used, and the respective annotations should be provided when necessary.
- References. The diagram should provide references to other documents containing details related to the information provided in the diagram.
The above mentioned points should be taken into consideration by the applicant when preparing the submission. However, the particular way they should be applied should be determined on a case-by-case basis. The guidance also provides an example of a diagram illustrating the way it should be prepared.
Risk Management File
According to the FDA guidance, the submission dossier should also include the risk management file containing the following documentation:
- Risk Management Plan complaint with the applicable standard ISO 14971. The aspects to be covered by the risk management plan include, inter alia, (i) individual risk acceptability criteria including the need for risk reduction (control), and (ii) method to evaluate the acceptability of the overall residual risk for all residual risks after all risk control measures have been implemented and verified.
- Risk Assessment. This document should describe the reasonably foreseeable software and hardware hazards related to the software in question concerning its intended use.
- Risk Management Report – a document intended to:
- Show how the risk management plan has been appropriately implemented;
- Demonstrate that the risk management file has been assessed by the appropriate personnel and the overall residual risk is acceptable;
- Demonstrate appropriate methods are established for the collection and assessment of relevant production and post-production information.
In summary, the present FDA guidance describes in detail the most important documents related to the software products, which applicants should duly submit when applying for marketing approval. The document highlights the most important aspects to be considered to ensure the completeness of the information provided.
Sources:
How Can RegDesk Help?
RegDesk is a next-generation web-based software for medical device and IVD companies. Our cutting-edge platform uses machine learning to provide regulatory intelligence, application preparation, submission, and approvals management globally. Our clients also have access to our network of over 4000 compliance experts worldwide to obtain verification on critical questions. Applications that normally take 6 months to prepare can now be prepared within 6 days using RegDesk Dash(TM). Global expansion has never been this simple.
