Medical device software is used in a wide variety of applications and is subject to a wide variety of changes. The impact of software changes on safety and effectiveness may not always be clear. This is often the case when making general code changes to software that are not necessarily intended to change function, but rather to perform what could be described as “code maintenance” or “infrastructure” modifications. These types of changes can, if not controlled properly, create unexpected changes to how the device functions. These types of changes should therefore involve a careful evaluation of their potential impact on device safety and effectiveness.

In addition to change management, these types of changes should also involve careful consideration of the overall architecture of the software. If the software architecture was developed in a planned, modular format, the likelihood of unintended impact to other areas of the code may be significantly reduced. On the other hand, if the software code was developed in a looser construct, without a clear architectural plan, the ability to clearly delineate between functional modules in the code may be reduced. The potential impact to device safety and effectiveness increases in code with looser construct, due to the inherent risk of unintended changes in code without clear boundaries in the functional modules.

The purpose of this section is to provide guidance regarding evaluation of certain types of software changes, such as “code maintenance” and “infrastructure” changes. Manufacturers are encouraged to discuss these “gray areas” with the relevant CDRH or CBER Office and Division if there are questions about whether to submit a new 510(k) for these or other types of software changes. In most cases, this will be the Division under which the device was originally cleared.

‍