Cisco has aggressively marketed their “Medical Grade Network” that promotes the value of managing clinical data (especially from or between medical devices). Many have asked Cisco just what makes a network “medical grade.” When pressed, what was described to me was a mission critical network, which is fine for patient accounting, but inadequate for life critical data. From their web page (emphasis mine, links are Cisco’s):

The Cisco Medical-Grade Network is a scalable, end-to-end solution that simplifies operations and management and supports the necessary regulatory compliance.A Cisco Medical-Grade Network connects all stakeholders in the healthcare system to a single information and communications infrastructure. The network provides a resilient and reliable network infrastructure for Clinical Connection Suite, Connected Imaging, and Connected Electronic Health Records. A Medical-Grade Network Assessment can determine whether your network is medical grade.

Given that Cisco has no products with FDA approval, “regulatory compliance” must be that required for commercial products; nothing special here (even though it sounds special).

In the recent past their well intentioned marketing has included things like wireless VoIP phones as part of medical device alarm notification systems (complete with photos of ECG waveforms displayed on phones). Unfortunately, their good intentions ended with the marketing and their conventional mission critical solution was not demonstrated to assure safety and effectiveness in health care.

Cisco was warned that they were pushing the envelope, and indeed the FDA later informed Cisco that they were marketing a medical device. Cisco was told to cease and desist, or else. Well, that got their attention. Cisco has not been bragging on their Medical Grade Network lately, although at least some of their original claims are still on their web site (here and here); probably just an oversight.

Cisco has likely spent considerable time and money on health care since their run in with the FDA. But from the outside it appears to have all been spent on lawyering rather meeting the needs of health care. An example of lawyerly writing is found in the Cisco Unified Wireless IP Phone 7920 Administration Guide for Cisco Unified CallManager Release 4.2 and 5.0 (link), in the caution on page 4, which states:

This product is not intended for use with patient monitoring devices or other patient care devices. Do not use this product as the primary communications tool in health care environments, as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment.

These two heavily laden sentences were obviously written by smart folks who have probably forgotten more about liability and the Food, Drug, and Cosmetic Act than I’ll ever know. Yet there is so much wrong with this cautionary statement. Let’s parse it bit by bit.

“This product is not intended for use…” Intended for use is code for FDA pre market approval, in which you must state the intended use of your medical device. Cisco is explicitly stating that the 7920 (and by inference, maybe the wireless LAN) is not a medical device.

“…with patient monitoring devices or other patient care devices.” Most extensions of a medical device, like remote surveillance or alarm notification, are by definition part of the medical device. This last bit of the first sentence clearly separates the 7920 from use with any medical device system, thus limiting Cisco’s liability and avoiding any nasty talk about injunctions or seizing adulterated product.

“Do not use this product as the primary communication tool in health care environments…” There is no distinction between “primary” or “secondary” anything in regards to medical device regulations. Communications here could mean voice or data, but probably refers to data. What’s left unsaid here, and could easily be implied, is that you could use the 7920 for secondary communications (if such a thing existed). The context here may be that other vendors (including Cisco partners) are selling alarm notification systems without pre market approval. The industry has created the term of art “secondary alarm notification” to provide a legal fig leaf for unregulated alarm notification systems (unfortunately, that’s most of them). (More on primary versus secondary alarm notification in a later post.)

“…as it may use an unregulated frequency band that is susceptible to interference from other devices or equipment.” This is beyond confusing, it is wrong. The FCC regulates the entire RF spectrum, including the ISM band used by the 7920; there must be some tortured logic here that is not apparent. To claim that 802.11a/b/g is unregulated is incredible. The ISM band is certainly more regulated than WMTS or MICS, two medical related bands. All wireless technologies, regardless of frequency, are susceptible to interference – yet many wireless medical devices are safe and effective, including those using the same frequencies (and similar if not identical technology) used by the 7920.

In this caution statement it is hard to separate the wireless LAN from the 7920. Would Cisco’s warning apply to another vendor’s handset on their network? Or does the warning apply to the network that supports the 7920, or any other handset?

Liability fears are a major factor in most non-health care companies lack of long term success in health care. You can't really participate in a market unless you're willing to accept and manage the inherent risks. If fact, medical device liability is very manageable. The role of attorneys (regulatory or otherwise) is to point out legal risk; it is management's job to decide how much risk to assume and how to manage it. The irony is that getting pre market approval for alarm notification on the 7920 should not be that hard. Certainly Cisco has the money to do it themselves, or the clout to induce a partner to assume the regulatory burden. The obvious choice here is for Philips to put a 510(k) on an alarm notification solution using the Clinical Connection Suite (Emergin’s Integration Suite) and Cisco’s wireless LAN.

Medical device vendors are increasingly adopting 802.11a/b/g for wireless connectivity. Numerous patient monitoring systems and “smart” infusion pumps sport WiFi radios. Device vendors and third parties are adding external radio modules so various medical devices can run on enterprise wireless networks. Cisco knows all this (and is even working with many medical device vendors), yet claims, “This product is not intended for use with patient monitoring devices or other patient care devices.” So which is it? Is Cisco’s wireless LAN unsafe for supporting the core mission of patient care using medical devices, as their statement claims? Or are all the medical device vendors who are adopting WiFi correct? Creating cognitive dissonance in your target market is not a good marketing strategy.

