Part 1 – Medical Device Software, the FDA and the US Congress
Preface:
In any given 2-week period, an average of 15% to 20% of the applications on my smartphone have new versions to fix software bugs. Others I speak with experience similar statistics. And, that doesn’t include how often my smartphone software crashes while executing tasks it was intended to perform. We don’t complain about it. Instead, we accept this state of constant, almost continuous, software revision to fix bugs as a matter of “how things are.” We have come to terms with the fact that the normal state of software is for it to be broken, in need of repair and “acceptably” functional, while simultaneously defective.
One might think, given the prevalence and importance of software, we would reject software disrepair as normal – especially for critical applications that impact safety. But, the evidence suggests otherwise. If you perform a search on the FDA Medical Device Recall Database from January 1, 2013 to August 14, 2015, you will see 500 device recalls reported. This is the maximum number of rows the FDA report supports in a single query (meaning more than 500 devices were recalled). Enter the keyword “software” into the search, and the query returns 344 recalls due to medical device software. Reviewing randomly through these notices confirms that software issues played an instrumental – or the only – role in the recalls. And, all but nine are Class I or Class II recalls in response to a risk of temporary or serious adverse health consequences due to software problems.
Is software so difficult and challenging to write and deliver that we must accept these kinds of failure rates, even if when doing so creates a health risk? As a consumer and patient I want to strongly say, “No, we should not!” My 27 years associated with the software industry screams, “No! We must not.” Sure, all software has bugs; that is, there are always issues that cause software failure given enough time and resources. But, many software manufactures, medical device manufacturers in particular, find it too difficult to create software products that perform without error. Or, to be downright cynical, they simply reject this concept.
Numerous factors may contribute to problematic medical device software being delivered to the marketplace, including:
- pressures to get to market sooner, rather than later
- ignorance among some developers regarding what constitutes a medical device
- misunderstandings of medical device regulations
- increased dependencies on operating systems and interoperability with other systems – which are also undergoing constant change
- the sheer complexity of medical device software, which makes exhaustive testing impractical or nearly impossible
In our practice as medical device consultants and software developers, we have heard all these reasons and more. But, it puts software manufacturers in a bit of a quandary: What is the responsible thing to do when it comes to delivering software to the market? More specifically, what is the responsible thing to do when harm to users or patients is at stake?
The ethics of software or medical device manufacturing is not my intended topic here; instead, we are interested in how the FDA approaches answers to these questions. The FDA’s mission is to ensure that the medical devices that go to market are safe and effective. As a law enforcement agency, the FDA can, to be bluntly clear, coerce. In the face of known regulations that can be backed by coercion, the need to create actionable plans to address compliance presents itself with some urgency. How the FDA and other regulators seek to ensure that medical device manufacturers meet regulatory expectations and mitigate the impact of risk to device users and patients is explored below and in future installments of this series of blogs.
The topics we will cover in this series, include:
- Medical Device Software, the FDA and the US Congress
- Software Validation: What it does and does not do for risk mitigation
- The reassessment of Software Risks: MDDS, Mobile Applications, Usability and Cyber Security
- Safety Testing, IEC 60601-1 and IEC 62304
- What’s on the horizon
Part 1 – Medical Device Software, the FDA and the US Congress
With a market size of around $110 billion and an expected reach of $133 billion by 2016, the United States is the largest medical device market in the world. The US market represented an estimated 38% of the global medical device market in 2012.1 As technology advances, we are seeing more and more devices rely upon software for basic safety and essential performance. Additionally, we are seeing an increase in medical device data systems (MDDS), mobile medical applications and devices that “talk” to each other through networked systems. As software development becomes a deeper, more integral part of the medical device industry, we should expect to see even greater FDA activity in and around the topic of medical device software.
According to the FDA Annual Recall Report FY2003 to FY2012, annual recall counts increased 97% – from 604 recalls in 2003 to 1,190 recalls in 2012. Many of these recalls were attributed to software issues, especially in radiological devices. If our casual query in the FDA Medical Device Recall Database cited above is any indication, this trend is not improving.
Between 2010 and 2012, 429 devices were recalled due to software design problems. More than two thirds of the recalls were due to:
- Software design failures
- System compatibility, including interoperability between treatment planning and treatment delivery systems
- Complex or non-intuitive user interfaces that lead to human error
- Dose calculation that relies upon clinical support software2
In its June 2011 report, the Government Accountability Office (GAO) recommended that the FDA enhance its oversight of medical device recalls by creating a program to routinely and systematically assess medical device recall information and use this information to proactively identify strategies for mitigating health risks presented by defective or unsafe devices. The GAO also recommended that the FDA perform an assessment to identify trends in the numbers and types of recalls, the devices most frequently being recalled, and the underlying causes of recalls. Subsequently, in 2012, Congress directed the FDA to establish a program to “routinely and systematically assess” information regarding device recalls and to use that information “to proactively identify strategies for mitigating health risks presented by defective or unsafe devices.”3
What makes this even trickier is that Congress and the FDA can’t seem to agree about what to do regarding software. In September of 2013, the FDA proposed a final guidance indicating that on mobile medical apps software was to be considered a medical device (for the purposes of regulation).4 Simultaneously, Congress was pushing for the SOFTWARE Act5, which could make it difficult for the FDA to assure the safety and effectiveness of some devices, such as computer-aided diagnostic tools (like those that read X-rays). Two years later, Congress and the FDA have still not ironed this out.
For those devices that are clearly medical devices the FDA intends to actively regulate, manufacturers are faced with an emerging quality framework that addresses these software-related concerns, including additional design controls, 21 CFR Part 11, IEC 60601-1, PEMs, IEC 62304 and, someday, IEC 82304. The challenge will be integrating technology, especially software, in a manner that offers better, more efficient patient care, while meeting all of the accepted standards of safety. An even bigger challenge will be convincing the medical device software industry of their role in commercializing medical device software that meets the intent of this emerging safety framework.
Next Up: Software Validation – What it Does and Doesn’t do for Risk Mitigation