The Food and Drug Administration (FDA or the Agency), the US regulating authority in the sphere of healthcare products, has published a guidance document dedicated to deciding when to submit a 510(k) for a software change to an existing device.
Table of Contents
The document is intended to assist medical device manufacturers (software developers) in determining the regulatory status of changes to software products intended for medical purposes. Due to its legal nature, the guidance does not introduce new rules or requirements itself but provides additional clarifications regarding the applicable regulatory requirements and also recommendations to be followed. Moreover, an alternative approach can be applied, provided such an approach has been approved by the authority in advance and is in compliance with the provisions of existing legislation.
In order to assist medical device manufacturers in interpreting and applying the provisions of relevant regulations, the guidance also provides some examples of software modifications and explains how they should be treated.
These examples include the following:
Proactive Software Security Patch and Access Control Measures
In order to ensure the continuous safety of a medical device in terms of cybersecurity matters, its manufacturer conducts a continuous evaluation of the new threats arising and develops necessary updates to the software used in a medical device. Once a vulnerability is identified, the software developer takes steps to eliminate it while making no impact on the performance of the medical device in general. Should changes to the software take place only to improve cybersecurity, such changes would not require a separate 510(k) submission – it would be sufficient for the manufacturer to document such changes.
The same approach applies in the case of changes introducing new access control measures or encryption. For example, this includes situations when a manufacturer makes a software modification to add encryption to the configuration file of the device and add passcode requirements for remote users, in addition to the password needed to access the device. As in the previous case, such changes do not impact the overall performance of a medical device. Thus, the change should be treated as an improvement to the cybersecurity of a medical device, and it should also be sufficient to simply document such a change.
Modifying System to Meet Specification
If there is an issue with the barcode scanning system resulting in situations when the Specimen Identification barcode could be misinterpreted by the system due to invalid characters, the manufacturer will have to make changes to the software in order to avoid misattribution of patient-related data. This could create situations when incorrect reports are generated due to the association of specimens with the wrong patients. The way the system should process barcodes with invalid characters should be prescribed in the initial specification. In such a case, the changes made by the manufacturer (developer) to ensure the software operates as prescribed in the specification would be treated as returning the system into specification of the most recently cleared device. As in the cases described above, no additional submission is needed – it would be sufficient to document the changes and follow record-keeping requirements.
Data Error
The example provided by the FDA guidance describes a situation in which software is used to collect administrative records in a file (table). In the course of its operations, the software fills in the rows one by one, but then at some point, starts adding new data to the rows that are already filled, overwriting the data contained therein. The issue is caused by a mistake in the software code. Hence, changes to the software are required to remove the issue and ensure the administrative data is collected and recorded correctly. Thus, in such a case, the software change is limited to changes to the particular module managing data recording. In particular, the functionality of the module is expanded to adding new rows in a table to avoid overwriting data in existing ones. At the same time, the change is only intended to make the software operate as initially intended and does not change its functionality in general. Consequently, a new 510(k) submission would not be needed as well.
Adding or Removing Diagnostic Parameters
The guidance further describes situations when the medical device manufacturer adds new diagnostic parameters or removes existing ones. In particular, the document provides the following sample case: An electroencephalogram (EEG) diagnostic monitor was cleared with spectral edge frequency (SEF) and peak power (PP) as quantitative parameters. The device’s intended use is to monitor brain electrical activity through electrodes placed on the surface of the head. A software modification is made to add Amplitude Integrated EEG (aEEG) as an additional quantitative parameter that was not included in the original premarket notification. In such a case, incorrect information provided by a medical device could result in wrong clinical decisions based on this information. As the changes described above would impact how the device operates (processes information), a new 510(k) submission would be required. At the same time, should the manufacturer decide to remove an existing parameter, for example – peak power, the approach to be applied should be slightly different. In this situation, the manufacturer should assess whether the change creates or necessitates a new risk control measure or a modification of an existing risk control measure for a hazardous situation that could result in significant harm. If the answer is positive, a new 510(k) submission would be required due to the changes to risk control for a medical device already placed on the market.
The authority additionally mentions that the examples described above constitute simplified situations intended to assist in understating the way the main principles should be applied. At the same time, they do not cover all possible specific aspects that could take place in reality. Hence, the FDA encourages medical device manufacturers to assess all situations on a case-by-case basis. The responses and clarifications provided by the Agency are related to the particular questions raised and should not be construed as complete and exhaustive. Thus, the responsible party shall carry out a rigorous assessment of their changes, their nature, and potential impact on the safety and performance of a medical device in question in order to determine whether the submission of a new 510(k) would be required in that particular case or not.
In summary, the present FDA guidance highlights the most important aspects related to the software changes to the medical devices already placed on the market and describes an approach to be applied in order to achieve and sustain compliance with the applicable regulatory requirements. The document also provides some examples of such changes in order to illustrate the particular way these requirements should be applied in specific situations.
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.
