Spoiler alert: If you hang on long enough, this is about safety.
Not long after reading one of the recent salary survey articles saying the Baby Boomers leaving our field are not being replaced by enough millennials, I heard Joni Mitchell’s “Both Sides Now” on the radio. It was a personal favorite long before I entered the field, which places me smack dab in the center of our aging cohort. I can’t think of a time in my life when the song didn’t speak to me, even if every time I hear it the lyrics say something new. And there it was once again as I contemplated both sides of my clinical engineering career. But this time, my thoughts were informed by the data showing the field is graying. When the Boomers are gone, then what?
You read that right—both sides. From my perspective, on the one side is “before the introduction of complex information technology to the point of care,” and on the other is “after.” That transition has driven cataclysmic changes the field is still managing. But with so many of us moving on soon, it will be up to the young folks to sort out these issues. They’ll need to decide what are just ice cream castles and feather canyons, and what issues are worth some professional give and take.
I really don’t know exactly when the IT transition took place. I do remember the early hype, however. When one manufacturer marketed its newest product as a “microprocessor ventilator,” I asked the company’s local salesperson why anyone would want to ventilate a microprocessor. I have coinvented a patented processor-based scorekeeping device, so I knew the introduction of processor-based technology was significant—and that significance did not lie in the mere fact of its presence. But the professional world of clinical engineering was no longer and would never again be the same; we had crossed to another side.
In the mid 1980s, I developed a PC maintenance group within a CE department. The most difficult, if not at times insurmountable, problems we faced were getting PCs to talk with other devices using “standard” RS232 cables. At the 1988 AAMI annual meeting, one company exhibited hardware to realize something called a “Medical Information Bus” aimed at making medical devices “interoperable.” Even with my limited experience, I recognized that as an ambitious if worthwhile goal. There was no way I could have imagined that by 2016, medical device interoperability would still be a pipe dream. Perhaps the clouds got in my way.
I’ve been fortunate since that meeting to have worked not just on projects directly related to interoperability but others that have emerged indirectly from that work, particularly risk management and systems engineering. But the time I’ve spent working on these topics has kept me somewhat distanced from the details of day-to-day clinical engineering and healthcare technology management (HTM); I haven’t called myself a clinical engineer for a while because of it. As the song says, it is all too true that something is lost and gained in living every day.
But as my workload has shifted recently, I’m increasingly spending more time on what I call the “traditional” side of the field. One thing that struck me during re-entry is how much things have changed, yet stayed the same. Just yesterday I was in a project meeting with our clinical engineers. Twenty-six Januaries ago when I first came to Massachusetts General Hospital, the driving project was installing monitors and equipment in a new building. Yesterday, it was connecting monitors and equipment to networks and our electronic medical record system.
But since I faded away from the field, more has changed about project lists than the increasing focus on networks. There are far more recalls than I remember dealing with during my days on the floors. Ditto software upgrades and bug fixes, which there were none of 37 years ago. The very nature of failures and how they’re addressed has changed. That is neither a good nor a bad thing. It just is.
But from my vantage point, one thing hasn’t changed since before or after the introduction of complex IT, at least not for me. To a large degree, it’s what attracted me to interoperability in general, and the Medical Device Plug-and-Play program in particular (MD PnP), and standards work. And if HTM is to survive as a unique entity, no matter where our department resides on an organizational chart, then that one thing must remain.
That one thing is the focus on the safe application of technology at the point of care. If not CE/HTM, who? After all these years, who else gets it? Who else, with our perspective and grounded in our experience, really knows safety?
I am not suggesting that we focus on the specific safety issues of 30 to 40 years ago. No matter what CMS or any other outsiders think or believe, who on the inside does not believe that focusing increasingly scant resources on traditional PM of the majority of medical devices on the market today is an ineffective, if not irresponsible, way of making safety-related opportunity cost choices? We may know it; we may even have data to demonstrate it. But I’d argue we’ve done a poor job communicating it outside our inner sanctum. And maybe subconsciously we don’t want to, because if we did, then what would we do?
What would we do if managing technology were secondary to more appropriately applying it? How would we respond if envisioning and evolving point of care systems that are safer and more effective than those we have now was more important than managing PM for those systems? How would we spend our time if implementing systems that are by intent more resilient (that is, better able to recover from a major mishap) enabled everyone in a healthcare setting to spend less time operating from a reactive mindset? How would we sell that?
Let me take that back. How would you sell that?
Because as the salary survey demonstrated, these are among the problems for our next generation to address. I’m 4 years from outta here, Lord willing. Those of you who are only now seeing the occasional gray strand in the mirror are going to have to address this issue—or whatever you discern to be the next set of opportunities to bring engineering and technical skills to the point of care. This begs the question whether anyone sees those opportunities, no matter how difficult they may be to discern through the day-to-day, get-the-job-done clouds. Just what opportunities are being made visible to future CEs and BMETs? A famous proverb has it that “without vision, the people perish.” This principle holds for any community, including professional ones.
I’ve alluded to some very real and consequential problems for the next generation of CE/HTM professionals to take on. There are others that trouble me. Consider production pressure, the real or implied pressure personnel feel to treat production, not safety, as their primary priority. It has always been an issue in our field, but I would guess most of my older colleagues wonder, as I do, how our younger colleagues deal with the ever more frequent device upgrades and bug fixes I alluded to previously. Not only does a software change represent an increase in hands-on workload, it also requires less obvious planning and analysis, eg, identifying and addressing any impact that could result from in-use interactions with related devices.
Then there’s what other engineering fields call the “normalization of deviance,” the process by which people within an organization become so accustomed to a deviant behavior that they don’t recognize how far they have swerved from their own rules for basic safety. It was first used to describe how NASA’s culture devolved to permit the Challenger disaster and has since been applied to other domains, including healthcare.
Another concern is a fix I’ve seen reported more times than I care to count—pushing the reset button. Why is that strategy acceptable by itself? It would not have been 30 years ago, but then the failures we addressed rarely ever appeared to resolve with a button push. Still, why is it OK not to even try to understand which failure caused the need to reset? What makes anyone confident that a device or system has returned to its correct operating state, or that any inherent safety-related aspects of the associated device or system meet their specifications? There may very well be good reasons to trust pushing a reset button as a fix, but it would be good to know what they are. A former president once we should approach treaties with a “trust but verify” mindset; why should that not be the case for corrective actions taken to address problems with complex medical device systems?
These are but three of the relatively new safety issues that have emerged with the introduction of complex IT-based technology. There are more that I haven’t touched on, and almost certainly more that we haven’t encountered yet. These could serve as key challenges for the next generation of CE/HTM professionals. Or perhaps not; I’ve looked at CE/HTM from both sides now, from inside and outside, and I really don’t know CE/HTM at all. Not anymore, I don’t.
For those of you on the before side of your career, what matters should not be what we old timers see as opportunities, but what you see. What would you like to be able to say about what you did on the after side? And of course, among your hopes are continued employment, security, and adequate compensation. But those aren’t the only factors that drove your choice; something about the field interested you. Those advantages might be among the things that attract other new colleagues.
The need for safe and effective medical technology isn’t going away. If you’re reading this, you know that safety and effectiveness have as much, if not more to do, with the application of technology as its intrinsic nature. The need for engineering and technical professionals to ensure that application may change, but it will not diminish. That is the message young biomeds need to take to heart and convey.
Rick Schrenker is a systems engineering manager for Massachusetts General Hospital and senior biomedical engineer for the MGH MD PnP Program. For more information, contact chief editor Jenny Lower at firstname.lastname@example.org.