GlobeStar Systems World Connex — Day Three

After a breakfast meeting, I caught Brenda Vollmer’s presentation on Improving Safety Through Automation. Grand River Hospital recently installed ConnexALL to integrate WatchMate patient wandering, Siemens fire panels and Delta Controls building automation systems.

According to Brenda the implementation of ConnexALL was initiated to better align with their hospital’s patient and staff safety goals.  After installation they were able to consolidate much of the management and interaction of these three event driven systems into an automated and consolidated system using ConnexALL. Specific benefits included, improved reliability, managed group notification, reduction in manual interventions, automatic alarm escalation, increased mobility (no sitting at a workstation or watching a panel), quicker decision making, and a consolidated auditing capability.

WatchMate is used for wandering, patient elopement and infant abduction. The hospital’s security is based on the premise that it’s easier to contain (a potential security situation) than retrieve, and that it’s easier to catch someone in the act than is to try to find them after the fact. WatchMate provides notification to a user at a workstation. The hospital used  switchboard operators to monitor WatchMate, since they’re usually at their desks. They had to recognize the alarm, look up who to notify, and ensure that notification is made. Now, ConnexALL automatically receives alarms, notifies appropriate staff, ensures alarm delivery (including necessary automatic retry), and escalates alarm notification when necessary. (After some googling, it seems that GlobeStar integrated with WatchMate even though the product is no longer sold by the manufacturer, Xmark.)

Read More

GlobeStar Systems World Connex — Day Two

The second day of GlobeStar’s World Connex user group meeting included more informative end user experiences implementing ConnexALL.

Shawn Sicard, CEO of PiiComm in Toronto, Canada lead the customer presentations with a discussion about putting togeter complete solutions.  PiiComm is a systems integrator targeting the health care vertical market, with a long term relationship with GlobeStar. As an event sponsor, PiiComm has an exhibit demonstrating many of the products they support. Sean highlighted the Motorola CA 50 wireless VoIP phone with built-in barcode scanner. Built orignally for Home Depot, the phone has found some interest in health care. The phone has push to talk (PTT), a 1D barcode scanner in a small size (4.37″x 1.81″ x 1″ and about 4 ounces). The CA 50 is rather like a large Vocera pendant, there is no phone keypad. The phones are configured based on user profiles and voice input and text based menus on the phone to place calls. He also talked about the new Motorola EWP 1000/2000 wireless VoIP smart phones. The Moto phones were prominent in the Vocera/Motorola announcement at HIMSS, and is only one of two wireless phones that meet all the basic hospital requirements — ruggedized, water resistant and impervious to hospital disinfectants. (The other phone is the also new Ascom DECT IP phone, the d62.)

Shawn described asset management, preventive maintenance, temperature monitoring, patient and staff safety and workflow and resource management as key applications supported by AeroScout. PiiCommis also an Ascom reseller. Shawn noted that going wireless, including wireless VoIP is hard; part of his company’s mission is to help with that transition. He positioned Ascom as a DECT wireless phone solution that doesn’t require Wi-Fi.

Patient Monitor Integration

After the break Stephen Rocha with St Vincent Heart Center of Indiana presented Patient Monitoring Integration.  Stephen described the corporate culture and noted that Siemens/Draeger are the predominate medical device vendors (Hospira too). They also have Dukane for nurse call, Hill-Rom beds and Siemens (the Chantry Networks acqusition?), Meru and InnerWireless provide wireless networking. ConnexALL is used as messaging middleware.

Read More

Cisco Changing to Support Health Care

Many things have changed at Cisco since they were visited by the FDA in 2006. Awhile back Kent Gray, global lead for Healthcare Solutions at Cisco, explained to me that the FDA was responding to a brochure produced by Cisco that included a photo of a 7921 handset displaying a patient monitor alarm and associated waveform. The FDA observed that the photo represented labeling of a Class III medical device for which Cisco did not have regulatory approval. Thus began a crash course in the health care school of hard knocks for Cisco.

To Cisco’s credit they have since made many substantive changes to their traditional approach to vertical market marketing in response to the special requirements of health care. During the AAMI conference this week in San Jose, I had a chance to meet with Erik Petersen, the Global Healthcare Solutions & Technology Partnerships Manager, to talk about what Cisco’s been doing in health care.

Health care has strategic importance to Cisco. After their run in with the FDA – a rite of passage for health care vendors – Cisco’s commitment to the market was confirmed by no less than CEO John Chambers.

As a corporation that has experienced enviable growth, the company is grappling with the transition from a $40 billion company to one doing $60 billion. “Cisco wants to offer a strong proactive value proposition in health care,” said Petersen, “rather than just providing a piece of infrastructure that the customer has to deal with for an overall project.” To meet their growth objectives, the company is shifting from a horizontal market company to one focused on vertical markets and applications. To us in health care, this means responding to the unique requirements of our vertical market.

Read More

Cisco CCX and Medical Devices

When it connects to a wireless LAN, a medical device uses the Wi-Fi® radio to send data to and from network infrastructure such as access points. If the medical device’s Wi-Fi connection is unreliable, then the device’s operation will become unreliable, and users will be reluctant to use the device. In some hospitals, network-ready medical devices sit unused in closets because users could not rely on the devices to maintain consistent network connections, especially when the devices were mobile.

Wi-Fi radios adhere to a set of IEEE and industry standards that define how the radio interoperates with a wireless LAN infrastructure. Devices that bear the Wi-Fi CERTIFIED seal have passed a set of interoperability tests defined by an industry association called the Wi-Fi Alliance®. A medical device that is Wi-Fi CERTIFIED should interoperate with any wireless LAN infrastructure, but there are no guarantees that operation will be flawless or that connections will be reliable. That’s because Wi-Fi interoperability testing uses access points (APs) from only a few vendors and doesn’t include such things as roaming from one AP to another.

What Is CCX?

Read More

Cisco Stumbles in Health Care


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.

Read More