Qualcomm released a new 3G chip that supports both EV-DO (Verizon and Sprint) and HSDPA (AT&T and T-Mobile). This will result in radio cards that will run on either technology and provide the greatest choice in selecting carriers.

The chips are apparently targeting laptops and should appear in new laptops by the second quarter of 2008.

The latest technology to join the 3G alliance is WiMax, which the Qualcomm chip (called Gobi) does not support. In the US, Sprint is the first carrier to announce plans to deploy a nation-wide WiMax wireless network.

Pictured right is Qualcomm's QSC6240 chip with integrated radio
transceiver, baseband modem and multimedia processor - together with
power management functionality into a single chip for WCDMA (UMTS)
and HSDPA handsets.

A recent survey of ED docs indicates that they believe that ED overcrowding is getting worse. From the Modern Healthcare story:

In a survey of nearly 1,500 practicing emergency physicians, more than 80% said crowded conditions in their emergency departments had increased either slightly (40.2%) or significantly (42.4%) in the past year, according to a recent poll from the American College of Emergency
Physicians. In the study, conducted from Aug. 28 to Sept. 19, nearly 67% of respondents cited “not enough staffing and/or resources” as their leading concern about patient care.Other top concerns included decreased throughput in the emergency department because of boarding patients (65.4%) and long wait times (65.3%). Also, 40.4% of physicians said their emergency-care environment has overcrowding and that access to specialty physicians and similar practice issues is a concern, but not yet a crisis.

Of those who responded, 703, or about 47%, said they had experienced a patient suffering as a result of crowded emergency rooms, while 200 said they had experienced a patient death for this reason at some point.

First off, while quantitative percentages are quoted extensively, this is really just a survey on the opinions of emergency room physicians. As noted a couple days ago, actual operational data is much harder to come by. Certainly the emotional assessment of front line physicians on ER overcrowding has value, but it is certainly not scientific.

Caveats out of the way, it is likely that ED overcrowding is indeed getting worse. Certainly there’s no doubt emergency room volumes are increasing. The major cause of this overcrowding, “not enough staffing and/or resources,” is frustratingly vague - but then the survey is based on opinion rather than operational data. Are they talking about staffing and resources in the ED, outside the ED in downstream areas, or both?

The survey hints rather strongly at both the causes and potential solutions to reduce overcrowding. Overcrowding due to boarding patients in the emergency department was noted as the second major cause. Boarding patients - parking them on gurneys in hallways while they await a “soon to be available” inpatient bed - results from down stream patient flow bottlenecks. Building a bigger ED won’t help with that problem.

Another story, noted by FierceHealthcare, describes a 2006 study showing that increasing ICU beds reduces ambulance diversion and increases hospital revenue. The study, done at Oregon Health and Science University Hospital and published in the Annals of Emergency Medicine (abstract), includes some interesting data.

• Based on 10,301 adult ED patients in 2002 and 2003, the average hospital revenues per patient were $4,492
• Each hour spent on diversion cost the hospital $1,086 in lost revenue
• An increase of staffed ICU beds from 47 to 67 beds reduced time on diversion by 63%
• The hospital gained $175,000 in additional monthly revenues through reduced time on diversion

Since critical care and telemetry represent the most common patient flow bottlenecks that result in ED overcrowding and diverts, the outcome of this study is expected. You too can calculate the cost per hour of revenue lost due to emergency room diversions - to provide one more reason why those units that won’t take your patients should buck up and start carrying their weight.

Solving your ambulance diversion problem by adding ICU beds is perhaps not the best approach (but it is by far the most expensive). OHSU is sort of ICU-crazy, with a 1:2 ratio of “special care” beds to med/surg beds (155 critical care beds to 311 med/surg beds). This compares with another Portland metro hospital, Providence St Vincent. At virtually the same number of beds (466 for OSHU, 450 for St V’s) St Vincent as 7 critical care beds for every 54 med/surg bed (94 critical care beds to 356 med/surg beds).

Implementing variable acuity units at your hospital can go a great way to eliminating critical care patient flow bottlenecks. The capital cost to implement variable acuity units (or universal beds) is much lower than building more ICU beds. The rub is the management effort to retool the impacted nursing units and getting buy-in (and compliance) from your medical staff. But then, nothing is easy.

