For clinical/biomedical engineering departments, software and firmware upgrades have long been par for the course. But two trends in recent years have had a significant impact on how clinical/biomedical engineers deal with upgrades: medical devices that are increasingly software-driven, and the degree to which medical devices have become connected to one another and to other networks. As is often the case, when medical technology evolves beyond a certain point, regulations to address those changes are inevitable. As the quest for clinical data fuels the evolution of connected medical devices, biomeds will need to brush up on their software skills.

As devices become more integrated, it is important to remember that any upgrade, no matter how small, may impact something beyond that device.

Connectivity Matters

“More and more devices are networked to other devices or information systems,” says Ken Olbrish, MSBE, enterprise imaging system administrator, Main Line Health System, Radnor, Pa, just outside Philadelphia. “Making a software change on one system may render the interface to another system inoperable. As devices become more integrated, you essentially have to think of them as an entire system rather than individual devices. Any change, no matter how small, has the potential to impact something much bigger.”

Olbrish adds that many device interfaces today are customized and built to specific software versions. “It could be a specific EMR [electronic medical record] that you’re sending to, from a specific software version of a medical device,” he says. “You need to get all the devices on the same version to work properly with the EMR. Then what happens if I update those devices later? Does the data still go to the EMR? What if I only upgrade 50% of them? Will the other half still work?”

One method that biomeds can use to head off potential problems is to create an artificial test environment to simulate how the change could impact other devices and systems. “Testing is critical,” Olbrish says. “The more testing that can be done before anything is implemented in a clinical environment, the better. If a device integrates to multiple systems, then as many of these integrations as possible should be tested. Obviously, there’s a trade-off between the time and cost of testing versus how much can be tested, but the more testing that can be done in advance the better off you’ll be in the long run.”

Olbrish does emphasize that simulation is not always easy. “Devices can be expensive,” he says. “You don’t usually have an extra one just sitting around waiting to be put in a test environment.”

Even with all of the right equipment on hand, simulation has its challenges. “It may not be easy to duplicate real world conditions,” Olbrish warns. To ensure that simulations are as accurate as possible, he recommends reaching out. “Communication becomes a lot more important here, not only the biomed talking to a device vendor, but also talking to IT to find out what impact a particular change might have on the network or another system. As part of the test planning, it’s also important to try to get clinical staff involved too, since they understand best how the device is actually used out on the floor. They can help simulate their day-to-day scenarios with the devices.”

Tracking Changes, Managing Risk

As the director of clinical engineering at Archbold Medical Center in Thomasville, Ga, and also the executive director of the Georgia Biomedical Instrumentation Society, Horace Hunter agrees that testing connectivity and regularly tracking software changes and updates are important. Hunter’s attitude reflects a pragmatic view formed during 30-plus years of biomed experience.

“We absolutely have to actually connect the device and check it out—not just put it back on the floor,” Hunter says. “For example, we have to interface vents with patient monitors and try it out on the network first. So while we may have fewer PMs, we also have to add some new functional checks. It sort of balances out that way.”

As far as recording and tracking software changes, Hunter advocates using what you have. “Most biomed departments have an asset-management system. All of the revision histories and upgrades can go there. You’ll just need to teach everyone the documentation process,” he says.

While Olbrish agrees that there are many ways to document software changes made to devices and equipment, he emphasizes that other new processes may still be needed. “Having some formalized change control processes in place also helps,” he says. “This puts in the necessary checks and balances to ensure that critical items are addressed before changes are made.”

It starts with asking lots of questions. “It can be something very simple, like, ‘If this data doesn’t get to the EMR, what’s our backup plan?’ ” Olbrish says. “You don’t need to get carried away with details, but you should have a sense of the worst that can go wrong. And if we can’t send the data, how do we work around it so clinicians can do what they need to do?”

At the heart of this type of risk management is knowing the major things that could go wrong with a given device based on a given upgrade, and the contingency plans required. “I don’t think a lot of biomeds need a lot of formal education to do this; there’s just a lot more pieces involved,” Olbrish says.

Risk management in a very basic sense is exactly what drove Scot Copeland, CBET, a clinical systems specialist at Scripps Mercy Hospital in Chula Vista, Calif, and the staff there to develop a system to track software upgrades.

“When the Conficker worm came on the scene, our CEO saw it on the news and said to compliance, ‘Hey, what are we doing about this?’ ” Copeland says. “So our compliance people asked us what we were doing about it.” Although they had implemented precautions against the virus, there was no easy way to pull the supporting documentation. Copeland says that modifications were made to the computerized maintenance management system (CMMS) program so that all software patches and updates could be documented in a special data field for a given piece of equipment.

He adds that not all devices are created equal when it comes to risk. “We’re also applying a scoring scheme to identify devices that have a special vulnerability—networked devices that touch the hospital enterprise network,” he says. “Imaging systems that talk to the Windows-based hospital network, or devices that use the wireless network to download ECG’s? You bet we’re concerned about them. But we have lots of medical devices on their own networks that don’t touch anything. They’re not connected to the Internet, no e-mail goes through them, they can’t be hacked. We’re not as concerned with those.”

Vendor Control and Approval

Whether a device is connected to the enterprise network or not, there’s one aspect to upgrading medical devices that differs from any other type of hardware: the device manufacturer. Many of today’s regulated medical devices are driven mostly by software, and biomedical engineers are forced to rely on vendors to tell them when updates are approved and available.

