Software-related Device Recalls Spike: What To Do?

The numbers don’t lie. Recalls of medical devices in which the problem owes to software woes have been climbing for years. Given the pace at which this category of medical device problem is progressing, how can CTOs and CIOs cope, much less manage? Proceed proactively, say the experts, and enlist the help of your colleagues in IT.

From 1994 to 2000, excepting the anomaly of Y2K-skewed 1999, the percentage of software-related hazards and recalls in ECRI Institute’s database of device alerts never topped 4 percent. Between 2001 and 2008, it rose in an almost straight arc to approximately 15 percent.

In August 2010, FDA’s Center for Devices and Radiological Health released internal evaluations showing that, between 2005 and 2009, software played a causal role in approximately 18 percent of the recalls issued for 510(k)-approved devices. That number situates software as the third-leading cause of recalls, behind manufacturing defects (37 percent) and design flaws (23 percent), but ahead of labeling problems (12 percent).

The true number of recalls, hazards and adverse events spurred by software is higher: Unrecognized glitches leave no data to track.

“Hospitals typically have very good policies and procedures for handling alerts and recalls as they come out, but when it comes to reporting, it can be very difficult to identify a problem as software-related,” says Barbara Majchrowski, senior project engineer in ECRI’s health devices group. “Once we identify the issue, and start to troubleshoot, we need to involve the appropriate parties to mitigate it.” When it comes to reporting incidents to the FDA, she says, “we absolutely know that the problems are under-reported.”

Providers are mandated to provide such escalated reporting when a patient dies or is seriously injured, and information surrounding the event “reasonably suggests” that a device was implicated, according to FDA’s guidance document, titled “Medical Device Reporting for User Facilities.”

Learning curve  

“We are dealing more and more with software and IT issues, and that’s a change in our profession,” says Caroline Campbell, who serves St. Vincent Health in Indianapolis as imaging service manager, an in-sourced position contracted to Indianapolis-based TriMedX Healthcare Equipment Services. “Many hospitals still have separate clinical engineering and IT groups, but they’re forced to work more closely together and have more cross-training between the two just because the technology is evolving. [Software-related hazards and recalls] is an area where the two professions really have to keep pace with each other.”

To hold up their end of the deal, clinical engineers need education and training to develop new skill sets, says Campbell—and she puts her money where her soapbox is. She’s working toward a degree in IT at the same school where she teaches engineering, Indiana University-Purdue University Indianapolis.

Campbell, who holds a master’s degree in engineering, began her healthcare career with a nine-year run in nursing. This gave her plenty of firsthand experience with the user’s point of view on device hazards and recalls. Asked to name a device that seems especially prone to IT problems, she bypasses the high-profile suspects—infusion pumps and defibrillators—to offer a surprising answer: ultrasound scanners. “Part of it is that they’ve grown in volume and part of it is that they’re moved around the hospital, connected to and disconnected from the network, started up and shut down,” she says. “They get worked pretty hard.”

Campbell appreciates device vendors who offer sensible suggestions for “workarounds” while they’re developing a software upgrade or patch to fix a problem. “I was reviewing recalls to prepare for a meeting recently and saw that, on a particular radiographic system, if you’re taking manual exposures and you accidentally hit the ‘Technique’ and ‘Expose’ buttons at the same time, your output may not be what you expect,” she says. “The workaround was to be aware of how the problem can be created, and to avoid that situation and recognize its effect.”

Campbell’s colleague James Jernigan, a TriMedX national director, says it is a mistake to think of the increase in software-related recalls as a purely negative development. For one thing, some devices are engineered to fail-safe under certain circumstances. Such incidents may call forth recalls even when patients were not harmed but, on the contrary, protected from harm.

“I would look at the big picture, including asking ‘Has this route increased patient safety?’” says Jernigan.

