EQUIPMENT STANDARDS

Data lost. Alarm failed. Patient died. An alarmist viewpoint? Sure. But that telegraphic scenario has captured the attention of both FDA and a heavily computerized healthcare industry. That concern has sparked an international effort to write a standard that will mitigate the deadly risks to patients caused by the increased control that hospitals have over medical devices used in enterprise networks.

Interconnected devices such as patient monitors, infusion pumps, central stations, and alarm systems in hospitals are at the heart of a multifaceted problem, according to Tim Gee, principal, Medical Connectivity Consulting (Beaverton, OR). The use of medical devices on an enterprise network is just one threat, and the combined use of regulated devices to create systems of systems is another.

A new standard seeks to address these issues. Gee says that the standard, International Electrotechnical Commission (IEC) 80001, will “demonstrate to hospitals the risks that they are assuming and will force them to operate their networks in a safe and effective manner.”

Typically, device manufacturers anticipate neither of these threats when seeking FDA approval for their devices, Gee notes. Therefore, changes in the design and management of a hospital's network can adversely affect device performance in the first instance. The actions of third parties such as network and IT system vendors and healthcare providers using the regulated devices can alter the infrastructure in unintended and risky ways in the second instance, he says.

This state of affairs leads to three specific headaches, Gee says. One, many hospitals don't realize that “their enterprise network is now part of the medical device and, as a consequence, they have to use that medical device in a fashion that is consistent with regulatory approval.” Two, medical device manufacturers have no guidance to offer hospitals on the question. Three, hospitals are struggling to “reliably conform” with medical device specifications that have received regulatory approval.

In fact, because network specifications vary among device OEMs, Gee says differing vendor specifications can conflict, causing a hospital's support of the requirements for one medical device to make it difficult or impossible to meet the requirements of a different medical device. As a result, “hospitals have no choice but to choose one set of specifications that may be fine for one device but will mean another device will effectively be used off-label.” This situation is not inherently bad, but if it's done poorly “it can substantially increase patient risks and hospital liability,” he says.

Data Problems—and a Solution

The resulting failure of the enterprise network to adequately support the medical device system is the primary concern, Gee says. This can take the form of lost data, corrupted data, inappropriate timing of data delivery, and security breaches. That level of concern reached a peak in 2005 when FDA called a meeting to say, ‘Hey, we need to fix this problem,' the consultant says. For device manufacturers and their customers, the fact that the data in question are critical to the life of the grandmother in Room 211B is the source of testy differences as network responsibility shifts to hospitals.

The goal of IEC 80001, “Application of Risk Management for IT—Networks Incorporating Medical Devices,” is to surmount the resulting problems between device manufacturers and hospitals. At issue is the shift away from network vendors controlling how a network is designed and managed. Hospitals have now largely assumed this responsibility when they tell device manufacturers that they have to conform to the hospitals' networking specifications.

FDA recognized that it needed to weigh in on the problems. “Back in 2005 we put a lot of people in a room here at FDA” to discuss these issues, says Brian Fitzgerald, deputy division director, division of electrical and software engineering, FDA (Silver Spring, MD). Participants in the “brainstorming session” included representatives from the Healthcare Information and Management Systems Society, the European Union, and device manufacturers.

They determined that it was possible to write a benchmark that collected the disparate existing approaches addressing these risk and security concerns “in one place,” Fitzgerald says. Further impetus for that approach came in 2006 during a conference in Frankfurt hosted by IteG, a German healthcare IT organization. “The Germans had a national committee of the IEC that had actually been contemplating a standard for some considerable time,” he recalls.

The international effort involves ISO/TC 215 Working Group 7 for medical devices and Working Group 4 for security. A second committee draft of the proposed standard is circulating, and approval is expected by no later than 2010, barring major changes. Any delays that push the approval date beyond 2010 could force the whole effort back to the drawing board. According to Fitzgerald, ISO and IEC “stop further development at the end of four years. They go back to stage one. There's a clock on the standard that expires.”

