The Food and Drug Administration (FDA or the Agency), the US regulating authority in the sphere of medical devices and other healthcare products, has published a guidance document dedicated to the content of premarket submissions for device software functions. The document is intended to provide additional clarifications regarding the scope of documentation to be submitted by medical device manufacturers (software developers) applying for marketing approval for the products they are responsible for. The document outlines the scope of information the authority expects to receive to be able to proceed with the review of the application. It is also important to mention that guidance documents issued by the FDA are non-binding, and an alternative approach could be applied, provided such an approach complies with the respective regulatory requirements and has been agreed with the authority in advance.
Table of Contents
Software Development and Maintenance Practices
As it was mentioned in the previous articles dedicated to the matter, the scope of documentation to be submitted by the applicant depends on the software product in question, its intended use, and also the risks associated thereto. Based on these, the appropriate Documentation Level should be applied. For instance, in case the device in question falls within the scope of the Basic Documentation Level, it would be sufficient to submit a Declaration of Conformity to the respective FDA-recognized voluntary consensus standard – a standard the medical device manufacturer may refer to demonstrate compliance with the applicable regulatory requirements. However, the authority also mentions that alternatively, a summary of the process and procedures that are in place to manage the software life cycle development, software configuration and change management, and software maintenance activities could be provided. As further explained in the guidance, such a summary should provide comprehensive information regarding the following aspects:
- Process 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 include risk assessment of software changes, initial testing that evaluates the correctness of the implemented software change(s), and regression analysis and testing. According to the guidance, the software changes covered by the scope of this point include corrective, preventive, and adaptive changes.
In the case of Enhanced Documentation Level, the applicant would have to submit either a Declaration of Conformity to the applicable standard or a comprehensive set of documents related to the configuration management and maintenance plan, together with the documents listed hereinabove.
Software Testing as part of Verification and Validation
Another important aspect covered in the guidance is software testing in the context of verification and validation. In this regard, the document also refers to the respective guidance on the General Principles of Software Validation which provides additional clarifications on software testing and specific aspects to be considered including, inter alia, unit-level testing, integration level testing, and system-level testing.
According to the guidance, software testing may sometimes involve other device performance testing activities. Thus, to ensure clarity and improve the readability of the documentation submitted, the authority encourages the applicants to provide precise references to the particular documents and reports.
As in the case with software development, the scope of information to be provided about software testing should be determined depending on the applicable Documentation Level. In particular, the guidance provides the following:
- Basic Documentation Level. In this case, the scope of documentation to be submitted should include, inter alia, the following ones:
- A summary of all the testing activities undertaken at all the levels. As further explained by the FDA, 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. In the case the software product subject to review constitutes a revised version of the product already placed on the market, it is also necessary to provide a comparison to the initial device which is approved for marketing and use in the US.
- Additional changes were implemented about the failed tests, as well as additional details demonstrating that the underlying issue has been addressed.
- Regression analysis and pass/fail test results to account for unintended effects of a software change.
- System-level test protocol includes expected results derived from software requirements, actual results that are observed and recorded, objective pass/fail determination (i.e., actual results are acceptably equivalent to expected results), and a system-level test report. The latter should confirm that the appropriate protocol has been duly followed.
- Enhanced Documentation Level. In this case, apart from the documentation described hereinabove, the applicant would also have to submit unit and integration level test protocols and reports, to demonstrate that the respective protocols have been duly followed.
Revision Level History
The authority also mentions that when deciding on the documents to be submitted, the aspects related to the specific nature of software products should be considered. For instance, the Agency expects the applicant to provide comprehensive information about the history of software revisions that have taken place in the course of the software development process. Such a document should highlight the most important changes to the product, and also indicate the respective date and version number, as well as the details on the testing performed. This list should also indicate the current version of the software that is intended to be placed on the market, together with the information regarding the changes in comparison to the previous ones, along with an assessment of the potential effect of the differences on the safety and effectiveness of the device. Should the software developer apply an iterative approach, it will be necessary to provide information regarding the respective changes to software requirements and the way they correspond to the general system requirements.
In summary, the present FDA guidance provides additional recommendations regarding the information and documentation to be provided by medical device manufacturers (software developers) to demonstrate compliance with the applicable regulatory requirements for software development and testing processes. The document clarifies the scope of information the authority expects to receive depending on the complexity of the product subject to review, its intended use and risks associated thereto, and also the way this information should be 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.
