Vendor Problems with Connectivity: An Overview
Medical device vendors are like everyone else, they tend to resist change. It's rarely very pretty when technology and market requirements force a successful box company to add connectivity features. Over the years I've seen a range of outcomes and reactions, from denial (E for M cath lab recorders) to easy embrace (Sarns/3M). Fundamentally, connectivity is a transition from a homogeneous environment controlled by the manufacturer to a heterogeneous environment that feels completely out of control.
When I started out some 20 odd years ago, connectivity meant a PC with some data analysis and reporting software plugged into the serial port on the back of device. Connectivity today means a bidirectional network connection that is wireless (unless it's a CT that's bolted to the floor). Now devices have to talk to (or interoperate with) third party systems that work within a general purpose IT network environment populated by other devices. None of this is rocket science, just an interrelated complex mess that benefits from specialized planning, process and expertise.
Root causes for connectivity problems are based in human nature. First is the desire to apply current thinking and processes to new problems. If most things in life were intuitively obvious we would all be rich, driving flying cars or living in space colonies. Much about connectivity is not intuitively obvious. The next root cause is resistance to change. When a device vendor is faced with connectivity, they've typically been doing business the same way for 10 or more years (and if not the company, then certainly the employees). Successful vendors have world-class execution that creates a narcotic like comfort zone that's hard to leave. Finally, most device companies aren't very strategic. Their strategy (like their business model) was refined years ago, they've become tactically focused, strategic “muscles” have atrophied.
Linear common sense thinking leads vendors to apply their current business model to connectivity. This creates problems in product development, sales, installation, service and support. The components in an embedded medical device have a life cycle of years, the life cycle of connectivity components is measured in months; applying the same design and product testing processes don't work.
An ultrasound system that records to film looks almost identical to an ultrasound system connected to a PACS. The first is bought solely on image quality; the second is bought on workflow first, then image quality. Installing the standalone ultrasound is as simple as uncrating it, plugging it in and turning it on. However, a connected ultrasound system is not “installed” until it talks to a PACS properly. The skill set and pay scale for a field service rep who swaps boards is significantly different from someone who does network integration and DICOM configuration. Time and again vendors have learned these lessons the hard way, and both the vendor and their customers have suffered.
Using a device business model with connectivity has financial implications as well. Product offerings that include third party components (like computers and network gear) will never return the factory margins of core device products. The gross margin device vendors ranges from high thirties into the fifties. A well executed turnkey software business model will deliver nine to twelve percent to the bottom line. It is unavoidable that the more a vendor's revenue comes from connectivity, the lower their gross margin. This presents an interesting financial management problem for device vendors that is usually dealt with after the fact rather than in planning.
All of these differences bring us to resistance to change. I've seen resistance to change in the refusal to hire network engineers because of the difference in pay vs. existing field service engineers; the 40 to 60 percent sales force turn over because of a refusal to change from selling boxes to the solution selling required to sell connectivity enabled devices; and a refusal to expand product test and verification capabilities to match the heterogeneous environment in which connectivity products exist. Corometrics' first generation fetal monitor surveillance system was built just like they made devices, from scratch (they even wrote their own operating system) while competitors were fielding lower cost PC-based surveillance systems with the same or better features. Because resistance to change is an emotional response, there is little logic at work and can result in “business insanity.”
Finally we come to an absence of strategic planning. Device vendors typically have device strategy down cold, but given the preceding root causes, strategic planning is seldom applied to connectivity. The natural device vendor inclination to do everything themselves so little thought is given to existing and new core competencies required by connectivity. Questions about intellectual property, where a vendor adds real value to a broader solution, strategic alliances, and long term market development often go unasked. There is a definite tendancy to try to do too much and become seduced by the beauty that is connectivity.
All of these problems can manifest themselves in physical symptoms that impact customers and can provide competitive intelligence to other vendors. Internally, connectivity can suck up an inordinate portion of R&D budgets and engineering time. The most prevalent symptoms are in product availability, either delays or products that never make it to market. A variation of this is the first generation connectivity product with minimal features that is followed by the “real” product that customers want. The first generation is hardly worth buying, and the follow on product takes forever to come to market. A related symptom is the buggy release; this is where a major product release with many new features and capabilities is found to have, ahem, problems once installed in customer sites (but it tested great in the lab).
Wireless radio selection is an area ripe for these problems because vendors aren't as familiar with market and technical requirements or the nature of these types of component products. (It's just a WLAN card right? How hard can that be?) More than one vendor is faced with replacing a radio they just came out with.
Finally, we have the edge condition customer who experiences problems. These customers push the envelop in either scale or complexity in their use of the product, and as an outlier, testing proves inadequate resulting in problems.