“We may need to get a certain device update, but then the vendor says, ‘Well, we haven’t tested this. You can’t put it on.’ How do you deal with that?” Olbrish asks.

Copeland and his team are at least trying to put some structure around the issue. “Everything has to be validated by the manufacturer and issued as a patch by them,” he says. “So we’re adapting procedures to our CMMS which will generate periodic work orders for us and document when regular software maintenance is needed.”

Copeland and his staff also do their best to get vendors to cooperate in the process. “We have tried to install virus checking software on some devices where the manufacturer has said, ‘OK, we’ll support you on installing your own software, but you’ve got to set it all up according to how we want it.’ So we’ve worked together with the vendor to install those kinds of things. We’ve worked with the manufacturers to get their OK to allow us to put these kinds of things on there.”

Because not all equipment is updated on a regular basis, and vendors are not always capable of knowing what version of software is on a given device, Copeland admits that the process is not easy. “We have to do it on a case-by-case basis, and it can be difficult,” he says.

Culture can add to the angst too. Many biomedical engineering departments are built on a spirit of independence and self-reliance that does not always mesh with an increasingly connected medical device world.

“We decided we’re going to have to rely on the vendors more than we’re accustomed to,” Copeland says. “We’re at their mercy to some extent anyway. There are vulnerabilities that are not going to be covered because the solution hasn’t been validated by the manufacturer yet. The IT guys don’t understand that sometimes, but they’re getting used to it. The device stuff is just different.”

IT + CE = ?

Different? Yes. Dependent? Definitely. The line between IT and clinical engineering is getting smaller, and can sometimes lead to entirely new places.

“At our hospital, any software that is FDA controlled belongs to biomed,” Hunter says. “Everything else goes to IT. Where that line gets blurred is the electronic medical record piece. Which part is biomed and which is IT? At one time the IT people were trying to handle it alone, but when patient records are involved and all the charting is done electronically, you’ve got to involve biomed. Now we’ve got a new department called informatics—the interfacing of all the device applications with the electronic medical records.”

While the line may be thinning, Hunter can still see it pretty clearly. “IT doesn’t really want the responsibilities that biomed has with regard to the various types of medical equipment: physical therapy, dialysis, radiology, etc,” he says. “Some people think that the two should merge and become one department. I think it would be really difficult for an IT person to understand patient care the way a biomed does. We work well together as a team, but if we were put together under one umbrella—I don’t know, we each have very different interests and priorities. It may work, it may not.”

Nevertheless, Hunter believes that IT plays a critical supporting role for the biomed department. “Anytime there are any upgrades or support that we need from IT, they’re a part of the team,” he says. “They know that. When we have major upgrades and the whole network is involved, we meet with IT, informatics, administration, and clinical to put the plan together.”

For Olbrish, too, partnering with IT and other departments is critical to successfully maintaining and upgrading device software systems. “Sharing information is the critical part. If IT is making a change to a particular part of the network, they need to get that info well in advance to biomed. Also, if biomed is making changes to equipment, IT needs to know too,” Olbrish says. He recommends using whatever communication methods work best for your situation—meetings, e-mail, or conference calls. But going beyond IT is key, according to Olbrish. “It’s not just IT and biomed,” he says. “Those two groups realize by now how closely they need to work together. But too often they don’t pull in the clinical staff until it’s too late, and something gets missed. Don’t come up with solutions without input from clinical areas. They may have ideas that biomed or IT don’t even know about.”

Industry Guidelines and Regulations

If CEOs and risk managers are not enough motivation to put an effective upgrade system in place, then IEC 80001-1 certainly is. This international standard, titled “IEC 80001-1: Application of Risk Management for IT-Networks Incorporating Medical Devices,” is a hot topic of conversation among hospital risk managers, IT, and biomedical staff (See 24×7‘s September 2011 cover story).

“IEC 80001 is one we’re going to tackle soon,” Copeland says. “We haven’t decided who’s going to be responsible for it—we haven’t got there yet—but Scripps will want something in place, at least a policy to address those issues. It’ll definitely be taken into account in the process for designing new networks.”

“At the heart of 80001 is the need to have processes in place, realizing that these devices are becoming parts of entire systems of devices,” Olbrish says. “If they aren’t already doing so, biomeds should be looking at IEC-80001 now and have discussions with their IT departments about how this will impact what they do. When the use cases arrive, they should be looking at these and use them as a basis to start introducing it to their facilities. If nothing else, biomeds should be making sure they’re educated about it, because there’s value in understanding the principles of this standard and applying them to the software management processes they’re using now.”

In addition to IEC-80001, Integrating the Healthcare Enterprise’s Patient Care Device Domain (IHE-PCD) addresses the standardization of interfaces among medical devices. While it applies more directly to device manufacturers, there are some ways that biomeds can help promote and establish this.

“While it’s not yet widely implemented in medical devices, biomeds should ask vendors for compliance with IHE-PCD and maybe even look at adding this to device contracts,” Olbrish says. “By pressuring vendors to take part in IHE-PCD as part of the purchasing process, it will help to drive vendors toward standardization in much the same way that radiology was able to push vendors to standardizing on DICOM years ago.”

Kent Lupino is a contributing writer for 24×7. For more information, contact .