The Complex World of Patching Medical Devices

Randy Horton

Published on: January 2nd, 2025

The Complex World of Patching Medical Devices Blog Image

If I Say I’ll Fix It, You Don’t Have to Remind Me Every Six Months: The Complex World of Patching Medical Devices

Updating medical devices isn’t as simple as expected, but there are ways for manufacturers to tame unexpected and unwanted complexities.

Table of Contents show

– – – –

Do you ever see a t-shirt that perfectly sums up a situation? I recently came across one on TEMU that said, “If I say I’ll fix it, you don’t have to remind me every six months.” The first thing the t-shirt got me thinking about is my (fairly substantial) backlog of to-do projects at home. Then, while seeking to escape too much thinking about that list, it occurred to me that this would also be a great title for a panel I was organizing at AdvaMed’s Medical Device Cybersecurity Summit. This panel looked at the complexities that manufacturers need to manage when patching bugs (especially newly discovered security vulnerabilities) in medical devices.^[1]

We looked at this question closely during a lively conference session on November 13, 2024, in Washington D.C., held at AdvaMed’s offices. Before I go any further, I need to give due credit to others for many of the ideas in this article. A good deal of credit for this thinking goes to three amazing panelists: Oleg Yusim, Chief Product Security Officer at Illumina; Mike Nelson, Global VP of Digital Trust at Digicert; and Jessica Wilkerson, Senior Cyber Policy Advisor at the FDA. I’d also like to give thanks to a few conference attendees who added some great points to our session: Arnab Ray, Director of Cybersecurity (Product and Manufacturing) at Abbott’s Cardiac Rhythm Management business, and David Nathans, Chief Information Security Officer for IT/OT at Siemens Healthineers. Thanks to all of you! However, I am solely responsible for this article, including any errors or omissions.

The timing for this panel was quite good since the new FDA guidance on medical device cybersecurity went into effect in the prior year. Medical device manufacturers now need to allocate more attention to delivering cybersecurity at a consistently higher level than before. In particular, the FDA’s guidance focused attention on post-market patching to address new cybersecurity vulnerabilities/threats that emerged or came to light after a medical device was already in use in the market.

The Not-So-Simple Art of Software Patching

It seems like about once a month, Apple beams me down an update for my Macbook Pro’s operating system. Those OS updates always seamlessly install themselves in just a few minutes (though it occasionally requires me to reset a few of my laptop’s security settings). Similarly, my current and past iPhones and Android phones seemed to auto-update all the apps on my phone with only my vague awareness. So, if updating my most valued necessary electronic devices is not a big deal, what’s different about updates to medical devices?

At first glance, updating a medical device should be straightforward, right? Download the patch, install it, and move on. But as with many (most?) things in the MedTech industry, it’s anything but simple.

So why is patching medical devices complicated? The short answer is that there are several different factors, each of which addresses the complexity of the problem while also intertwining with complexities from other factors. In the next section, we’ll focus on three of the more prominent factors discussed during the panel.

Legacy Systems: An Archaeological Dig

Imagine renovating a century-old house with outdated wiring and hidden structural issues. That’s what updating legacy medical devices can feel like.

One of my fellow panelists put it perfectly: “We have devices that are expected to live in possible environments for a very long time. We’re not releasing them every two years.“

These devices often run on decades-old code, and touching one line might require re-evaluating (and re-validating) the entire system. There are likely not many people who are still familiar with this code, let alone having had a hand in writing it, or who are “fresh” in their memory of how it all ties together. Also, the older the code, the less likely there is to be testing automation already in place, which significantly increases the effort in regression testing any patches to ensure that they didn’t break existing functionality.

Ultimately, touching any code in a legacy medical device can be like pulling a thread on a sweater—you never know how much the sweater might pull out. Actually, it may be more akin to pulling a thread on a sweater in a dimly lit room!

We should note that having old legacy code is not an indictment of medical device manufacturers for writing obsolete code. In fact, it’s the opposite. Medical devices are built to last, often for years or even decades. And code naturally ages and looks more “legacy” with each year. So, if anything, the existence of so many legacy codes is a credit to the tremendous engineering quality that exists in MedTech.

Regulatory Hurdles

Then, as is always the case in MedTech, there’s the regulatory side of things. Regulations are crucial—they ensure patient safety and device effectiveness—but complicate patching. All regulatory compliance efforts require time and effort from highly skilled people to manage a massive volume of (essential) minutia.

“Recertifying products is a pain,” one panelist commented to a packed room of nodding heads. “You have to go through all the regulatory approvals, show what was exactly changed, and recertify that the product is good enough to be in the field.“

In many ways, this is no different than any other way that Regulation adds complexity to a medical device’s Total Product Life Cycle (TPLC). To paraphrase Winston Churchill, someone might joke that “regulation is the worst way to ensure patient safety and device effectiveness—except for all the others that have been tried.”

Business Constraints

The last major category for this is “let’s not forget the myriad of business and operational checkpoints (and constraints) that need to be considered.” For every update to a device, manufacturers must consider costs and internal resource allocations. They must also coordinate and communicate about these patches with their users, healthcare delivery organizations, providers, and patients.

For example, applying a patch isn’t generally just a matter of a device auto-downloading and self-installing a software update. Sometimes, it might mean physically bringing patients into the clinic to access the device. It could involve downtime for the medical device, which is not a popular activity for healthcare administrators. It could also involve a 3rd party technician physically traveling to the device.