It appears that the participants will beat the clock, but the development effort faces several heartburn-inducing challenges. Chief among them are the different outlooks of device manufacturers and hospital IT departments or network system vendors. Rick Hampton has had a firsthand look at the effort to reconcile the clashing sides. A clinical engineer for the past 20 years, Hampton is the wireless communications manager for Partners HealthCare (Boston), a nonprofit organization that provides primary and specialty care. He is also an IEC 80001 committee member.

As the healthcare industry inches closer “to making these devices interoperable,” Hampton says it faces a huge hurdle “in the field because that term, interoperable, can take on several different meanings. If we want devices to communicate and pass data back and forth in order to make patients as safe as possible, the biggest problem we face right now is actually connecting the transport systems.”

Playing in the Device Field

Historically, enterprise networks have been “proprietary and closed,” Hampton points out. The IT industry's “realm is to provide the transport. The only problem is they have no idea how to play in the medical device field.” He cites the use of clinical laboratory analyzers as an example of what can go wrong in an interconnected network. When the analyzers were first connected to the radiology and picture-archiving systems, the entire enterprise was “going well until the first computer virus hit,” Hampton says. The problem raised “real patient safety issues,” because “if you screw up a picture archiving and communication system, the patient may have to undergo radiology again and be exposed to more radiation than he's supposed to be exposed to.”

Antivirus tools installed by the IT departments only worsened the problem and touched “the first raw nerve,” Hampton says, because medical device manufacturers had to approve “the use or update of any computer code.” The usual IT utilitarian solution is to put a bandage on the problem in the form of a quick patch. The difference, says Hampton, is that to the IT industry “it's just data. Only in the healthcare world, that data—we hope—is a living, breathing person.”

Steve Baker, principal engineer with Welch Allyn (Beaverton, OR), has had similar experiences. “It's a huge concern that some IT vendors don't understand the ­medical ­regulatory process,” he says. As an example, he cites a situation involving monitors from multiple device manufacturers that all failed for the same reason—a proprietary algorithm on the IT vendor's equipment. Welch Allyn pointed to the same problem for 2½ years. To the company's mounting frustration, the IT supplier's upper management could not see what its more healthcare-savvy colleagues saw only too clearly.

Welch Allyn ran additional tests in mid-2008, Baker says. The IT supplier's test engineers “saw the problem and their jaws dropped. They said, ‘Wow, that's really bad.' They seem to be the only ones at the company who understand how ugly the problem is. We're still waiting for code.” Because device manufacturers “don't buy much of their gear,” Baker and others believe that some IT companies can't justify devoting resources to quickly solve such problems because sales volume is too low to merit their attention.

Baker agrees that patching security holes can introduce risks. Aware of this, one Welch Allyn customer requested validation of a specific software version. Shortly after, a security update caused the customer to request validation of the updated version. “We would have preferred to validate the next major version, but they're a big customer,” Baker says.

Baker notes that if the update only fixes the security hole, that's less risky than a patch that also adds new features. “The important question is: What is the risk to my patients if I implement this?” IT departments, however, may immediately install updates even after receiving a security risk notice. “Often, there's no planning to verify that the new code works with medical devices,” says Baker. Validation includes defining requirements, writing a test plan, and testing against it. “What that costs is time,” he says.

Ensuring Patient Safety

Hospitals should have plans in place for just such situations, Baker says, adding, “if monitoring fails due to an upgrade, how do you ensure patient safety?” One solution could require the IT department to check with the OEMs to determine whether they have validated against the new software version before it is installed.

“My job as a manufacturer is to give the hospital the network requirements for my devices to work well,” Baker says. “Then, I can go into a hospital and validate my device's operation.” Problems arise when IT departments decide to install, for example, a wireless VoIP [voice over Internet protocol] system. “Now the network I validated doesn't exist,” he says.

Chief information officers are sometimes a bane, Baker notes. “In some hospitals the actual guys with their feet on the floor, they get it. But what are the biomed and IT guys to do if the CIO buys a distributed antenna system (DAS) with no medical device pedigree and says: ‘Make it work.'”

