The Food and Drug Administration (FDA or the Agency), the US regulating authority in the sphere of healthcare products, has published guidance dedicated to the content of premarket submissions for the software contained in medical devices. The latest version of the document was issued in May 2005.
Table of Contents
It is important to mention that FDA guidance documents do not introduce additional rules and requirements but provide clarifications and recommendations to be considered by the medical device manufacturers and other parties involved in order to achieve and sustain compliance with the applicable regulatory requirements.
The Agency also confirms that an alternative approach could be applied, provided such an approach complies with the regulatory requirements set forth by the current legislation, and has been approved by the FDA in advance. Interested parties may also submit their comments and suggestions to the Agency when developing a new version of the document.
The present FDA guidance outlines the scope of documentation the applicants are expected to submit in the context of premarket approval of software devices. In particular, the recommendations provided in the document could be applied for stand-alone software applications and hardware-based devices containing software. The guidance summarizes all the recommendations provided in previously issued documents dedicated to the same matters.
Regulatory Background
First, the Agency emphasizes that the regulatory approach described in the guidance is intended to be the least burdensome. As mentioned, the document itself does not implement any additional requirements. All the provisions thereof are non-binding in their legal nature.
The FDA further outlines the scope of medical devices covered by the present guidance. According to the document, the regulatory approach described therein should be applied to devices that contain one or more software components, parts, or accessories, or are composed solely of software as “software devices,” including:
- Firmware and other means for software-based control of medical devices;
- Stand-alone software applications;
- Software intended for installation in general-purpose computers;
- Dedicated hardware/software medical devices;
- Accessories to medical devices when those accessories contain or are composed of software.
The recommendations provided herein could be applied to the medical devices irrespectively of the particular way the software is provided to the user.
At the same time, the scope of the present guidance does not cover software intended to perform manufacturing functions rather than being used as a device.
The regulatory approach described in the guidance could be applied for the main types of submissions, namely:
- Premarket Notification (510(k)) including Traditional, Special, and Abbreviated submissions,
- Premarket Approval Application (PMA),
- Investigational Device Exemption (IDE),
- Humanitarian Device Exemption (HDE), including amendments and supplements.
The document also contains references to the FDA-recognized voluntary consensus standards medical device manufacturers may use to demonstrate compliance with the applicable regulatory requirements. In particular, this relates to such standards as ISO 14971 and AAMI SW68.
Terminology
In order to assist medical device manufacturers and other parties involved in applying the recommendations provided therein, the FDA also provides the definitions of the most important terms and concepts used in the context of the software contained in medical devices. This includes the following:
- Verification – confirmation by examination and provision of objective evidence that specified requirements have been fulfilled. In a software development environment, software verification is confirmation that the output of a particular phase of development meets all of the input requirements for that phase.
- Validation stands for establishing by objective evidence that device specifications conform with user needs and intended use(s). Use of the term validation in this document is limited to design validation and does not include process validation as defined in 21 CFR 820.3(z)(1).
Thus, in the course of software validation, it should be assessed whether the software meets the needs of potential users and also the intended use of the medical device as determined by the manufacturer. Usually, this takes place during the last steps of the development process and includes the actions performed to ensure the software operates properly.
Apart from the verification and validation, the document provides additional details regarding the concept of minor and major injuries. In particular, it refers to the regulation 21CFR 803.3(bb)(1), which divides injuries depending on the impact caused to the patient`s health and further treatment required.
Level of Concern
Another important concept used in the context of the software contained in medical devices is the level of concern, which is an estimate of the severity of injury that a device could permit or inflict, either directly or indirectly, on a patient or operator as a result of device failures, design flaws, or simply by virtue of employing the device for its intended use. The level of concern should be taken into consideration when determining the scope of information and documentation to be provided in the course of filing a premarket submission. For this purpose, the manufacturer shall provide a detailed description of how the software subject to review could cause or mitigate hazards associated with the injuries. Thus, when submitting an application, the responsible party shall also indicate the appropriate level of concern. The authority additionally emphasizes it is not related to the general risk-based medical device classification.
According to the document, there are three main levels of concern to be applied: minor, moderate, and major, respectively. The guidance further describes the approach to be applied when determining the level of concern for a software product. The authority states that the level of concern should be determined before taking any measures to mitigate identified and potential risks. The level of concern based on the impact the software can have on the user or patient should also be indicated in a premarket submission.
In the case of the software contained in medical devices, the following levels of concern could be applied:
- Major – a failure could result in serious injury (the same applies for any failures related to the information),
- Moderate – a failure could result in minor injury,
- Minor – any failure is unlikely to cause any injury.
In order to assist medical device manufacturers in applying the approach described hereabove, the FDA further provides special criteria to be taken into consideration when determining the level of concern. These questions cover such aspects as connections to other medical devices, use in combination with medicines, potential consequences of a failure in terms of the harm that could be caused to the health of a patient or user, the importance of functions of the device, and others.
The document also highlights the most important points related to the documentation the manufacturer shall provide. The scope of documentation to be provided will depend on the appropriate level of concern determined in accordance with the abovementioned principles and criteria.
In summary, the present FDA guidance describes the basic principles of the regulatory approach for the software contained in medical devices. The document outlines the main aspects to be considered by the applicants in the context of premarket submissions.
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.