A safe trial-and-error process, he suggests, can yield “more non-damaging software issues on which you have to work with the manufacturer. You have to get the latest and greatest version, because it is being updated and improved. Perhaps that’s a direction we want to go.”

Problem of propriety

At Arkansas Children’s Hospital in Little Rock, Kevin Haralson, director of clinical engineering, finds that networking problems account for upwards of 90 percent of all problems. He knows to spot these by the “really bizarre and very random” behaviors they cause in devices. The usual troubles, he says, stem from the gremlins of group policy, sharing and security. These networking failure modes are distinct from failures pointing to software inside devices, of course, but the two modes can be difficult to distinguish, so he needs to consider both when preparing to check with device manufacturers.

“There are plenty of software-related issues that are truly software-related, because everyone is in a hurry to compete with the other guy, and they sometimes get stuff out sooner than they should,” says Haralson. “When it turns out that it is a software issue, and not a configuration issue but a true flaw, we talk to the manufacturer.
About half the time they’re already aware of it because other people are having similar issues, he says. “The other half they’ll say it’s a first. Either way, in the end, they’ll send us a patch or revision to upload that will cure the problem.”

Haralson describes a recent situation that illustrates how much trickier medical device service has gotten since embedded software began its march toward ubiquity.  
“We have to fight tooth and nail to get service manuals for the capital purchases, such as in radiology and lab. The manufacturers say the software is proprietary,” he says. “I was told that, on a big analyzer for blood bank, the FDA wouldn’t force the manufacturer to give us service manuals.” Rankled, he set up a meeting with FDA code-enforcement officials and, sure enough, they told him there was nothing they could do. “They said, ‘We don’t regulate that. We don’t say that manufacturers must give out service manuals. It’s a business decision on their part, not a regulatory issue at all.’”

This is one of the reasons the Institute of Medicine (IOM) has called for abolishing the FDA’s 510(k) approval process. A device is not “substantially equivalent” to its previous iterations, the organization reasoned, if it has undergone multiple software upgrades. The group is advocating full clinical testing of all upgraded versions to ensure safety and effectiveness, recommending that FDA come up with policies and procedures for, among other things, specifically testing software.

The discussion raised by IOM’s much-publicized protestations attracted widespread attention in the mainstream media, which reminded the American public that more than 700 patients had died due to code problems in infusion pumps and that, between 2005 and 2009, adverse event reports for external defibrillators jumped 80 percent.

Teamwork counts

Haralson tells how large recalls play out on the department level floor. One Friday night, he received notification from MedSun, FDA’s medical product safety network, that 750 infusion pumps at Arkansas Children’s needed to be fitted with clinical precaution devices as soon as possible. “It was a nightmare,” he says. “It uncovered a lot of gaps in the system for immediate-action types of needs.”

Haralson helped pull together a response team that included several senior nursing staff, including the vice president. They huddled, came up with a plan for deploying the clinical precautions and then got to the hard part: communicating the plan to clinicians throughout the 316-bed hospital. Next came documenting their response, for which they used an ECRI database—“the manufacturers always have plenty of paperwork,” says Haralson—and, finally, drawing from the experience to set up guidelines and parameters for future reference.

“Typically, recalls are not a major drain on my time, but that one drained my whole department’s time for weeks,” says Haralson, who manages 11 staff members. Normal recall-related activities take about an hour per week of each technician’s time, he says. “We spend around 30 minutes per person per week to look at new alerts from ECRI and probably another 30 minutes on paper alerts from the manufacturer.”

“These are interesting times,” says Majchrowski. “Very challenging but very exciting—there is a lot of potential with interoperability, for example. We are gaining advantages, but we need to keep in mind that we need to plan these systems well, we need to have good strategies in place, we need to have good policies and procedures so that, if something does go wrong, we know what to do.”

The numbers don’t lie. Something software-related surely will go wrong. The hope is that event reporting and recall responses will keep pace, pushing device design and engineering ever closer to perfect performance for patients.