The most striking lesson that I've experienced, and witnessed repeatedly, is that when it comes to connectivity, "you don't know what you don't know." This applies to providers (buyers) as much as it does vendors (sellers). When presented with a new problem, it's human nature to apply current knowledge and mental models in search of a solution - thus the perennial appeal of the "intuitively obvious." Intellectually we know that problems don't all fall into the same logical framework. But, for various reasons we tend to apply known solutions to new problems, and only when the outcome is unacceptable do we contemplate the unknown. Decision making insanity aside, this typical approach is inefficient - or worse.

The barrier to effectively applying the intuitively obvious to connectivity results from fundamental differences between embedded system devices (i.e., conventional stand alone medical instruments) and the methods and technologies used for connectivity (i.e., general purpose computing technologies). This dichotomy in the application of the different technologies used in both embedded systems and connectivity, extends from product design to regulatory, manufacturing, marketing, sales, installation, service and support. For the vendor, the entire business delivery system is affected. Provider processes - needs assessment, vendor selection, implementation and ongoing internal support - are impacted as well by these differences.

So how are embedded systems different from connectivity? Embedded systems embody the following concepts:

  1. The embedded system is a black box in which the vendor controls everything.
  2. As many variables as possible are striped from the embedded system to simplify design, improve safety and reliability, and to improve serviceability.
  3. Cost of goods (COGs) and the bill of material (BOM) are supremely important as they determine product costs and factory margin (most device vendors' factory margin targets for a new product is 80% or higher).
  4. Because they are a black box, selling embedded systems are all about the box - the user interface on the box, how the device attaches to the patient and the data that comes out of the box (e.g., diagnostic image quality, accuracy of arrhythmia analysis, elimination of motion artifact in NIBP or SpO2, etc.) - rather than the customer. There is some focus on the customer's clinical practice and how that matches the embedded device's features, but the focus is still box centric.
  5. The sphere of vendor focus extends no further than attaching their product to the patient, the user interface and resulting usability. Installation involves uncrating the device, plugging it into a wall outlet, and training the caregiver and/or techs who will use it.
  6. Selling the embedded system entails a limited degree of account qualification to identify the characteristics of the device that are most important to the prospect, presenting the general features (usability, powering options, mobility, size and weight) along with clinical capabilities.
  7. Servicing the embedded system device entails diagnosing the black box itself and any external sensors connected to the device. To the frustration of biomedical engineers, the service model for customers has evolved to from board repairs, to swapping components, to swapping entire embedded system devices.

While buying or selling embedded system devices is not a cake walk, notice how each of the areas above are focused and constrained - inwardly focused - as a black box should be.

Before we get into a similar list for connectivity, remember that connectivity is more than just the ability to connect the device to a third party information system, that's the easy part. Effective connectivity - that caregivers and techs will actually use after you've bought it - results in the automation of specific workflows that occur around the use of the medical device. Already we've moved from constrained and inwardly focused embedded system model to the (by comparison) amorphous mystical realm of connectivity.

So, here's how connectivity impacts the principals noted above:

  1. With connectivity, the vendor is inexorably forced to give up the rigid control they enjoy with their black box and support the standards and typical options of the general purpose computing world. When implementing network connectivity on the embedded device, the vendor can't just support one method of network configuration (for example only supporting static IP addresses). The vendor must support all the general enterprise IT conventions for communications and integration.
  2. Supporting a myriad of IT conventions (network integration, authentication, encryption, LDAP/Radius integration, QoS, the list goes on...) adds a considerable number of what seem to be "unnecessary" variables to the device vendor. For sales, this opens a whole new area for account qualification, negotiation, and how the solution is quoted. The clinical buyer is between a rock and a hard place: they don't understand their IT department's requirements (and which ones are reasonable/unreasonable) and they have to trust the vendor who doesn't know any more about this stuff than they do.
  3. New costs associated with connectivity, like installation, systems integration, service and support, frequently overshadow what were once simple unambiguous decisions impacting COGs. Conventional IT features (say 802.1x authentication) that are stripped out to "keep COGs in line" can result in lost sales if the buyer uses a missing feature in their IT infrastructure. Holding the line on COGs and causing your warranty reserve to balloon or missing revenue projections are two frequent outcomes. With connectivity there are no "easy" COGs driven decisions.
  4. Connectivity fundamentally changes how the medical device is bought and sold. When you automate workflow around the use of a specific device, the impact of your choice of devices extends beyond the immediate use of the device itself. A great example is the point of care where medical device connectivity system decisions interact with those made for wireless phones, nurse call, and messaging middleware like Emergin or Ascom. The resulting workflow is impacted by multiple purchase decisions made over time involving a number of apparently unrelated vendors. Even the configuration of a single system impacts usability and workflow across all of the integrated systems.
  5. The sphere of vendor focus must now extend into multiple directions. As noted above, connectivity extends workflow automation. Product managers must extend their skills to capture these new workflows in a way that engineers can reliably implement into the product. The vendor must extend their knowledge into the general IT sphere to create competitive products, and successfully install, service and support them. This means new skill sets at significantly higher pay grades for certain positions in numerous departments.
  6. Sales must evaluate a prospect's workflow, compare it to their product's capabilities, and effectively position their solution against the competition - or judge the prospect unqualified due to a workflow mismatch. Buyers must evaluate their own workflow and the workflow support provided by each vendor under consideration, and accurately rank vendors on the quality of match between workflows. The same process is required for IT requirements like network configuration, authentication, encryption.
  7. In my experience, service is one of the areas hardest hit by the adoption of connectivity. There are significant new skill sets required, skills that have a higher market value than those of the typical embedded system field engineer or support tech. Since little of this change is anticipated and budgeted in advance (remember, you don't know what you don't know) service - and the customer along with their internal advocate, sales - learns these lessons the hard way. The result is frequently poor service responsiveness and quality, which improves (too slowly for sales and the customer) over time.

The nature of workflow automation, long the principal focus of IT, is new to embedded device vendors. For the sales rep, the guy or gal who is at the pointy end of the spear, this is a scary proposition. While internalizing connectivity is a job challenge for everyone else in the organization, the sales rep will measure the success of their company's adoption of connectivity by their income. Is it any wonder they get exercised when promised features don't materialize, things work poorly (or not at all), or customers are left in the lurch?

The next installment in this Selling Connectivity series will cover qualifying prospects. You can read the first of this series here.