According to discussions with Cisco folks, part of the problem here is Cisco’s insistence in forcing the health care market into the same vertical market framework Cisco remains focused on forcing health care into their common framework where Cisco combines third party products into complete solutions that Cisco markets as specific vertical market solutions. This is what Cisco has done with their Clinical Connection Suite and other health care solutions. The FDA’s insistence on a single vendor assuming regulatory responsibility for a medical device, and then only that vendor market their regulated product does not fit with Cisco’s marketing template for vertical markets.

Post-FDA run-in, Cisco’s position is that their wireless network should not be used for medical devices. Cisco has also indicated they would not support medical device applications on their network. Can you think of a wireless application that is more central to the delivery of hospital care – and Cisco doesn’t support it? Should a hospital install a vendor’s wireless network if they refuse to support medical devices? All of this seems to fly in the face of wireless devices that have FDA pre market approval like the infusion pumps from Cardinal and Hospira, or Draeger OneNet for patient monitoring and Welch Allyn’s wireless patient monitors and PDA-based surveillance and alarm notification. These companies have demonstrated for years that 802.11 is a safe and effective data transport for critical patient data - and there are studies to back up such cliams (pdf). Such a refusal by Cisco to support medical devices is short sighted.

Another reason that Cisco may be refusing to meet basic health care market requirements is more problematic. Implied in the 7920 caution are questions about Cisco’s wireless LAN. At a recent national conference, the CIO of a large provider organization – and Cisco shop – said that Cisco’s wireless LAN software could be divided into two categories. The software used to provide basic network features is rock solid and very reliable, however he noted that the software that provides the advanced features is very buggy and extremely unreliable. This would obviously be an issue for life critical applications.

The hospital wireless market has identified 4 key applications: wireless data applications like point of care charting and meds admin, wireless VoIP, indoor positioning for asset and staff/patient tracking, and wireless medical devices. Each of these applications has its own set of WLAN design criteria and the resulting network will only support the applications for which it was designed. In fairness to Cisco, many wireless LAN problems in hospitals are the result of poor planning by hospitals or poor execution by value added resellers.

Cisco appears to be having problems with LWAPP, especially dynamic channel allocation and dynamic power control. Some indications of the problems can be found in the Cisco support forum here. You can find a detailed explanation of dynamic channel allocation problems here and here. From the introduction (emphasis mine):

In its Unified Wireless Network architecture, Cisco has developed patent pending technology for dealing with interference detection and avoidance, dynamic channel assignment, dynamic power adjustment, coverage-hole detection and correction, rogue detection and client load balancing. This system is known as RRM or Radio Resource management. The stated goal of which is to avoid problems in the fixed ISM band of 802.11b/g where only 11 channels are available to U.S. WLANs. This system, though sound in theory, has problems when applied to large WLANs in urban areas or locales that have heavily deployed WLANs such as Metro WiFi, skyscrapers, hospitals, universities and businesses near residential neighborhoods.

As a consequence of this and other rumblings of problems with LWAPP, an increasing number of hospital CIOs are doing pilots where WiFi vendors demonstrate their ability to provide reliable connectivity - usually for the 4 key wireless applications noted above. This has resulted in sales for Meru and Aruba into Cisco sites.

This post is not meant as an indictment of Cisco – everyone stumbles once in while. But somehow Cisco, you’re losing your way in health care. Stated simply, medical device data (and the concomitant regulatory burden to ensure safety and effectiveness) is a core requirement of health care. Meet that requirement, or alternatively, there’s no dishonor in ceding those applications to other vendors. If there are other issues that limit your ability to support life critical applications, be up front about it. In most cases, customers will wait for things to shape up.

We’re an incestuous bunch in health care, and we talk, a lot. The first CIO who loses their job, or the first sentinel event (a nice way to say patient death) where Cisco appears to wash their hands of the situation (and I don’t mean you should accept liability, but work with the customer to determine root causes and ensure it doesn’t happen again) you can write off health care – at least the wireless market.

If you want to walk the walk in health care, lose the regulatory attorneys and create a team to get your health care business on track. And be prepared to accept that it will take more than marketing spin to really be a player in health care – lives are at stake.

If you’re a provider reading this, caveat emptor. Vendor standardization is an important tool in fulfilling the core mission of your institution – effective and safe patient care. Wireless medical devices are a fact of life in most hospitals already, and they will only get more life critical. If you can’t ensure patient safety, then vendor standardization is less than worthless, it is a liability.

Life critical means more than mission critical. Defining the right requirements and ensuring your WLAN meets those requirements entails work and expense – but it is still cheaper than the alternative of installing a separate life critical enterprise network for medical devices, or having to replace the one you bought from the wrong vendor.

Pictured right is the new Cisco 7921 VoIP handset that would make a great nurse-carried device for alarm notification - if only someone would do the regulatory work required.

UPDATE: Check out these following posts: Cisco Wireless LAN Technical Issues - Update, and More WLAN Problems.