Using Risk Management to Successfully Deploy Wireless Medical Devices

Ken Fuchs, senior principal architect, Enterprise Systems at Mindray (Mahwah, NJ), will speak on "Using Risk Management to Successfully Deploy Wireless Medical Devices" at the MD&M West MedTech Innovate Seminar taking place on Wednesday, February 13.

MPMN: What do you intend to cover in your presentation at the MedTech Innovate Seminar?

Fuchs: My topic is about risk management and how to apply it within a hospital setting. The presentation will try to improve awareness among both hospitals and device manufacturers that there is a shared responsibility between them when they deploy medical devices on the hospital's internal IT networks.

Historically, many medical devices were deployed on networks, but most of them were on isolated networks. Thus, in the case of patient-monitoring or infusion devices, the vendors would come in, install their own hardware, run their own cables sometimes, connect everything together, and basically have a locked-down network rather than connect the devices to anything else in the hospital.

Then at some point, people decided that they needed some data from these systems, and this was accomplished by building gateways that sat across the networks. Thus, you had a PC of some sort with two different network interface cards. Data from the medical device was collected from the closed network provided by the vendor and then shipped to clinical information systems or electronic medical records systems using the hospital's IT network.

More recently--especially with the advent of wireless--there has been greater demand to merge all of these separate networks into one network and not duplicate the infrastructure. But this effort has led to new issues facing vendors. Previously, they owned the whole network and knew what they were getting from it, but now they are sharing it with other, probably unknown systems and devices, and now there is some onus of responsibility that moves from the vendor to the hospital's IT organization.
First, the vendors and hospitals have to be aware of this situation, and second, they have to try to manage the corresponding risk, especially since we're talking about medical devices that can cause patient safety issues if they don't operate properly.

MPMN: Are these vendors medical device OEMs or suppliers of wireless connectivity solutions and software?

Fuchs: These vendors often include manufacturers of patient-monitoring equipment, infusion devices, and imaging systems. In the case of imaging equipment, considerable amounts of data are typically transferred in bulk but with moderate time sensitivity. In the case of infusion devices and patient monitoring systems, much of the data are 'real time' data, bearing in mind that 'real time' means different things to different people. In such cases, if you're pushing waveform data or parameter data across these networks and something comes along that clobbers the network for whatever reason, an unsafe condition such as a delayed alarm can arise.

MPMN: In terms of regulatory requirements and standards, what are the challenges and hurdles to expanding wireless technologies for medical device applications while rendering them safer and more secure?

Fuchs: An international standard called IEC 80001 was developed to try to address the issue of placing medical devices on the hospital IT network. It was developed by a team of vendors, healthcare providers, and regulators--including FDA. The resulting standard places much of the burden on the health-delivery organization and encourages the organization to use risk-management approaches. In contrast to such standards as IEC 60601, to which medical device vendors must conform if they're going to create a medical device, IEC 80001 is not currently a mandatory standard. In the United States, one of the reasons that it is not mandatory is that it applies not to vendors but to health-delivery organizations, which are not normally regulated by FDA. Potential adoption paths include hospital-certification groups such as the Joint Commission. In any case, the standard doesn't currently have real regulatory status, and compliance is voluntary.

Vendors that wish to comply with this standard must disclose the issues and risks associated with their systems so that the hospital can be cognizant of those risks and attempt to mitigate them. For example, the vendor is supposed to inform the hospital whether a particular system needs a minimum bandwidth of x Mbit per second per device and that the hospital must provide this bandwidth at all times. The vendor is also supposed to tell the hospital if the latency on the hospital network must be y milliseconds or if the system can't run properly in a radio-resource management environment. Radio-resource management is a scheme in the wireless world in which devices are taken off line for a 'short' period of time to determine what else is out there, such as rogue devices. Unfortunately, employing this scheme may affect the wireless performance of some medical devices.

MPMN: What standards and strategies regulate risk management related to medical devices?

Fuchs: Vendors should try to disclose all the risk issues that they can foresee. To a certain extent, they should work with the hospital in helping it understand what the issues are and try to work with it to mitigate them. Now, it's on the hospital's side to work through these issues and perform an analysis that is similar to what the vendor would normally do in its risk analysis to understand the risks and get them down to an acceptable level. Part of this effort is that the hospital needs to understand that there are risks. It needs to look at what those risks are and make a decision as to whether the risks, after they try to mitigate them, are worth the deployment of the system. In other words, does the benefit outweigh the risk?

MPMN: What, specifically, are some of the risks that might arise?

Fuchs: Alarm-annunciation systems that go to cellphones or pagers are popular today. Although most vendors probably do not suggest that hospital organizations rely solely on such systems, if a hospital nevertheless decides to do so for whatever reasons, it has to understand that there may be a risk that someone may not receive a page. Perhaps they will have to look at the technology in question and understand what the probability is that someone will not receive the page. Or perhaps they will develop an escalation scheme in the event that someone doesn't respond to the page. Will the page go to someone else? Hospitals and vendors have to look at the overall systems design to feel comfortable that a device is good enough to put on the hospital's wireless infrastructure and deploy it.

Other risk issues relate to bandwidth management. If the vendor says that a device requires a certain amount of bandwidth, the hospital can turn to its infrastructure vendor to determine whether there are mechanisms for allocating different bandwidths to different types of applications. Is there a Quality of Service or prioritization scheme in place to improve the priority of safety-critical versus noncritical data, such as data from downloading a Netflix video? After all, IEEE 802.11 wireless networks are being used for all sorts of wonderful things.

MPMN: What do you hope attendees will come away with from your presentation?

Fuchs: I'm hoping that they'll come away with an awareness of IEC 80001 and its availability. In addition, I hope that they will gain awareness of how they should work in a cooperative manner with their potential customers--healthcare-delivery organizations--and become aware of the standard, how it applies to them, and how it may apply to the hospital. They should also understand that there's a framework in place that they can refer to if the need arises. I don't expect the attendees to be experts, but they should at least know a little about the standard so that they don't look totally puzzled when someone brings it up.