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 software contained in medical devices. The present article describes the most important points to be considered, including software-related documentation and additional aspects related to the specific types of submissions.
Table of Contents
It is important to mention that the FDA guidance itself does not introduce new rules or requirements, but rather provides additional clarifications regarding the applicable regulations, as well as recommendations to be taken into consideration by medical device manufacturers and other parties involved in order to achieve and sustain compliance with the applicable regulatory requirements. The Agency also states that an alternative approach could be applied, provided such an approach is compliant with the current legislation and has been approved by the authority in advance.
Software-related Documentation: Key Points
First, the document addresses aspects related to the documentation to be provided by the applicant. According to the guidance, the scope of documentation to be submitted depends on the intended purpose of the medical device in question, the level of concern associated thereto, and also the type of submission itself. The authority additionally mentions that if there are device-specific requirements available for the particular medical device, such requirements should prevail over the general requirements described herein.
As stated by the FDA, the documentation to be submitted by the applicant should:
- Describe the design of [the] device;
- Document how [the] design was implemented;
- Demonstrate how the device produced by [the] design implementation was tested;
- Show that [the applicant has] identified hazards appropriately and managed risks effectively;
- Provide traceability to link together design, implementation, testing, and risk management.
The particular types of documents to be submitted by the applicant are described further in the guidance in the form of a separate table in accordance with the applicable level of concern. These recommendations are also based on the main principles of Design Controls.
It is stated that the documents indicated in the guidance are usually created in the course of the software development. Hence, the necessity to comply with the requirement to provide such documentation will not result in an additional regulatory burden for a medical device manufacturer (software developer) provided that all the processes are duly documented. Some of the documents could be provided as statements contained in the submission itself, while others should be attached as separate documents.
According to the guidance, the manufacturer shall also indicate the level of concern for the medical device in question, determined before the effects of any mitigations. The decision to assign the particular level of concern should be duly justified, and relevant supporting documentation should be provided. The Agency expects the documentation provided to demonstrate the whole decision-making process and the reasoning behind it.
Software Description
The description of the software subject to review should cover all its features and also the environment in which the software is intended to be used. The authority encourages applicants to highlight the main points related to the functionality of the software. According to the guidance, the description of the software provided by the applicant shall include the details on the following:
- Programming language;
- Hardware platform;
- Operating system (if applicable);
- Use of Off-the-Shelf software (if applicable).
In the latter case, the appropriate guidance issued by the FDA should be considered.
Should the information outlined above be provided in another document submitted by the applicant separately, it will be necessary to provide additional reference to such a document.
Device Hazard Analysis
The regulating authority also encourages medical device manufacturers (software developers) to submit information related to a Device Hazard Analysis for any and all products. Such analysis should be based on the intended purpose of the device and hazards associated thereto. This information should be provided in the form of a table.
The information to be provided for each hazard should include:
- Identification of the hazardous event;
- The severity of the hazard;
- Cause(s) of the hazard;
- Methods of control (e.g., alarm, hardware design);
- Corrective measures taken, including an explanation of the aspects of the device design/requirements, that eliminate, reduce, or warn of a hazardous event; and
- Verification that the method of control was implemented correctly.
The Agency additionally mentions that the scope of the analysis described herein should cover any and all hazards the medical device manufacturer (software developer) could reasonably foresee. This also applies to the hazards associated with potential misuse of the product (both intentional and unintentional).
Software Requirements Specification
Another important document the regulating authority expects the applicant to provide is the Software Requirements Specification (SRS) – a document that usually describes all the requirements considered when developing the software, including those related to its functionality, interface, or design. The SRS outlines how the software product should operate.
According to the guidance, the scope of SRS could cover such requirements as:
- Hardware requirements;
- Programming language requirements;
- Interface requirements;
- Software performance and functional requirements.
Hence, the requirements should cover all important aspects related both to the hardware and the software itself. For instance, the requirements related to the performance and functionality of the software should describe how malfunctions of the software should be identified and treated. This section also addresses aspects related to the safety requirements the software should meet.
Architecture Design Chart
The Agency also expects the applicant to provide a document describing the internal structure of the software in terms of connections among its core elements. Such a document should additionally describe data flows and how the software interacts with the hardware with which it is intended to be used. At the same time, this document should not constitute an exhaustive description of all the functions and elements – the information contained should be sufficient for the FDA to assess how the software operates and achieves its intended purpose. However, in the case of the software with a higher level of concern, the information to be included in the architecture design chart should contain more details due to the higher risks associated with such a device. This element could also be a part of another document included in the submission – in such a case, the appropriate reference should be made.
Apart from the documents described above, the software-related documentation to be submitted by the applicant in the context of premarket submission for the software contained in a medical device should include such documents as:
- Software Design Specification;
- Traceability Analysis;
- Software Development Environment Description;
- Verification and Validation Documentation;
- Revision Level History; and
- Unresolved Anomalies (Bugs or Defects).
In summary, the present FDA guidance highlights the most important aspects related to the documentation of information about software subject to review. The guidance describes each document in detail and provides clarifications regarding its form and content.
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.
