Lantronix Announces Deal with Point of Care Glucometer Vendor
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)
quantity purchase commitment valued at approximately $360,000 over the
initial 12 months of production and an additional minimum commitment
for approximately $490,000 of next-generation technology based on
certain project milestones.
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.
AAMI 2007 – Exhibits, Part 2
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.
AAMI 2007 – Exhibits, Part 1
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).
GE Unveils Carescape
GE Carescape is the main focus of a front page story
in Healthcare IT News (dead tree edition that came today). GE
Healthcare brings out the big guns to describe the Carescape solution.
Let's start with the problem as they define it:
Each system serves an important function, and yet they might not all be connected in a way that information is shared easily.
Patient monitoring is defined as devices that collect and display
patient data. According to GE Healthcare officials, false alarm rates
exceed 80 percent, clinicians are overwhelmed by the amount of data
they have to collect, and critical vital signs are sometimes not
provided in time for proactive responses.
According to David Freeman, chief marketing officer of monitoring
solutions for GE Healthcare, “…traditional patient monitoring
(measures) have not been keeping pace.” Amen to that. But it seems to
me that a major factor in this “jungle of technology” is the proclivity
for vendors like GE – virtually all medical device vendors, in fact -
to build end-to-end proprietary systems. This megalomaniac vision that
places the vendor's product (and not anyone else's) as the center of
the universe is perhaps the biggest factor in patient safety problems
at the point of care. The traditional solution for this problem is to
buy everything from one vendor – except there is no one vendor who
makes everything, not even GE.
The solution is, “a new product portfolio called CARESCAPE. Its goal is to provide a
wireless infrastructure that offers clinical decision support, advanced
parameters and device integration and control at the patient’s bedside.”
Using enterprise access – what Freeman calls “the wireless
backbone” of the suite of solutions – CARESCAPE is designed to pull
together a wide range of disparate devices and systems for easy access
and control, allowing a doctor in an emergency room to quickly call up
a patient’s full electronic medical record or a nurse coming on duty to
check the status of all of his/her patients.
“It just takes one or two clicks on the keyboard and it’s all
there, as opposed to walking away somewhere else” to a distant computer
or series of workstations, says Munesh Makhija, general manager of
systems and wireless monitoring solutions.
What exactly all this means, time will tell. Perhaps I will be able to get some details next week at the AAMI conference in Boston.
Mirth: the Open Source Interface Engine On Steroids
Software is in the midst of substantial change.
level of automation in hospitals is starting to exceed the ability of
any “single application” to address it (not to mention the ability of a
vendor to cobble one together through acquisitions), and IT
architectures like SOA and web services are making middleware a natural
solution for enterprise-wide services (think Emergin
and event management). Likewise it seems that every new application has
an engine for this and an engine for that – rules engines, messaging
engines, interface engines, positioning engines – geez, they're
everywhere.
As the proliferation of software engines, or “enginification” continues, the value inherent in an application rises from the application code itself to the intellectual property that's embodied in the definition and configuration of the underlying engines. Thus the foundation of clinical information systems (FDA regulated or otherwise) is increasingly based on these (almost) commodity engines that drive most of the key features in applications. And as engines become more prevalent, they are increasingly available as open source software.
A major portion of medical device connectivity is software. Due to the lack of interoperability standards, not only must vendors network enable their devices, but they must provide server and client applications – often at considerable cost. A the same time, much of a server or client is little more than commodity HIT software plumbing – basic databases, role based access control, web servers, HL7 interfaces – they've all been done many times before. Wouldn't it be nice if you could look at software like you look at computers – something off-the-shelf? Increasingly, you can.
A good example of this trend is the Mirth Project open source interface engine. Mirth is the evolution of what was the embodiment of proprietary intellectual property (the once nascent interface engine product category) and provides a common tool to be used by vendors and hospitals alike. The Mirth code base was developed by WebReach, a contract development shop that started as a fuzzy logic expert systems developer in the '90s. From expert systems, WebReach did development work for pharma and has evolved into an open source health care solutions company.
I'm still wrapping my mind around the many ways that Mirth could be used – the possibilities extend way beyond simple HL7 interfacing to EMRs and other typical HIT applications.
Wireless Vendors Challenge Cisco in Hospitals
Things are changing in the WiFi market. At HIMSS 2007 I noted the booth traffic Aruba Networks and Meru garnered. There was also new comer Extricom who showed a wireless LAN that has a “one-channel” deployment, like Meru.
Since the show, I've heard rumblings of vendor trials at hospitals where the sales eventually went to someone other than Cisco. Until recently, Cisco was the undisputed IBM of networking, including wireless. You know, “no one ever lost their job buying Cisco.” Well, it seems that those days may be over – at least for now.
Wireless networking vendor Aruba Networks has been gaining increasing momentum in health care lately. Aruba was selected by Welch Allyn as the preferred infrastructure for their new 802.11a/b/g radio embedded in their patient monitors, and for their nurse-carried alarm notification system (more here). Aruba's latest marketing vehicle is a market report titled: Healthcare WLAN Appliations: North American Hospital Survey Results. The report identifies the top five wireless LAN applications in hospitals – mobile EMR, VoWLAN, automated meds administration, WiFi-based indoor positioning systems, and wireless patient monitoring. At the right you can see that mobile support for EMR adoption leads the
application pack, and wireless VoIP runs a close second. Surprisingly,
automated meds administration is third, followed by indoor positioning
and monitoring. Note that most hospitals expect to deploy all 5
applications. (You can download your own copy of the paper here.)
The adoption of these 5 applications is roiling the wireless LAN market in health care; the reasons are bandwidth and mobility. While much is made about wireless LAN coverage, the challenges facing vendors are accommodating the bandwidth required by these apps, and providing the active management to ensure that the data streams for each of these apps meet the different requirements of each application. Implied in “active management” is the ability to also monitor each application's performance on the network. Word to the wise: the ability of current vendors to meet these requirements is highly variable. Make assumptions about what might be a “safe choice” (or take vendor statements at face value) at your own risk.
At HIMSS 2007 I spoke with Peter Mongroo of Aruba, who is their man responsible for the health care vertical. I was impressed with his (and Aruba's) understanding of the market, and especially what it means to put life critical data on the enterprise wireless LAN. Applications that demand true mobility and can come with heavy bandwidth loads can challenge wireless LANs. There are many highly technical issues, so techie that even my eyes started to roll up into my head. Peter mentioned 3 key issues.
First, to support true mobility, wireless LANs must allow clients to roam between access points (APs) quickly. More conventional products can do things like encrypt the wireless link at the AP rather than the switch. This means that encryption keys must be passed between APs as clients roam, adding overhead and reducing roaming performance.
Quality of service (QoS) is another key requirement, especially for life critical data and streaming applications like VoIP. Conventional QoS is done at layer 2 of the ISO network model and keys QoS to devices (using MAC address) that are divided into groups based on bandwidth requirements. The problem with this is that many devices are multi purpose – a PDA could do meds administration, alarm notification, and include a soft client for wireless VoIP. The high mobility requirement is QoS that is managed by application, regardless of the device.
Like a lot of medical device connectivity solutions, wireless LAN security can be based on wired ports. Mobile users must be able to move beyond the area covered by a wired port (say a nursing unit or surgery department). Security policy must follow the user as they move across the enterprise, and even use different devices.
Aruba sponsored a webinar last week that highlighted 2 of the 5 applications: Welch Allyn's wireless patient monitors and Ekahau's indoor positioning system. While both presentations were enlightening, we'll focus on patient monitoring. Welch Allyn's presenter was their wireless rocket scientist, Steve Baker, PhD. Steve described how Welch Allyn overcame regulatory hurdles with the process they developed for deploying life critical data across enterprise wireless LANs. Very interesting stuff – you can download the webinar presentation here, and an archive of the webinar here.
Draeger was the first to deploy patient monitors across the enterprise wireless LAN with their Infinity OneNet, and there are many things I like about their implementation. Unfortunately, Draeger doesn't have much market share in the US (although they're won a number of big deals in Europe against Philips with the new network technology). GE Healthcare and Spacelabs can also run on enterprise wireless LANs. Philips continues to push their proprietary WMTS wireless network based on the European telephony standard DECT. While Philips sells 802.11b/g enabled patient monitors outside the US, their ability to implement on a shared enterprise wireless LAN is limited. Philips appears to be
NOTE: Due to a glitch with my content management software, an earlier draft of this post – which has been extensively revised – was posted on the blog. Please disregard the earlier version, and sorry for the confusion.
