The Medical Device Connectivity group on LinkedIn has some interesting discussions from time to time (you can join here). This week, Muhammad Siddiqui, a clinical analyst at the Cleveland Clinic, Abu Dhabi, asked:

I'm looking for some feedback. Why would any healthcare organization choose to go with Capsule if they have 90% Philips bedside solutions? Why would they not consider Philips as the nutural choice for device integration? I want to know and your feedback will be greatly appreciated.

As usual, there were numerous insightful responses discussing how the two approaches - connectivity enabled by medical device makers and that provided by vendor agnostic manufacturers - differed. What struck me was that there was no discussion about the workflow that the connectivity was supposed to provide. Since patient monitoring is mentioned, is the desired workflow remote surveillance or alarm notification? Perhaps the need is for clinical documentation from patient monitors to the patient's chart in an EMR? Another common application is data aggregation in high acuity areas like the OR or ICU. While each of these workflow applications is enabled by an MDDS, they are often provided by different sets of vendors.

Connectivity is workflow automation through the integration of medical devices and information systems. A basic question is exactly what workflow you're looking to automate with your proposed connectivity? Unfortunately, no one connectivity solution does all workflows equally well.

Workflows like remote surveillance and event review most often come from the medical device manufacturer (exceptions include Cardioupulmonary and LiveData). Alarm notification beyond remote speakers, ceiling lights and message panels are most often available from third parties (Welch Allyn is an exception here). Clinical documentation, or EMR charting of medical device data comes mostly from third parties and medical device manufacturers who have their own gateway products (like GE and Philips patient monitoring gateways).

The discussion comments about the trade offs between medical device maker's and third party solutions are all valid. Device makers like proprietary end to end solutions because it raises customer's switching costs and helps lock in their installed base. Because they make the medical device and the connectivity solution, theoretically they can create a better - more feature rich, easier to use - solution than a third party. An example of where this theoretical potential is realized is Welch Allyn's alarm notification product.

Likewise, third party connectivity solutions are also proprietary. The big difference here is that the third party solutions are device manufacturer agnostic, so you can change your patient monitoring vendor - or add manufacturers who make different kinds of devices other than patient monitors - without having to swap your connectivity solution too. However, should you want a connectivity workflow that's not available from your third party connectivity solution provider, you must add another vendor who can deliver on the new workflow or go without.

Unfortunately, the market has not evolved to the point where any third party connectivity solution can provide all the different connectivity workflow solutions. Currently, providers who have implemented various connectivity workflows also have multiple third party (and often medical device maker) connectivity solutions. The connectivity market can be segmented between EMR documentation, alarm notification, and remote surveillance/data aggregation applications. While there are third party vendors whose products theoretically could support all three segments of connectivity workflow, I'm not aware of any that do.