Infrastructure changes are modifications made to the software support system.

• Examples: switching compilers, changing programming languages (C to C++, C++ to Java), or changing software drivers or libraries.
• The complexity of the change should be taken into consideration while determining whether the change requires submission of a new 510(k). For example, when changing programming languages, the similarity of the programming syntax between the two languages should be considered. A change from C to C++ may not entail significant code writing if the syntax is similar. On the other hand, moving from a functional or logical coding paradigm to an Object Oriented Programming paradigm, in conjunction with the change from C to C++, could involve significant software re-write, and submission of a new 510(k) is likely required.
• Similar analysis generally applies to software driver changes, OS changes, etc. It should be noted that significant changes to verification and validation scripts might be a signal that significant infrastructure changes have taken place and should be examined.

Architecture changes are modifications to the overall structure of the software.

• Examples: porting to a new OS, software changes to support a new hardware platform, and new middleware.
• These changes may impact the overall performance of the device or extend the environment in which the device can operate. The extent of the changes and the impact that they have on the device should be considered in determining whether submission of a new 510(k) is required.

Core algorithm changes are modifications made to an algorithm that directly impact or contribute to the device’s intended use.

• Examples: alarm algorithms on a monitor, a motor control algorithm for an infusion pump, and a detection module and measurement engine algorithm for an IVD.
• Changes to the core algorithm that impact performance are addressed by the preceding section and flowchart. However, it is important to understand that a complete rewrite of the algorithm, even with the same performance claims and risk profile, may be significant enough to require submission of a new 510(k) because the rewrite may impact performance indirectly.

Clarification of Requirements – No Change to Functionality are changes made to clarify software requirements after a product has received premarket clearance. This clarification may be revised phrasing of an existing requirement or creation of a new requirement altogether, without changing or adding functionality. Changes made to clarify the requirements as discussed here likely do not require submission of a new 510(k).

Cosmetic Changes – No Change to Functionality are changes made to the appearance of the device that do not impact the clinical use of the device. For example, changing the company logo that is displayed on the background of every screen could involve modifying multiple software modules; while the number of modules impacted may be large, it is unlikely that the intended change could significantly impact the device’s safety and effectiveness or intended use, and submission of a new 510(k) is likely not required.

Reengineering and refactoring are two common software maintenance techniques.

• “Reengineering” is defined as the examination and alteration of software to reconstitute it in a new form and includes the subsequent implementation of the new form. It is often undertaken to replace aging legacy software.
• “Refactoring” is a disciplined technique for restructuring a software program’s internal structure without changing its clinical performance specification. Refactoring seeks to improve a program structure and its maintainability. In general, reengineering often results in broader and more complex changes, while refactoring is often narrower in scope and less complex.
• The complexity of the change and the impact on risk controls or performance should be considered to determine whether the change requires submission of a new 510(k). Changes that are minor modifications to enhance the maintainability of the device within its specification context are unlikely to require submission of a new 510(k). Changes involving significant software re-write likely require submission of a new 510(k) because of the impact on the performance and on the risk controls.