One of my favorite Clinical Engineers called today, prompted by last week's post on the Emergin acquisition by Philips. Like many that I've talked to, this person was surprised that Emergin was not snapped up sooner. A list of potential bidders were mentioned, but my lips were sealed. I will say this about potential suitors for Emergin - the lines are blurring between conventional categories of vendors, on both the health care IT and device sides.

Also discussed were two continuing problems with medical device connectivity, alarm notification and point of care automation (we'll just call it "middleware" for this post). The first deals with hidden costs - on both the device side and infrastructure side. As you work through the details of plumbing everything together, you tend to uncover situations where to get feature X you have to upgrade your medical device system to version Y. If this happens more than a time or two, the cost of your upgrades quickly eclipses the cost of your middleware.

On the infrastructure side few enterprise networks, wired or wireless, were designed to support the life critical applications of medical devices. Providing surveillance and alarm notification are more than mission critical, and require proper management, monitoring and documentation. Historically, device vendors installed their own physically separate networks so these issues were not apparent to hospital IT departments (and IT departments didn't mess up device vendor's networks).

Medical devices are becoming enterprise applications, and no longer justify isolated networks. Hospitals looking to benefit from the features of a system like Emergin's are looking at rejiggering and upgrading their network (and maybe a lot more). So after you've upgraded your medical device systems and network, your total middleware costs have perhaps tripled from original estimates. Ouch.

Medical device vendors continue to push device integration issues off on hospitals. Sure they'll install a server and manage it (apply upgrades, diagnose problems and get it running again when needed), but they won't take any responsibility for the actual operation of device connectivity. What clinical engineers need is a software app that actually monitors medical device connectivity and interoperability - sort of like an HP OpenView for medical devices.

As things stand, the biomeds responsible for medical device integration can't even tell if a disconnected serial cable is the cause of an interruption in data from a medical device. This is way outside the core competencies of medical device vendors. But there are solutions to this kind of problem, Nuvon for one. Presently hospitals are left to their own devices to solve this problem, unless they know to insist that device vendors fill this gap.

Most alarm notification, point of care automation and medical device connectivity solutions continue to be difficult to buy solutions, mainly because everything out there is a partial solution, with gaps and overlap everywhere. In marketing-speak, this is still an early adopter market. The early majority of the market is sitting on the sidelines until someone can field a whole product solution.

Pictured right is Smiths Medical's Cadd System Pro meds administration software.