The systems “work well in some applications, but they haven't been validated by most medical device manufacturers,” Baker says. In addition, even if the manufacturers have validated the antenna systems, each hospital has different requirements. “When you use a DAS, the idea is you can use a single antenna to cover a large area. But what if you're covering an area with 100 patients and the access point is only validated to cover 20 patients? Oops.”

A hospital with a DAS for its pager and cellular network may have been told that it supports 802.11 [Wi-Fi], “but not necessarily for life-critical patient data,” Baker points out. Echoing Hampton's comment, the Welch Allyn engineer says one major point in this discussion “tends to be forgotten. If you miss one alarm on one person, and you miss it at the wrong time, that patient may die.”

With many shared infrastructure solutions in place, Baker contends that a well-designed, validated 802.11 system can easily support IT and biomedical applications. However, for hospital IT departments that aren't able to take on the burden of carrying life-critical data, Baker proposes a solution that uses two 802.11 networks: one dedicated to IT, where all patient billing goes, and the other a dedicated biomedical network.

Alarm Notification Is Key

“The key point is alarm notification,” asserts a working group member who wants to remain anonymous. He says that the standard needs to ensure that a network delivers foolproof alarm conditions, for example, for a patient whose heart has stopped “in a room with no clinician around him.” Concerns such as the nature of the emergency and how to prevent failed alarms, network outages, weak coverage areas, and poor connectivity fall within the document's purview.

The standard “indicates that you have to work with the device manufacturer” to understand the implications of life-critical data, the role of the clinician, worst-case scenarios, and mitigation strategies, he says. In that regard, he and others on the device side see IEC 80001 as a valuable educational tool to bridge what Gee, the connectivity consultant, calls “the awareness gap.”

Acknowledging that the mind-set of IT managers has evolved to an extent, the anonymous committee member says they still lack a complete understanding of the liability at stake and thus the need for risk mitigation. “If you drop this alarm on your network, you answer potentially to FDA and a court of law because you may be getting sued by the patient,” he says.

One big question that committee members hope to answer with IEC 80001 is how to design and operate a multiuse network. The anonymous participant notes that there is no single configuration or set of network configurations well defined and understood to the point “where you could say…in this configuration, this is how the devices will operate. It's ad infinitum, especially when you add the dynamic nature of RF [radio frequency]. The question is how do you build a safe and effective network in a nondeterministic environment that includes the dynamic nature of RF or wireless?”

That's where IEC 80001 comes in, says the committee member. “It's really built around what medical device manufacturers do today within FDA constraints.” The standard takes practices that are the very air that medical device manufacturers breathe—concepts such as risk mitigation, analysis, and clinical trials—and builds a framework that can be adopted by IT staff for their networks.

Given the role that wireless LAN technology plays in the IEC 80001 discussion, the committee member says he's puzzled why IEEE or the Wi-Fi Alliance “have turned their backs” on participation. Two reasons come to mind, he says. The first reason, mentioned by Baker as well, is that the healthcare market is low volume. The second concerns liability. IEEE, he notes, is the R&D arm of the wireless companies, and the Wi-Fi Alliance is their marketing arm. Neither is too keen to put their names on a document that could be traced back to them and expose them to legal action, he believes.

A Two-Way Street

A network expert not involved in IEC 80001 development but highly knowledgeable about the issues at its core believes network providers “get the bad rap of being too rigid in their standards because they come from a world where universal standardization is a key component of interoperability.” Jim Galiardi, a network specialist with Network Systems, UW Technology, University of Washington (Seattle), acknowledges the risks involved when exceptions are added to the standards and says network vendors should not rigidly try “to force every device to work the way it needs to in their vanilla architecture.”

Nevertheless, Galiardi says the effort should be a two-way street. “Device OEMs previously had the freedom of building their stand-alone ‘island' networks to support systems using proprietary standards and protocols. They need to adapt and more readily embrace some of the IEEE standards that allow interoperability across platforms and devices,” he says.

Hospital personnel could be instrumental in forging a détente between device makers and IT system vendors, Galiardi believes. “I think the key here is the middleman at the medical center,” he says. That person could be the head of purchasing, radiology, or clinical engineering, for example. A middleman with relationships to both the medical device manufacturer and the network provider “would be the glue required to get the conversations happening. Furthermore, these conversations need to happen as part of the evaluation and purchasing process so that the network provider can point out the additional costs of providing specialized services if they should be necessary.”

