DPAC-external-WiFi

I was talking with a clinical engineer the other day about the scourge of connectivity, the dongle. Also known as a wart or pustule, this is a wireless radio wrapped in a little box and stuck onto the back of a medical device. Now if you're wirelessly enabling legacy devices (either devices you already own, or devices currently sold by vendors) a dongle makes sense - it's certainly preferable to those serial cables that caregivers are always yanking out of the wall.

What caught my attention was the excuse that a number of vendors have given this biomed for using dongles in place of, you know, actually building the WiFi radio into the device. Much like with patching operating systems, the convenient excuse was our friends at the FDA. "We can't build the radio into the device because then the FDA would require that we file a new 510(k)," is what a number of vendors claimed. That is so wrong.

First, from a regulatory perspective, the requirements for filing a new 510(k) are based on changes to the device - in this case, wireless enablement. The impact of regulations is not dependent on whether the radio is attached on the outside, or integrated within the case. A substantially new medical device (as opposed to "re-skinning" an existing product) requires a new 510(k) anyway. Even the minor changes involved in re-skinning a device can trigger a new 510(k) if, like most vendors, there are already too many letters-to-file on the device. Any vendor who thinks they can take a device with a serial port and add WiFi connectivity without a 510(k) can expect some 483s (or worse) from their next FDA inspection.

The real reason some vendors want to use a dongle is captured by three little words, cost-of-goods (COGs). Most current medical devices are designed for worldwide markets, and outside the developed nations it's all about COGs. Since the vast majority of radios and radio chips are designed for general purpose computing platforms, they expect the host processor (in this case the medical device's CPU) to provide memory and processing for things like encryption, authentication, and quality of service. This additional processing overhead frequently means a more expensive processor must be used (which could also require changing the operating system), and the additional cost of more memory. As a result, even devices sold without the radio option cost more than a similar device that do not support radio capabilities. Sales and product managers can gnash their teeth and pull their hair all they want, but getting a program manager to increase his COGs - especially if you're "changing requirements" - can be darn near impossible.

So, what can you do, use a dongle like this one? Building two products (one with, and one without radio support) is too expensive. If you build in radio support, your ROW (rest of world) COGs are high, and if you use a serial-to-WiFi wart, your wireless solution is less competitive.

There are ways around this conundrum, but they are not easy either. If you're curious about some of those ways, give me a call.

You can expect the best connectivity features from the few vendors who really understand connectivity - everyone else will put off taking the plunge as long as they can, and when they do adopt, they will take the easy route - warts. A key competitive race (and one many vendors aren't looking forward to running) is developing a core competency in connectivity - good connectivity in products, along with the ability to properly sell (dealing with IT), install (especially systems and network integration), and support (good log files, remote access, IT-knowledgeable service techs).

Connectivity is a tall order, and the proliferation of warts on new or "upgraded" products indicates how far the industry has yet to progress. Pictured right is the DPAC serial-to-WiFi external dongle module.