Posted: 30 Aug 2016 07:38 PM PDT
By Jennifer D. Newberger –
Perhaps the most interesting thing about the recently released draft guidance, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, is its mere existence. Historically, all changes to 510(k)-cleared devices were analyzed under the same guidance, regardless of whether the change related to software, labeling, materials, or anything else. That FDA has now carved out software changes indicates the importance that software has come to play in a wide variety of medical devices, and the complexities associated with software modifications.
Much of the draft software guidance mirrors a companion guidance issued the same day, Deciding When to Submit a 510(k) for a Change to an Existing Device, which addresses non-software modifications, and on which we previously blogged here. For example, the emphasis on whether a change is “intended” to significantly affect the safety or effectiveness of a device, and the use of risk management to identify potential hazards associated with the proposed modification, feature prominently in both documents.
In order to encourage the security of medical devices, the draft guidance begins by explicitly stating that if the change is done solely to strengthen cybersecurity without otherwise impacting the software or device, then no 510(k) is needed. Given the recent allegations involving pacemakers and defibrillators, this text may be reviewed more closely than it would have been just a few weeks ago.
The draft also addresses the issue of “bug fixes.” Though the draft states that such fixes are to be considered design changes under 21 C.F.R. Part 820, it also states that “[w]hen a change to the software only restores the device to the specifications of the most recently cleared device, then a new 510(k) is likely not required.”
The draft also separates out whether the software modification creates a new cause of a hazardous situation versus creates a hazardous situation itself, or alters an existing hazardous situation. It is not clear how a software modification could create a hazardous situation without creating a cause of a hazardous situation, or vice versa.
As with the companion draft guidance, this draft guidance regarding software modifications includes a number of detailed examples regarding when a new 510(k) would be needed, and should be helpful to industry in assessing software modifications. As is the case with the other draft guidance, companies should review carefully, since seemingly subtle changes could have major impacts (see our previous post here).
Perhaps the most interesting thing about the recently released draft guidance, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, is its mere existence. Historically, all changes to 510(k)-cleared devices were analyzed under the same guidance, regardless of whether the change related to software, labeling, materials, or anything else. That FDA has now carved out software changes indicates the importance that software has come to play in a wide variety of medical devices, and the complexities associated with software modifications.
Much of the draft software guidance mirrors a companion guidance issued the same day, Deciding When to Submit a 510(k) for a Change to an Existing Device, which addresses non-software modifications, and on which we previously blogged here. For example, the emphasis on whether a change is “intended” to significantly affect the safety or effectiveness of a device, and the use of risk management to identify potential hazards associated with the proposed modification, feature prominently in both documents.
In order to encourage the security of medical devices, the draft guidance begins by explicitly stating that if the change is done solely to strengthen cybersecurity without otherwise impacting the software or device, then no 510(k) is needed. Given the recent allegations involving pacemakers and defibrillators, this text may be reviewed more closely than it would have been just a few weeks ago.
The draft also addresses the issue of “bug fixes.” Though the draft states that such fixes are to be considered design changes under 21 C.F.R. Part 820, it also states that “[w]hen a change to the software only restores the device to the specifications of the most recently cleared device, then a new 510(k) is likely not required.”
The draft also separates out whether the software modification creates a new cause of a hazardous situation versus creates a hazardous situation itself, or alters an existing hazardous situation. It is not clear how a software modification could create a hazardous situation without creating a cause of a hazardous situation, or vice versa.
As with the companion draft guidance, this draft guidance regarding software modifications includes a number of detailed examples regarding when a new 510(k) would be needed, and should be helpful to industry in assessing software modifications. As is the case with the other draft guidance, companies should review carefully, since seemingly subtle changes could have major impacts (see our previous post here).
No hay comentarios:
Publicar un comentario