Also, as is often the case with human nature, providers don’t “see” security flaws, so the patching activity may appear to be more of a burden than the possible risk of a future cybersecurity breach. There may also be fear, especially if there is a precedent that the patched device may stop working correctly, causing even more issues. “The clinician has to decide whether it’s worth the risk with the cybersecurity patches,” someone pointed out. The same holds for clinical engineers, IT departments, and information security professionals in health systems.

Finally, suppose the patch has any impact on user experience. In that case, there is also a need to communicate with any users or stakeholders about what will change with the patch and if there is anything they need to be aware of or do differently.

Rethinking Our Approach: From Design to Deployment

The good news is that a robust portfolio of tools and techniques can make patching less of a lift and less of a headache for everyone involved.

For example, new medical devices should be designed to make future patches far easier to do than with their predecessor medical devices. Three major categories of approaches were discussed during this panel.

Designing with Updates in Mind

New devices can be designed from day one to make it easier to update with modern architecture, tooling, and processes that enable streamlined and reliable upgrades.

For example, one of the significant advances in software tooling (across every industry) in the last 10-20 years has been the tremendous advances in automated testing tools. Automation, when done well, is a game-changer. Automating testing reduces the time and effort required to validate patches.

To be clear, this is not a magic bullet. One colleague cautioned, “I don’t have full faith and trust in <<a specific software vendor>> to allow these patches to go directly to our devices in the field. We just don’t.“

It’s a reminder that while technology offers solutions, devices still require a “trust but verify” approach that welcomes patches from vendors but still requires re-validation of the device to ensure that a change in software or configuration that enables the medical device did not inadvertently change its functioning (or cause malfunctioning).

Patches Come in many Sizes, Shapes, and Colors

A key discussion point came from Oleg Brodkin, who challenged the audience to think about patching at a more granular level. Rather than analyze all patches as equally complex, Oleg made a differentiation between five types of patches:

1. Patches to the actual software code in the medical devices
2. Patches to underlying application software that enables the medical device, such as a software update to an OTS database management system.
3. Configuration changes to underlying application software that enables the medical device.
4. Patches to the underlying Operating System that enables the medical device, such as a Microsoft Windows code update.
5. Configuration changes to the underlying Operating System that enables the medical device.

Each of these five types of patches has unique considerations and is paired with varying levels of risk. However, medical device companies may also need to deploy multiple patches in a single update, which could include a combination of one or more patches from the above five categories.

This categorization can be pretty helpful in understanding how your patches could impact a medical device.

Collaboration: The Missing Piece

Perhaps the most significant takeaway from our discussion is the value of better collaboration among all of the stakeholders in a medical device, both on the manufacturer’s side and on the side of the device’s end users and the healthcare delivery organizations they work within.^[2]

The panelists identified a great deal of opportunity for improvement in how manufacturers and healthcare providers work together to handle software patches.

Several examples were given:

“You cannot go and force them because it’s your instrument to perform an update,” a panelist noted. “You can identify the vulnerability and the risk associated with it, provide the fix quickly, and clearly communicate what the risk is.”

Trust in the patching process could be increased by some information about vulnerabilities in any given patch and the importance of patches to promote greater compliance with requests for provider systems to apply their patches.

There was some sentiment in the discussion that with better communication and customer relationship management, providers (specifically clinical engineers) could be asked to assume more direct responsibility for applying patches, reducing the need for staff from the manufacturer to work on each patch on each individual medical device of the facility.

One panelist noted that many manufacturers could improve the process for all stakeholders by being more user-centered. The panelists noted that they had observed situations where the manufacturer had an inaccurate impression of how patches were applied at provider organizations. This often hindered them from making simple changes that could have significant impacts.

The same panelists often noted that they had also observed manufacturers who made patching unnecessarily complicated for themselves by assuming (incorrectly) that they were operating under certain constraints required by the providers. In both situations, the better a manufacturer understands their customers as organizations and individuals, the easier they can affect more considerable changes.

No, Patching Does Not Have to be So Painful

Patching medical devices is a complex challenge, but it doesn’t need to be as much of a burden (or a cause for dread) as it is today.

We can make strides toward a more secure and efficient healthcare environment by rethinking our approach, adopting newer technical approaches, and embracing collaboration and communication.

Have you faced challenges with medical device updates in your organization? I’d love to hear your experiences and thoughts on how we can tackle this issue together.

– – – –

Key Takeaways

1. Legacy Systems Create Challenges: Outdated devices with decades-old code make updates complex and time-intensive, often requiring extensive re-validation.
2. Regulations Slow Deployment: While safety is crucial, regulatory approvals significantly delay the patching process.
3. Design for the Future: Building devices with modular architectures and automated testing in mind simplifies updates and minimizes risks.
4. Collaboration Drives Success: Transparent communication and shared responsibilities between manufacturers and healthcare providers improve patch adoption.
5. User Empowerment Streamlines Updates: Allowing providers to apply patches directly can reduce downtime and reliance on manufacturers.

References

1. This article focuses on updating software for in-market medical devices, such as closing off newly-discovered (or at least newly-resolved) security vulnerabilities. That said, the same thinking also applies to the shipping of software patches which are intended to provide new/enhanced functionality, as opposed to just corrections to existing functionality.
2. This panel discussion did not get into a related topic of growing importance, the patching of medical devices that are directly controlled by end-user such as devices located at the patient’s points-of-living, as opposed to points-of-care.