This Is My Confession

By Rick Schrenker
I have a confession to make: I had a hidden agenda in an article I wrote for 24×7 over 10 years ago. And I’ve never written about it until now. The column was titled “Failures and Consequences,” which is available here. Everything in it was true, but I didn’t share the backstory, which relates to this:

The phenomenon of networked devices freezing up was noted by others as well. A couple of respondents described “network storms,” where clock-related communications traffic overload caused bedside monitors to essentially stop monitoring. One [person] reported his hospital was considering going on divert before the immediate problem was resolved.

Both reported definitively addressing the source problem with the manufacturer. However, the actions that led up to the failure (setting time incorrectly on central stations) were arguably ones that the manufacturer could have anticipated in a risk-management process like that of ISO 14971, Risk Management for Medical Devices, which calls for consideration not only of “intended use” but also “reasonably foreseeable misuse.”

At the time, I solicited stories of failures from 24×7 readers and was able to get enough feedback to write what I still consider one of my better columns. But what I will admit to now is that I was fishing for something. And I’ll bet some of you can guess what that was. In short, I wanted to see if we were truly the only customer reporting the problem to the manufacturer, which the manufacturer in question claimed. To me, it just didn’t seem like a one-off kind of problem. Turns out I was right.

I don’t know about you, but I heard that line many times when I worked at the pointy end of the stick. One time, in particular, occurred roughly 30 years ago, just weeks after I left my previous hospital to work at Massachusetts General Hospital (MGH). In my first department meeting with some manufacturer salespeople, one of us brought up a problem we were experiencing at MGH and were fed the “it’s only you” line. I then mentioned how odd that was, considering we had reported the same problem just weeks earlier while I was still at my previous employer.

I was reminded of this a few weeks ago when a colleague brought up his concerns about a certain vendor. I had dealt with the same vendor a few years ago to address some problems and recalled my discerning two mechanical design flaws with one of their products.

Neither manifested in problems that created direct hazards—but both led to relatively frequent failures, which required removing the devices from service and potentially interrupting the timely provision of care. And to me, that does represent an indirect hazard—in addition to the frustration of paying for replacement parts that failed due to design flaws.

The vendor insisted that no one else had experienced the number of failures that we reported. But lo and behold, when the vendor announced a replacement product a few months later, design changes not only addressed both problems but were highlighted as features in the marketing material they provided.

Returning to my network storm discussion with the manufacturer, one of my requests was to look at the product’s risk management file (RMF). After all, companies are required to maintain RMFs in order to obtain 510k clearance in the U.S. and receive the CE Mark in Europe. The final exchange in the ensuing argument was, “We will never show anyone our file!”—to which I replied, “Someday you will!” A decade later, I still haven’t heard or seen any reports of a manufacturer divulging the contents of one of these files. I guess I lost that battle. Does that matter to you?

Shifting gears just slightly, I often hear colleagues and clinicians say that the FDA “approves” medical devices. Setting aside the indefensible notion that just because a device is on the market means that it performs the application that you require it for, I would argue that the FDA may not serve the purpose you think it does. What the FDA does, by statute, is clear devices to be marketed. That has a specific meaning, which I’ll elaborate on in a future column.

For now, it’s enough to know that the FDA’s Quality System Regulations establish the hoops that manufacturers must traverse to obtain that clearance. (I, personally, learned about them while drafting a quality manual in response to the now-defunct requirement that hospitals that create Medical Device Data Systems have a quality system in place.) Among those hoops is formal risk management, and the FDA points to ISO 14971 as its expectation, with 14971 requiring the development and maintenance of a risk management file. Which, unless things have changed, you can’t see.

That wouldn’t have bothered me so much 30 or so years ago, before the integration of medical devices on networks. But the network storm problem happened 10 years ago, and I couldn’t get information about the risks it presented from the manufacturer of the system in which the issue occurred. A few years later, I served on the standards committee that developed IEC 80001-1. And I will tell you that the top hurdle we faced was getting manufacturers to even entertain the concept of working with other manufacturers on shared risk management.

Why? Well, if they wouldn’t let us see their RMFs, do you think they’d share them with each other? One approach that has since been advocated—including by me!—is defining standard interfaces so that conformance with the standard would make sharing RMFs unnecessary.

While I remain hopeful this approach will succeed, even when I was active in this effort I maintained a healthy skepticism, considering the whack-a-mole strategies we are forced to employ to address endlessly evolving cybersecurity threats (not to mention the unintended—and overlooked—faults buried in all complex software). I would like my skepticism proved to be unwarranted—but then again, some is always necessary.

So for my next few CE Reflections columns, I’ll speak a bit to an alphabet soup of acronyms. In addition to explaining a little bit more about QSRs and RMFs, I’ll touch on CAPA, V&V, MDRs, and a few pertinent others. In the meantime, if you want to know more about device clearance, click here.

Rick Schrenker is a systems engineering manager for Massachusetts General Hospital. Questions and comments can be directed to chief editor Keri Forsythe-Stephens at [email protected].