As an aside, using the American Hospital Directory (found in the Resources tab under Important Web Links), I created a spreadsheet that compares beds, LOS, total patient days, gross patient revenue, etc. While there are many differences between the hospitals, like LOS, it is interesting to note that St Vincent’s revenue is 4 times the gross patient revenue at OHSU.

UPDATE: I tried to find an email address for the principal investigator, John McConnell, for the study I quote above, but was unsuccessful. If you know John, I’d love to chat with him about his study (not to mention all those ICU beds). Thanks!

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?“

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.

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.

According to a survey by CHIME, more hospitals are reducing restrictions on cell phones.

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 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.

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.

Lantronix has scored their biggest medical device deal to date, “a custom, battery-operated version of its commercially-available WiBox® 802.11 b/g wireless device server for the manufacturer’s medical point-of-care application.” (press release)

The WiBox takes a serial output and converts it to a wireless network connection. Johnson & Johnson's OneTouch was the first point of care glucometer with wireless capabilities, using a terminal server and 802.11 radio from Lantronix. This is a good product strategy for legacy devices - if you're doing some sustaining engineering or refreshing an existing device, adding an external radio module is your only choice for wireless connectivity.

The problem with this approach for a new product is that it transforms a nice hand held device into a luggable package the size of a makeup case. While a “quick and dirty” solution for device vendors, external radios represent problems for customers. External modules get damaged and lost, and the additional connections between the device and external radio represent new points of failure. Trouble shooting deployed connectivity solutions represents a significant hidden cost for health care providers, and bolt on solutions like this one only contribute to the problem.

The good news is workflow. Connectivity is all about workflow - the process steps required to complete the tasks that surround the connected medical device - and wireless is a big improvement over forcing nurses back to a certain location to dock a device to download data. Perhaps the biggest workflow weakness with add-on radios is establishing patient context.

The apparent move among point of care diagnostics vendors from batch connectivity via docking stations to wireless connectivity is also an example of the incremental approach that many device vendors take with connectivity. As I'm fond of saying, you don't know what you don't know, and it is all too easy to take that first obvious ideal - “hey, sure, nurses can just take the device back to the recharger/docking station to download data!” - and after the fact realize that customers think it sucks don't like it. The next obvious step for point of care diagnostics vendors is wireless, but there are inherent problems here too. Then it will be something else.

Part of the problem is as that vendors look to customers for the solution (”what do you want?”) rather than requirements. Point of care diagnostics are relatively new for customers, and connectivity is certainly very new - at best customers can tell you what they don't like about your competitor's connectivity solution, and can't describe the optimal solution because vendors have yet to build it.

