Software in medical devices ideally provides better functionality, usability and safety. However, software is complex and prone to errors. The Federal Drug Administration (FDA) became concerned with the quality of medical devices after several high profile failures and market recalls. In 2008, they decided to use static analysis tools to evaluate the state of current software practices. Given the renewed interest in medical device security (and obviously on going concern about safety) it's important to revisit this project and make note of what's changed since then.
- Federal Drug Administration (FDA) Recommends Static Analysis for Medical Devices
- Using static analysis to evaluate software in medical devices
- The FDA Forensics Lab, New Tools and Capabilities
Why Post Market Analysis?
The Center for Devices and Radiological Health (CDRH) at the FDA is responsible for post-market analysis of medical device safety. If a device fails and results in injury or worse, the CDRH is responsible for analyzing what went wrong. A series of well publicized device failures drove the decision to find root causes for these failures and the impact of software on the events. The CDRH's Office of Science and Engineering Laboratories (OSEL) has been investigating the use of static analysis to evaluate source code provided by manufacturers. This work was also to determine how static analysis tools could be used in post-market analysis and determine how well commercial products, at the time, adhered to acceptable quality standards. The results using GrammatTech CodeSonar were significant and many issues in the provided source code were found and reported back the appropriate compliance groups.
Some of the key findings from OSEL's post-market analysis included:
- Significant errors were found that could result in device malfunction. Given the number of device failures and harm done at the time (2008), this discovery meant improvements in medical device software development were needed.
- Static analysis made post-market analysis feasible versus manual inspection. Although the inspection of such a large code base (several products were analyzed) was time consuming, the alternative, manual inspection was impractical.
- Precise identification of the error and execution trace makes debugging and fixing errors much easier.
- Static analysis allows a post-market investigator to evaluate the quality of the software, not just the development processes.
- Using static analysis in pre-market development is recommended and can easily be integrated into existing development processes. There is a strong case and recommendation from the FDA to incorporate static analysis into software development. It integrated easily with existing processes and tools and provides invaluable insight into source code.
The OSEL investigation is fairly recent (2008) but various things have changed since then. First and foremost is an increased focus on security. In fact, the FDA has just hosted the Medical Device Cybersecurity Workshop this week (January 20-21, 2016) highlighting how critical security is to medical devices. Security has huge implications on safety and privacy and thus, must be taken seriously during medical device development. As I've posted previously, static analysis plays a large part is assuring device security.
The second significant change is the adoption of IEC 62304 for software development processes, ISO 14971 for risk management and ISO 13485 for quality management (and other related standards.) In addition, the FDA and other international regulatory bodies, are requiring a much higher level of rigor in software development. As I posted previously, static analysis integrates well with the software development process requirements in ISO 62304.
The FDA used static analysis tools including GrammaTech's CodeSonar to evaluate the quality of production medical devices and found significant issues. As part of this work, they've made several observations and recommendations regarding static analysis - chief among these recommendations is using static analysis in pre-market development where it can have the most impact.