More WLAN Problems
Bruce Hubbert who writes the Freakquency blog has another good post titled, “The Myth of the Self-Monitoring WLAN.” Duke University recently suffered a WLAN outage caused by an unanticipated flood of ARP (address resolution protocol) traffic. The details of the failure are used to demonstrate the need for network and WLAN monitoring that goes beyond conventional proprietary end-to-end solutions.
Hospital IT shops can be very keen on single vendor solutions – sometimes to the point of accepting significant shortcomings in parts of the vendors comprehensive offering. This tendency applies to networking in spades. Certainly you need central management, but you assume the AP and controller vendor has all the answers at your own risk – as Duke learned.
Certain vendors are taking this to extremes, offering hospitals WLAN site surveys and recommending the replacement of any technologies that don't sport their logo. Hospitals have received “advice” to replace $300,000 wireless patient monitoring systems because they weren't validated for that vendor's APs. The justification for these recommendations is that I just bought a new 30' sailboat third party systems can't be integrated into our enterprise solution. (If a vendor offers to do a free site survey of your facility, by all means take them up on it – just be sure to have someone else review the findings and offer a less biased assessment.) “And the story sounds so great, “Implement our solution and it will fix itself when it breaks and protect itself when security policies are breached.” Who wouldn't want that?“
the truth is a little more complicated. As we have seen from previous
posts, sometimes the solution doesn't behave the way your business
practices need. Similarly, sometimes there are security problems within the infrastructure itself. So what to do?
In addition, as much as big market leaders would like to believe that single vendor
solutions are the new “best of breed,” we live in a multi vendor world.
the outset nor should one blame Mr. Miller. He was correctly reading
what the controllers were telling him. But it shows how important it is
to have a separate, 3rd party solution also available to get down to
the bits and bytes or even spectrum analysis (if the problem should be
something other than 802.11 protocol madness.)
Unlike commercial office space, or an open warehouse, the WLAN environment can be extremely challenging. Putting all your eggs in one network vendor is fine when all you're doing is supporting portable users moving from room to room charting or administering drugs. But when you start adding things like wireless VoIP, indoor positioning or wireless medical devices – with truly mobile users crossing subnets – look out.
Be sure to read Bruce's post, he's got some great recommendations.
UPDATE: Here are some previous posts on WLAN issues: Cisco Stumbles in Health Care, and Cisco Wireless LAN Technical Issues – Update.
CDC Publishes Latest Emergency Department Summar for 2005
FierceHealthIT notes a new CDC study on ED overcrowding – it’s getting worse.
Emergency department visits hit a new high in 2005, with more than 115 million visits, says new research from the CDC. That’s a jump of five million visits over the previous year, and a substantial 20 percent increase over 10 years.
Over the same time period, the number of hospital EDs decreased more than 9 percent from 4,176 to 3,795, the CDC says. More than half of these patients (62.8 percent) were referred to a physician or clinic
for follow-up after their visit, suggesting their needs weren’t critical.
The 32 page report is fuel for the American College of Emergency Physicians lobbying efforts to get congress to, “create a commission to study the ED overcrowding problem. Under the terms of the ACEP-backed bill, hospitals would have to report to HHS on how many patients are boarded in the ED, and how long they’re boarded.” [Patient "boarding" is the practice of placing patients in hallways, usually in the ED, where they wait for an inpatient room to become available. Patients commonly wait for hours, and sometimes more than a day, on a stretcher parked in a hallway.]
Ambulance diversion data is tracked by hospitals, regional and state hospital associations, and sometimes the state. This data is not available to the public or most state health agencies. Given how bad ED diversion is, I’m not surprised hospitals want to keep this data private – especially the worst offenders. Data on patient boarding is tracked less often by hospitals and to my knowledge, is not tracked across hospitals by associations.
Public reporting of both diversions and boarding would provide an important customer service metric and patient safety indicator and should be available to prospective patients. It is too bad that such a requirement must be forced on the industry by government.
You can download your own copy of the CDC report here (pdf).
More Hospitals Lift Cell Phone Bans
According to a survey by CHIME, more hospitals are reducing restrictions on cell phones.
Twenty-three
percent of the 185 survey respondents reported their organization has
lifted all restrictions on mobile phone use, up 5.5% from a similar
survey conducted by the Ann Arbor, Mich.-based organization in 2004.
Only 11 respondents, or 6%, indicated that cell phone use is entirely
prohibited at their hospitals.
Sixty-nine percent of respondents reported mobile phone use is
restricted only in certain areas, such as the emergency department or
intensive care unit. And 39% indicated their organization has or will
install technology to enhance cell phone signals.
Respondents, however, also reported that some problems have arisen
as a result of increased use of mobile phones in their hospitals. For
example, some say privacy and noise pollution concerns are compelling
them to continue some mobile phone restrictions. Further, some
respondents indicated their organization has specific bans on camera
phones in patient areas.
As I noted on the Biomed Listserv this week, RF interference is a fact of life and cell phones are but one contributor. Regarding RF interference risk, cell phone's will never be proven to be perfectly safe – but then neither will hair dryers, florescent light ballasts, microwaves, and elevator motors. The key is risk management.
Sadly there's no link to the actual report on CHIME's web site. (You'd think they could have found a corporate sponsor for the study, and then published it in support of their advocacy for effective use of IT in health care and as a service to the industry – that is why CHIME exists, isn't it?)
Vocera Names Zollars New Chair and CEO
Vocera has named Robert J. Zollars as their new Chairman and CEO. Like many health care executives, Zollars got his start at American Home Products, before moving to Baxter. From the press release:
the leading operator of outsourced chronic wound care centers serving
275 hospital customers nationwide. Before joining Wound Care Solutions,
he was Chairman and CEO of Neoforma, Inc. (NASDAQ: NEOF), a leading
provider of supply chain services to more than 1,200 hospitals and 465
supplier customers. Prior to his tenure at Neoforma, Inc., he was
Executive Vice President for Cardinal Health, Inc., a $75 billion
healthcare products and services company, where he was responsible for
five wholly owned subsidiaries, including Pyxis Corporation, Medicine
Shoppe, Owen Healthcare, Cardinal International, and Cardinal’s
Information Technology business.
Vocera has successfully competed in health care against a a number of much bigger competitors. Their unique offering has gotten good adoption, but they will have to continue to innovate to maintain their market position, let alone grow. It will be interesting to see what direction Zollars takes the company.
AAMI 2007 – Final Thoughts
I was in hog heaven at this year’s AAMI meeting. Connectivity was a major theme, and during every time slot in the program there was at least one presentation dealing with connectivity. During my presentation Monday afternoon, there was one I really wanted to see that dealt with alarm notification.
Lots of discussion centered around the evolving role of biomeds and clinical engineers and the kinds of training they might need in the future. There were rumblings from some in the ACCE who wanted to hold their annual meeting at HIMSS next year rather than AAMI. There certainly is a life-critical systems role that needs to be filled, and clinical engineers could fill that role. To this observer, it seems that clinical engineers will slowly become marginalized if they do not move in the “systems” direction. Even biomed techs will need IT skills to manage and support increasingly complex and pervasive medical device systems.
During the GE sponsored breakfast, there was a session on managing RF in your hospital. Reportedly the perennial “WMTS versus ISM” debate reared its tired ugly head. For many reasons mentioned here in the past (just google “WMTS” in the search box on the left colum). The WMTS bands will never have the bandwidth or (more importantly) the management tools to support more than a small portion of the wireless medical devices in a hospital. Only the usual suspects can even afford to develop the prorpietary radios required for WMTS, which is why 802.11 has seen so much uptake with device vendors.
But the inherent limitations of WMTS do not make 802.11 a slam-dunk. In fact, recent experience has highlighted the need for more rigorous RF engineering, wireless LAN design, and ongoing RF and network monitoring to ensure a reliable network. Hospitals are perhaps the most hostile environment for wireless networking. When it comes to networks, hospitals are faced with both selecting a hardware vendor that best meets their needs and a VAR (value added reseller – the indirect reps used by IT vendors to sell their products) who really knows what they’re doing. Only the best VARs can design and install a reliable network that supports all the big apps: data, wireless VoIP, positioning, and medical devices.
In a nod to presidential politics, “It’s the workflow, stupid.” To most, connectivity is about extracting data and moving it some place else. The real objective is to automate workflow – and how connectivity is implemented has a huge impact on what workflows it supports, and ultimately the usability of the system. A fundamental piece of this workflow is patient context, the association between a patient, their medical devices, and the data that comes out of them. Patient context remains a concept that’s poorly understood by most users and vendors. Many still try to fudge patient context by associating the patient to a port number or bed location. Guess what? Patients move, and mobile devices especially, must establish patient context in the device itself to be safe and effective. I would love to see some of the fantasy-based risk analysis and mitigation documents done for certain connectivity features that I saw this week.
All of this gets to another big change reflected in this weeks conference. Stand alone embedded products are evolving into real systems that extend functionality way beyond the box itself. This “systemization” of medical devices requires some changes in thinking. No longer can you focus on building safe and effective boxes, and after the fact plugging them together with other stuff and be sure the result is still safe and effective. Nor can you manage and support interconnected devices simply by maintaining the device – the entire system must be configured and maintained as a whole.
One of the good things to come from the increased involvement of IT in device connectivity is their insistence on a test system to support the “production” system. They do this with all their software systems. An indicator that connectivity is an afterthought is the total absence of test fixtures for an integration lab. Another symptom is the scarcity of such labs in hospitals and the limited capabilities of most manufacturers’ verification labs. As systems grow and become more complex, hospitals will increasingly demand support for these labs – in the absence of test fixtures, that means customers with clout will insist on indefinite loaners so they can effectively maintain their systems.
During the ACCE Clinical Engineering Symposium Saturday morning, Bridget Moorman referred to medical device connectivity as “brittle.” I know more than one person had an epiphany upon hearing that term. Any change, no matter how small, along the chain from medical device to target computing device renders the device interface inoperable. Device firmware changes, pin-outs, cable connections, terminal server configurations, network configurations, and interface configurations – on either side of the interface – all result in failure. Planning for these interfaces (hopefully by the vendor before product development) must take this brittleness into account. At the very least, customers must be able to monitor their connectivity all the way to the device, not just a server or terminal server.
Finally we come to FDA regulatory issues. I met an FDA representative in the exhibits. She works on the Issues Management Staff, a tiger team that addresses patient safety related issues that reach a point where they must be dealt with. Can you guess one of the simmering issues that may soon become an Issue? That’s right, medical device connectivity. Much of the current regulatory framework (both vendors regulatory strategies and how the FDA manages the process) is based on standalone medical devices, and “oh, by the way, it gets plugged into all this other stuff to do… stuff.” We can expect to see regulatory perspectives shift increasingly to a systems view, especially when multiple vendors are involved.
The contortions many vendors go through to avoid FDA regulation is a symptom of this spreading systemization of medical devices. While the FDA has a responsibility to ensure safety and effectiveness, they are also responsible for accomplishing their mission in a way that doesn’t drive undeserving vendors out of business or stymie the development of innovative solutions that promise even better safety and effectiveness. Don’t expect them to accept the status quo for long. I ask everyone who’s skirting the regs if they are committed to building a quality product, and the answer is inevitably yes. All it usually takes to get a 510(k) is compliance with a basic quality system (the FDA’s Quality System regulation) and 60 days for the FDA to process your 510(k) paperwork. And yet the reticence to be regulated suggests that things like prototype code makes it into finished products all too often.
Draeger Infinity TeleSmart Demo
Here's another clip from AAMI, this one from the exhibition floor. The Draeger TeleSmart was shown at last year's AAMI. Since then, they've received their 510(k) and released the product; manufacturing is gearing up now, and the product should be shipping later this summer or fall. Jeff gave a quick product presentation/demo that would make any product manager proud.
