Cisco Stumbles in Health Care

Cisco-7921

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.

Share
Read More

Cisco's Medical Grade Network Provides New Connectivity

CiscoSwitches

On October 11th, Cisco broadcast a live webinar to introduce their Clinical Connection Suite (press release).
Of course Cisco makes the same network boxes for health care as they do for every other vertical market, but they create a vertical market spin with alliances, marketing and distribution. Cisco has done a service to the industry by highlighting solutions to important problems in health care and growing the overall connectivity market.

The Clinical Connection Suite is made up of four components:

 

  • Nurse Call: enables real-time alerts, such as patient or caregiver locations, to engage in direct communications with their patients and mobile colleagues. No longer do clinicians have to be contacted on overhead paging systems or dedicated pagers; instead, they can now use wired or wireless devices, including Cisco IP phones, to access Nurse Call Systems such as Rauland-Borg and middleware from Emergin.
  • Patient Monitoring: provides nurses with mobile real-time alerts and patient status by delivering demographic data and key patient information via text and wave form transmission to any wired or wireless IP device. With the realities of healthcare as a
    wireless profession, caregivers cannot be tethered to nursing stations or remain in the same clinical area for any length of time. Enabled by Cisco communications capabilities connecting patient monitoring devices from leading monitoring device manufacturers, Patient Monitoring enables clinicians to deliver faster customer response.
  • Location-Based Services: improves patient care by allowing hospitals to locate and track key assets. Today, valuable time is spent by nurses and clinicians in searching for critical equipment and other hospital resources. By reducing asset tracking time, patients don’t wait unnecessarily for equipment or devices or other hospital resources. Additionally, healthcare facilities prevent equipment loss and replacement costs. Location-Based Services leverages the Cisco Medical-Grade Network and real-time location services for IEEE 802.11 (Wi-Fi) and Radio Frequency Identification Systems (RFID) tracking technology, in conjunction with the Cisco Wireless Location Appliance, asset tracking applications provider PanGo Networks, and active RFID tags from both PanGo Networks and AeroScout.
  • Collaborative Care: enables ad hoc collaboration between staff and clinicians to speed the time to diagnosis and treatment, bringing the right caregiver together with patient data in real-time using on-demand audio and videoconferencing capabilities. Using Cisco MeetingPlace and Tandberg’s visual communication technology, Collaborative Care enables hospitals and clinics to provide new services, such as real-time video-based translation capabilities for non-English speaking patients.

The critical piece of Cisco’s solution is the connectivity middleware from Emergin that integrates patient monitors (and other medical devices), nurse call systems, location-based services, and nurse carried communications devices. Without this middleware, there would be no enterprise connectivity solution to replace the proliferating point solutions that have been available for some time. It is interesting that vendors like Rauland-Borg and PanGo have differentiated themselves by integrating with Emergin.

You can see a replay of the webinar at your convenience. During the webinar, there were two questions that caught my attention. First Arthur Gasch asked about network latency and guaranteed delivery. Answer: a standard method of message acknowledgement is provided acrossvendors and products. Wrong answer; life critical data requires minimal latency to ensure that data is analyzed and alarms generated and delivered within specific (and reliable) time frames — this is the excuse medical device vendors frequently use when the say they require private networks for their devices. Later Arthur took another run at the question of maximum latency for life threatening alarms (LTAs) from monitor to phone. This time he got a more technical answer about network management.

The crux of these questions is whether wired and wireless alarm notification that is extended beyond what’s provided by the device vendor is covered by 510k and can serve as primary alarm notification. The difference between primary and secondary alarm notification was the elephant in the webinar living room (more on this here and here). After some bad experiences in the past with pagers, medical device vendors are extremely careful to differentiate between primary and secondary alarm notification (the first being regulated by the FDA and accepted for use in the treatment of patients, the second is neither regulated nor accepted in any legal or liability sense). From Cisco’s wording in their brochure, I would not be surprised if they got a visit by their friendly FDA officer. Oh, and nurse call systems are regulated by the FDA as well via 510k. But for some reason extending nurse call via secondary meansdoes not receive the same focus as medical device alarms.

Another question from Arthur during the webinar: how will this move industry to open systems and standards and drive adoption. Another great question. I think this will raise visibility for both vendors and providers on the importance of improved caregiver communications and the fact that the technology to provide a significant improvement over current approaches does indeed exist.

Someone asked one of the hospitals participating in the webinar about barriers to RFID adoption: the hospital rep (from IT) remarked that RFID is still new technology, currently in Gartner’s “trough of disillusionment”, but advancing quickly. He felt the market is still in the pilot phase, with most institutions lacking the ubiquitous wireless coverage to move RFID beyond specific areas and applications. There seems to be an innate appeal in WiFi based RFID over RFID with dedicated receivers. This seems due to the perceived cost savings of using WLAN infrastructure. It was also apparent that WiFi RFID projects count on the WiFi infrastructure investment justified via other applications. Of course active WiFi RFID tags are much more expensive than “proprietary” active tags and so must avoid infrastructure costs if they’re to show a competitive ROI.

From ExtremeNano story on Cisco’s announcement:

Within three years, RFID tags will be viewed as just another networked device, predicted Kent Grey, global lead for Healthcare Solutions at Cisco Systems. “Because the tags are just another device on the network, the ability to manage the tag comes with the ability to manage the network.”

Finally, an IDC analyst asked how important standardization and enterprise solutions vs point solutions were to the customer. Answer: very, I would guess every CIO wants to leverage network convergence and implement enterprise solutions. One hospital IT person on the webinar stated that IT wanted to get “in front” of medical device purchase by using Emergin and connecting future devices to that rather than “silo based” solutions.

Share
Read More