The verification of design specifications and functional validation of software is predicated on its intended use with a particular device or as a “stand alone” device. The U.S. Food and Drug Administration (FDA) and the industry have understood and used software validation principles ever since the enactment of the Medical Device Amendments of 1976. The growing use of multiple software-based devices, in conjunction with each other, steps outside the original software validation paradigm envisioned by FDA decades ago and may not be adequate now to accommodate current software interoperability uses.
As healthcare becomes more sophisticated and technologically more complex, the use of different types of manufacturers’ software-controlled devices with each other has become routine. This practice poses new demands on making changes to software programs to correct interoperability problems related to a risk to health or making changes to improve software programs in anticipation of interoperability demands. This issue becomes more pronounced with the advancement of sophisticated software programs for clinical use and mobile applications.
As the issue of device and software interoperability becomes more pronounced, firms face the common question of how to manage unexpected problems with software interoperability. This raises the question of whether FDA will characterize such related software changes as a reportable correction or removal under 21 C.F.R. Part 806. Software modifications to mitigate or resolve a risk to health have been and likely will continue to be reportable as a correction or removal. However, what if an interoperability problem has not yet manifested itself in a firm’s software, but the firm can anticipate such a problem based on another firm’s experience? Is a preemptive modification exempt from corrections and removals as a product improvement under 21 C.F.R. § 806.1(b)(1) or is the modification reportable because a risk-to-health problem exists, even though it was identified through another firm’s experience?
FDA faced this same question when it participated in developing a consensus standard for the configuration of hospital beds to reduce a risk of serious injury or death. FDA consulted with various national healthcare organizations to develop agency guidance concerning hospital beds and how to reduce patient entrapment, a serious risk to health, which was a common problem throughout the industry. During the implementation of the guidance in 2006, FDA entertained the idea that such changes were reportable under Part 806. Eventually FDA did not require a report under Part 806 but was close to doing so. Likewise, software interoperability has become a common issue within the device industry. Whether or not FDA can or will work with the device industry to develop some guidance is an open question. The question remains whether FDA would expect a report of a correction or removal where any guidance leading to software changes is a joint effort between FDA and the stakeholders. However, the landscape is different now. The use of software increases daily; it is not static, as was the case with hospital beds. The burgeoning use of mobile applications is a prime example. This drives the risks to health to a more complicated and broader level and could drive FDA in another direction.
The FDA and industry may be well served by identifying the regulatory consequences of implementing any guidance on software interoperability issues. The uncertainty of how Part 806 would apply can be avoided by openly addressing it in the development of any guidance concerning device software interoperability.