Security and Protection

Not all IT network suppliers are taking their lumps. Regarded as an industry leader, Aruba Networks (Sunnyvale, CA), which provides systems for companies such as Welch Allyn and Dräger Medical, was praised by at least one device company representative. Put in the default position of defending IT providers, Michael Tennefoss, head of strategic marketing for Aruba, points out that problems such as unauthorized access to data, inappropriate exchange or transfer of data, corrupted data, and other such hazards are somewhat out of the network's control.

“We can provide the security and protective features such as a policy enforcement firewall to meet requirements such as HIPAA privacy compliance,” Tennefoss says, “but it remains possible for a hospital IT manager to disable those mechanisms. If that happens, all that tremendous technology in both the device and underlying networking infrastructure is basically undermined,” he says. He sees the proposed new standard as similar to ISO 9000 and other benchmarks, the goals of which are “to define a series or process that will lead to the ultimate objective and then validate that you actually follow those processes. It's like building a house. You don't have to use fine lumber to build a house, but you can't have a fine house without fine lumber.”

Calling Aruba Networks's products “a pipeline,” Tennefoss says, “we made it easy for IT departments to integrate security right into the system, rather than asking them to put together a hodgepodge of different devices. However, implementation still comes down to defining the policies, implementing those policies, and validating that the policies are working. That's not something we can do for customers—it's outside the scope of the network.”

Tennefoss believes that for IEC 80001 to be effective, there may need to be some sort of penalties. He suggests that these could be similar to the penalties major credit card companies instituted against merchants whose ­improper use of the networks handling credit card data “made them vulnerable to theft.”

As the second draft makes it rounds, sticking points such as implementation and the not-so-little matter of the disclosure of device manufacturers' proprietary data and proprietary rights will need to be smoothed over, Gee and others point out. IEC 80001 will call for responsibility agreements among all parties detailing what kind of information the vendor will disclose and how the customer will keep that information confidential.

A good example is in a risk analysis where bugs in the product could have meaningful influence on the outcome, Gee says. The customer will ask the vendor to disclose those bugs. “[Medical device manufacturers] aren't keen on that, but it may be a legitimate request,” he says.

“From a device manufacturer perspective, the risk analysis that some hospitals will do will be worthless. Hospitals don't have a lot of experience doing this, and they certainly don't have the experience that medical device manufacturers have in doing a formal risk management process.”

Swimming in the Same Waters

“There will be a broad range of requests for information to device manufacturers and network system suppliers,” Gee predicts. Ultimately, he says, “the fundamental challenges for medical device manufacturers are how they are going to manage that variability in requests, what they agree to provide, and what they refuse to provide.”

As far as implementing the voluntary standard, Gee says accreditation bodies or payers such as the Centers for Medicare & Medicaid Services could tie reimbursement to adoption of IEC 80001. FDA's Fitzgerald says the marketplace will take the lead. For instance, “a large hospital group might very well put into its purchasing requirements” that it prefers to do business with medical device manufacturers in compliance with 80001, and it may have “a preferred vendor partnership with those device manufacturers that comply with it. Many voluntary standards are used in that way.”

Fitzgerald is optimistic that IEC 80001 will receive a good bill of health and find acceptance by mid- to late 2010. The benchmark “could be bringing together people…swimming in the same waters but looking at each other with suspicious glares.” Involving as they do “a lot of personalities, a lot of relationship-building, and trust,” standards take time to develop, he notes.

“I have every expectation that we would recognize the standard,” Fitzgerald says, “if it meets the needs of the FDA Modernization Act of 1997, which gave us authority to recognize standards development in consensus as long as it's applicable to product premarket duties. If this standard goes through the system the way it looks like it might, I think it would be a very useful standard for our premarket review staff.”

John Conroy is a freelance writer based in Los Angeles.

Copyright ©2009 Medical Device & Diagnostic Industry