No one wants delays in medical device approval by the FDA. Yet, in 2013, nearly 60% of 510k submissions were given a designation of Refuse-to-Accept (RTA), indicating that the FDA would not even consider the submission in its current form. An RTA designation significantly delays the approval process. How does medical device software affect the chances of a 510(k) or PMA submission not being reviewable?
The FDA has been clear on pre-market submission requirements for software devices, issuing a guidance document in 2005. The requirements depend on the Level of Concern designation for the device in question, which the submitter is responsible to determine. The greater the Level of Concern, the more software-specific documentation is required in a 510(k) or PMA submission. With the FDA giving RTA designations to submissions for infractions as minor a mis-numbering of pages, it is clear that incomplete or inadequate software documentation will result in an RTA, which essentially restarts the clock on any obligations by the FDA.
If proper software documentation is dependent on determining an accurate Level of Concern, how can a manufacturer know the proper designation? Level of Concern is an output of the Risk Management process, which is best governed by ISO 14971. When software developers understand the importance of this standard and work in conjunction with device design engineers early in the process, the Level of Concern for the device will be known from the outset. This, in turn, ensures that the correct documentation is developed for the software along the design process, well in advance of a 510(k) or PMA submission.
When ISO 14971 is carefully applied to software device development, it dramatically decreases the likelihood that software will be the cause of an RTA designation or of other delays along the approval process. This standard cannot be seen as applying merely to the “risk team”, but must be forefront in the work of each member of the design team. With increased FDA scrutiny of software components of devices, the necessity to start with a thorough risk process as outlined in ISO 14971 is especially important for the software developer. Any other approach will almost certainly result in costly delays to device approval.