The end result is an expensive and frustrating experience for customers and vendors both, where imperfect incremental solutions are bought and rejected over several years. After a thorough needs assessment and vendor selection process (that's focused more on the workflow than anything else) buyers should insist on trial installations for final evaluation and acceptance.

Vendors should consider taking a longer term view of connectivity to minimize or eliminate these incremental solutions - you'll spend a little more up front, but you'll save a lot in the end. The vendor pay-off for doing connectivity right is the competitive advantage of a superior solution. Similar concepts apply to the software side of connectivity solutions - the data management, remote access, HL7 interface, etc. Fortunately, new approaches can greatly reduce time to market and development cost for connectivity and related software - if you know what you're doing…

Thanks to Mark H. for the tip. Pictured right is the OneTouch wireless glucometer. You can just see the Lantronix module's antenna at the back of the case against the lid.

Respironics was showing Respi-Link, remote monitoring capabilities through an RS232 serial port. The biomed must take the device down to their shop and connect it to a computer that runs a special Respironics client. Through this connection, users can download firmware updates and do run some diagnostics. Respironics is using Axeda for this feature, and support the Esprit, NICO and new vents. No word on wireless network connectivity.

Walking down the aisles, I came across the IMT Medical booth. The Viasys Vela ventilator they were using to demonstrate their test fixture sported an RJ45 connector for what is apparently an Ethernet connection. The product page only mentions “data output port for graphic and information systems” - which sounds suspiciously like a serial port to me. Perhaps a reader can enlighten us further.

The Tyco booth was dominated by Nellcor - and a rep sporting an attractive forehead worn SpO2 sensor. I was going to get a photo of him, but I'm really not that mean. Nellcor wasn't showing the wireless SpO2 monitor they displayed at the Rapid Response Systems conference last month in Pittsburgh. In the back of the booth was a Puritan Bennett ventilator - no connectivity really, just an RS232 serial port.

Radianse showed a new real time location system (RTLS) receiver. Unlike the previous boring rectangle, the new receiver sports a modern wave-like shape. Referred to by some as the “Captain Cruch hat,” the wider form factor supports a new antenna with a horizontal egg shaped receiving area. This new antenna reduces sensitivity to tags on adjacent floors, but maintains excellent coverage for the floor on which it is locationed. The back of the new receiver sports both power over Ethernet (POE) and a plug for a DC power supply. There is also a slot for a WiFi card so the receivers can be configured to talk to a wireless network rather than a wired Ethernet.

Radianse mentioned that there's a new patient worn single-use tag in the works, due later this year. This tag will be 40% smaller and less expensive.

At Draeger's booth, they showed their new telemetry system. This is the same system they showed last year as a “pre approval” system. They have received their 510(k) and will be shipping in the next few months. You can see a quick demo of this unique telemetry system here.

Draeger also showed a new “clinical PC,” the Infinity C700. This device sports a wide-screen display that shows a few more seconds of waveform. Like previous versions, there is an Ethernet connection between the patient monitor (in this case an Infinity Delta patient monitor).

Spacelabs was showing their Flexport. It was not really clear whether this was a new product or not. The module interfaces third party devices (they had an Edwards cardiac output monitor hooked up in the booth) to Spacelab patient monitors. A serial D-connector goes to the third party device, and an RJ45 connection goes to the Spacelabs monitor - it was not clear whether the RJ45 was an Ethernet link or what, but the module is configurable (by Spacelabs only). The module integrates both numeric and waveform data from third party devices, and supports alarms and alarm notification through Spaclabs' central station. It was not clear if the third party device data could also be passed to the EMR via a Spacelabs HL7 interface.

After the initial flurry of new RFID vendors, I was surprised to come across a brand new vendor. RadarFind has been in development for a number of years and offers a unique approach to indoor positioning - an approach they assured me was vastly superior to anything else on the market.

This system uses 900 Mhz, so it's not a WiFi based system like Ekahau or AeroScout. Here's the good part - the receivers are built into wall outlets and use the electrical wiring to transmit positioning data to a collector that aggregates data from multiple readers. This reduces installation costs considerably. Collectors are connected to the positioning engine (the software that determines location) via Ethernet.

Another difference with RadarFind is that the readers initiate communications with the tags, rather than the other way around. Tags run about $50 or less, depending on features. Their top dollar tag has a 3 position sliding switch that can be used to indicate status - so a caregiver or tech could indicate a specific status, like room occupied, dirty, or clean. Readers go for $200-$300 each.

The real secret sauce in any positioning system is how they determine position. RadarFind uses highly engineered MIMO (multi in/multi out) antennas in both the receivers and tags. The math used in the positioning engine utilizes both signal timing and strength in what they called “windowed RSSI.” They use “active null-busting” to minimize the effect of multipath interference, which is common in hospitals. Positioning accuracy was claimed to be between 8 and 9 feet. The system is installed in their first beta site, so they don't have data on percent of room level accuracy readings, etc. The company is VC funded, has raised about $5.5 million in 2 rounds, has 11 employees (they contract a lot of their engineering), and sells direct.

I stopped by Physio Control - their booth was sort of slow, what with the FDA stopping product shipments and all. Most of us from the vendor side for any length of time have lived through a similar experience; it is not fun. Physio does have some interesting things in development, and the first is released but had a “soft launch.”

They've got a solution that uses an ambulance gateway to link their monitor/defibs to a server farm on the Internet. These servers will serve up a web application for the review of “STEMI” patients - that's ST elevated myocardial infarction patients, those who benefit most from rapid therapy administration. The application will be community focused providing access to multiple hospitals so any diversion issues can be quickly resolved. The system is already in use in two communities, one in the tri-cities in Eastern Washington state and the other in the North East.

One unresolved product feature question is whether they will open up the system and allow other vendor's monitor/defibs connect to the servers on the Internet. I predict that if they keep the system closed (for a misguided competitive advantage) the system will see very limited adoption. If they open up the the system, many more communities will buy because they have devices from multiple vendors - either it's too expensive to replace all their monitor/defibs at once, or they're owned by separate entities. In this latter scenario, Physio will still have a competitive advantage against every vendor who has yet to integrate with the solution - integration for Zoll, CardiacScience or Welch Allyn could easily take 12 to 24 months, and some may even be foolish enough to refuse the opportunity to participate. Tendencies towards proprietary systems strategies run deep - I don't expect Physio to open the system, but time will tell. A couple of Physio's devices include Bluetooth and they are looking at WiFi connectivity.

Zoll showed a new R-Series monitor/defib intended for hospital crash cart use. The device will soon sport an 802.11b radio - when I teased them about their “primitive” radio, they noted that a follow-on radio will support 802.11b/g. What's really weird is that the radio will only work peer-to-peer, talking to a PDA used to capture data and document code events in Zoll's PC-based CodeNet application. A future version of the radio will connect to the infrastructure (the hospital's access points) to provide an enterprise-wide defib dashboard. This device maintenance and readiness application will indicate test results, devices that require servicing, and in a future version download firmware updates, provide network clock sync, distribute the hospital's standard defib configuration, and provide access for remote diagnostics from the Zoll mothership.

The Anritsu RF analyzer is the preferred tool for RF trouble shooting and identifying sources of interference. At $14,000 this tool is not as widely available as it should be. Current barriers to adoption include price, complexity, and the perceived skill level required of users. With the rapid uptake of wireless technologies in hospitals, some improved marketing could make this device part of the standard kit in every hospital's clinical engineering shop. Hopefully they'll start to think outside the box and get this important tool into a greater number of sites.

Pictured right is the Anritsu Spectrum Master.

UPDATE: Word has it that Physio Control will open their STEMI Internet-based information system to third party monitor/defibs. This is driven by the fragmented market where a community may have multiple EMS agencies, referring hospitals and PCI centers.

I saw the new Hospira pump - you know, the one with the funny name (okay, I'm writing this on the plane and can't remember the Symbiq). It has a very nice color touch screen that covers almost the entire front of the device. The device has an 802.11b radio presently, but will have an a/b/g radio in the third quarter. Surprisingly, there is no patient name displayed on the pump. The helpful and patient folks in the booth attributed this to HIPAA requirements; either their product manager's don't understand HIPAA, or this is spin for what will be an increasingly important question. This apparent short coming could be a consequence of Hospira's dependency on third party meds admin applications to establish patient context. (The good news is the display is all software, so adding the name should be relatively easy.) The back of the pump has a heavy duty faux metal mount for attaching the pump to a pole.

Baxter's booth was a bit slow, having recently come off their FDA recall and ship hold. They didn't have any new products. The wireless radio they showed at HIMSS 2 years ago in Dallas is still not available. Nor is the wireless PDA they showed that established patient context and provided nurse carried alarm notification.

Cardinal's Alaris pumps remain the only infusion pumps to establish patient context on the medical device (the safest most reliable way to associate data coming out of a medical device) - without any additional third party software (although I doubt it's any less expensive than Hospira's multi vendor solution).

Neither B Braun or Sigma were exhibiting at the show.

You may ask, “Why obsess over patient context?” Without patient context, “smart” pumps can only provide oversight of pump configuration based on the med being administered - there is no consideration of the patient (that might determin dose) or the patient's order (that could indicate the wrong medicine). Also, with out patient identification (and caregiver ID) any QA database is anonymous - a very blunt tool for improving safety. Finally, it's hard to export pump data into a medical record, provide surveillance, or do alarm notification beyond the pump itself without patient context. With the increasing push on patient safety patient identified data will become increasingly important.

Philips had a nice customer appreciation event one night where I managed to pick up some information on their new SureSigns VS3 vital signs monitor and Philip's HL7 implementation. The VS3 reminds me of the saying, “If your only tool is a hammer, every problem looks like a nail.” Being strong in high acuity patient monitoring, the VS3 looks more like a continuous monitor than a spot vital signs monitor. In fact, while many vital signs monitors only display numeric data, the VS3 can also show waveforms (SpO2) and trended data. Like the VM line, the VS3 uses a bar code reader to establish patient context. The system does not support an ADT interface, so you can't identify the patient from a pick list - important if you don't already use bar code patient IDs.

The device is not wireless - could this be the result of their commitment to WMTS for all their patient monitors? Some customers might balk at installing WMTS house-wide just for spot vital signs. Consequently, the VS3 (like all their VM low acuity monitors) has an RJ45 Ethernet port on the back of the device. This forces a use model where the caregiver gathers a queue of data as they take readings from patient after patient. When they're done, they must park the monitor where it's plugged in to recharge and connected to the network for a batch data download. To support this use model, the VS3 presents a nice listing readings taken in the bottom half of the big luxurious (for a vital signs monitor) color display. The downside of this approach is the potential for delays in the data getting on the chart, either because the caregiver was interrupted while taking readings, or they forgot to plug in the network cable when they were done. Wired network connections for portable devices also suffer from the not uncommon occurrence when forgotten cables jerk out the wall plate, frequently disabling the network port. Wireless connectivity avoids these limitations.

Philips was the first vendor to provide direct HL7 output from their medical devices. Market acceptance has been pretty good. The devices themselves require a server that aggregates feeds from multiple monitors, and the devices have some configurability. The longer term plan is to eliminate the server so monitors can communicate directly with the host system. It would be interesting to see how this would work out.

GE showed the new Carescape Data Module. This update of the Tram data module provides data continuity across multiple GE patient monitors. When originally conceived, most patient monitors were not portable and patient transport was done with special monitors. Nowadays, most monitors are portable and the use of transport monitors is limited. The module has cabling to support two use models. When placed near the patient, the Data Module uses shorter sensor cables to the patient, providing reduced chance of patients getting tangled up in lead wires. In this case, a single long cable connects the Data Module to the patient monitor. The other use model uses a shorter cable between monitor and Data Module and better supports traditional transport use cases. The Data Module has its own battery for transport, and can even power the portable monitor if that monitor's battery is not charged.

GE was also showing version 5 of the Carescape CIC Pro central station, and Carescape Mobile Viewer. The old Patient Viewer only supported the Unity Network (and the old Marquette patient monitors), the new version also displays data from Datex patient montors. The Mobile Viewer provides remote surveillance on PCs, tablets, PDAs and cell phones. While alarm conditions are shown, the product does not provide alarm notification.

GE also showed their Dynamap with an optional infrared (IrDA) communications port. The IrDA port allows the spot vital signs monitor to transmit data to a CareFusion PDA for subsequent uploading to the EMR. Since the acquisition of CareFusion by Cardinal Health, it is not clear what GE plans to do long term - nor is it clear that Cardinal has any interest in continuing CareFusion's OEM business rather than focusing exclusively on their own point of care (PoC) product strategies.

Also on the monitoring front, Welch Allyn noted a refresh on their MicroPaq - incorporating the latest Masimo SET board and their new 802.11a/b/g radio. The new device will weigh the same, but be a bit thicker at the top. Colin showed the BP-S510 that will be released next month. The Colin Prodigy II spot vital signs monitor incorporates new wired Ethernet connectivity. CAS was also showing their vital sign monitors. Mindray was showing a number of devices - conventional telemetry pack, low acuity monitor and a portable ultrasound system. Connectivity was pretty basic with a simple central station and RS232 for data export. Goldway, another Chinese device vendor, was showing a couple low acuity monitors. I've got to wonder how successful vendors will be with low cost manufacturing business models. While device prices are high (I mean how many ICU patients really need a $42,000 monitor?), market requirements have evolved beyond the box itself. Most vendors spend too much for connectivity features, but off-shore vendors also have the challenge of getting good requirements.

Pictured right is the Philips VS3 vital signs monitor.

UPDATE: In reviewing the bits on monitoring vendors above, I realized I forgot Nihon Kohden. They had a pretty big island booth and showed their ZS-940P patient worn low acuity patient monitor. This device received prominent position in their booth (photo).