The above title is the topic for my presentation at this year's Medical Device Connectivity Conference. The event this year will be held at the Hyatt Dulles in Herndon, VA November 21-22. The agenda is just about finalized; you can check it out here.

This post is both a preview and a bit of thinking out loud as I continue to develop the the presentation. Suggestions or criticisms are welcome via comments below.

Whenever connectivity is added to a product or solution, things change. If this is a new product direction for the company (or a new variation of an established product category purchased by a provider organization) the resulting changes are often unexpected - by both buyer and seller. And whether expected or not, not meeting the market requirements that result from these transformations means bad things can happen like:

  • Unsatisfied customers and/or user resistance due to unmet requirements,
  • Lower than expected adoption rates, and
  • Lost sales to competitors who better meet requirements resulting from transformations.

The goal of the presentation is to provide a concise framework to be able to identify and anticipate those changes, even when it's the first time dealing with connectivity.

First let's consider what drives the adoption of connectivity features before we get into the possible transformation domains themselves. The root causes for these changes are what drive most all product development decisions: meeting evolving market requirements, creation of a sustainable competitive advantage, and cost reduction to increase profitability. These root causes relate to specific product strategies that often include some sort of connectivity as enabling technology or part of a whole product solution, or as an end in itself. Here are some examples:

  • Take advantage of a conventional connectivity application, e.g., alarm notification or clinical documentation;
  • Move a capability from a remote centralized location and push it to the point of care;
  • Miniaturize a device to reduce cost, make it easier to use and/or able to be used more broadly than before;
  • Transition the product from a capital expenditure to one based mostly on disposables; or
  • Re architect the medical device by moving some embedded system device functionality to software and the enterprise network.

The bullets above are examples of actions that trigger product transformations resulting from connectivity. When product strategies like those above are pursued, the resulting transformations can impact a number of different domains:

  • Device use location
  • Users
  • Product technology
  • Workflow changes
  • Interoperability requirements
  • Business delivery system

These domains are useful in categorizing change and working to determine and plan for new requirements that may be a consequence of these changes. Many of the domains are interrelated. For example, changing the device use location will often impact users. These change domains have evolved over the past 20 odd years I have been developing and launching connectivity based solutions.

Case Study

A good case study to explain the above framework deals with blood gas analyzers. In the beginning blood gas analyzers were bench instruments found in large clinical lab departments typically housed in the hospital basement. Like all the other bench instruments in the clinical lab, the blood gas analyzer was tightly integrated with a comprehensive lab information system (LIS) and often, automated sample handling systems. This high degree of automation was overseen by trained technicians who provided for the care and feeding of these instruments and automated systems, ensured quality control, fixed operational problems when they came up and handled STAT orders or other exceptions. While costs were relatively high (dedicated lab space and staff, plus the instrument and reagents), at sufficient volumes individual test costs were low. A shortcoming of the centralized approach was the elapsed time from when a blood gas order was created, the sample drawn and transported to the clinical lab, the test run and the result available to the ordering clinician.

In time, manufacturers realized they could miniaturize their blood gas analyzers, reduce their cost and generate test results using disposable cartridges. At first these new analyzers were desk top sized and placed in nursing stations. As technology advanced, analyzers shrunk to hand held devices. At a high level this transition leveraged miniaturization and the shift to disposables. Numerous transformations fell out of this product change. Let's take the transformation domains one at a time.

The photo accompanying this post is of the Epocal Epoc blood analysis system. Epocal's strategy was to segment the essential medical device, the microfluidics diagnostic unit that accepts the disposable card that carries the patient's blood sample, with the IT component, the PDA and bar code reader that handles the workflow automation. This contrasts with Abbott Point of Care's i-STAT 1 Wireless approach of incorporating everything into a single device manufactured by Abbott. Both approaches are valid, but they have wildly different implications and consequences.

Alere Epoc blood testing system

Device Use Location

In our example, the blood gas analyzer is transformed from the clinical lab in the basement to the nursing station or the patient's bedside. This change has lots of cool advantages, like the ability to do STAT tests much more quickly, and the ability to do the test right where the patient and clinician are for a super fast diagnosis and perhaps immediate therapeutic decisions. How could this not be a terrific new selling feature and competitive advantage?

Changing the location in which the blood gas tests are performed produces numerous transformations. Device use location changes also tend to have a big impact on users and workflow.

A number of consequences of this transformation jump out:

  • The obvious changes are those required for the blood gas analyzer to actually operate at the nursing station or at the bedside.  A microfluidic system must be developed along with the associated disposable cartridges. Appropriate power must be available for the device to operate. Feature changes necessary for the newly reimagined device to generate blood gas results are usually self evident as they are part of what is considered the actual medical device, rather than connectivity features.
  • There's still a requirement for trained operators of the blood gas analyzer, and additional resources from the clinical lab will be required to go out and perform these tests or caregivers will have to be trained and certified to perform the tests themselves.
  • There is still a requirement to do quality control with the same trade-off between sending people from the clinical lab or having caregivers assume responsibility for QA.
  • In the clinical lab blood gas analyzers are nestled into the embrace of a sophisticated LIS; pushed out to the point of care that LIS automation has to be delivered some other way - hopefully automated, but in the early days most often not. This absence of automation support at the point of care is why as many as 50% of test results never made it into the medical record, and why getting results to clinicians was problematic. Many of the functions automated by the LIS were transformed into manual tasks push onto caregivers; they were not happy.

Not all connectivity device use location transformations are as dramatic as these for diagnostic point of care devices. Yet, many connectivity features shift the location in which certain functions are accomplished or used from one place to another. For example, clinical documentation of vital signs moves much of the work from charting at the nurses station to the point of care where the data is acquired. Alarm notification moves the notification from the central station at the nursing station to a nurse carried mobile device. While these are not dramatic changes, they are changes none the less, and must be anticipated and managed so that they contribute to the new value proposition, rather than detract from it.

Users

The users involved in the use of the medical device solution transformed by connectivity can also change. Here again, our blood gas analyzer provides a dramatic example. As noted above, moving the device use location can result in a whole new set of users that have to be supported by the device and trained in its use. Less radical transformations can include:

  • Certain new features and capabilities can become available to users in management and supervisory roles (e.g., dashboards, activity reporting, escalation).
  • Also, new features can become available to support personnel who previously were not involved in the use of the medical device. In this case, information and/or tasks delegated from traditional users to support staff.

Transformed medical devices always come with new training requirements for existing users. New system components, like dashboards, client apps, bar code readers or apps running on new mobile devices, are examples of typical transformations that impact users. Users often have reduced workflow with automated tasks (a good outcome) or additional workflow because the transformed device pushes new manual tasks onto users (a bad outcome) to make up for changes in the product.

It goes without saying that user acceptance of the transformed medical device is critical to meeting sales forecasts and maintaining customer satisfaction.

Product Technology

Obviously, the core embedded system medical device (the conventional box that is the medical device) is transformed in some way. In our example, the blood gas analyzer is miniaturized using microfluidics and disposable cartridges, resulting in a pretty radical transformation of the product technology. Many other transformed devices can incorporate new technologies via miniaturization, connectivity or just new capabilities. Product transformations relating to connectivity can be divided into a number of categories:

  • Communications: wired or wireless communications between the conventional embedded system medical device and wireless sensors or medical device software running on general purpose computers (PCs, tablets, servers and smartphones).
  • The incorporation of features based on software running on general purpose computers. This mostly entails user interface issues and issues related to any computer hardware that is used directly by the user (e.g., a smartphone app versus software on a server).
  • The care and feeding of new computing devices. Users not only have to contend with new software user interfaces and features, they also have to develop new habits pertaining to the use of this new hardware. For example, developing the habit to consistently plug in and unplug an Ethernet cable before moving a portable device, properly wiping down computing devices with disinfectant, or ensuring that mobile device batteries are properly managed so that sufficiently charged devices are always available when and where they're needed are important new tasks that must be assumed by users.

Transformations in this category can have a big impact on the medical device manufacturer's business delivery system, as we will see below.

Workflow Changes

The steps a user completes to use a particular medical device is the workflow associated with that device. These steps are the sum of what's required to operate the device itself (what I call knobology) and all the other tasks associated with initiating the use of the device, staging accessories and consumables at the front end, any prepping of the patient, and the use and documentation of data produced by the medical device. Workflow steps that are not automated often become new manual workflow tasks required to use your "connected" medical device.

Adding connectivity to a medical device necessitates that the manufacturer automate some significant portion of this workflow that occurs around the direct use of their device. Typically, only a small portion of the overall workflow associated with the use of a particular medical device entails the direct operation of said device. Consequently, there is a substantial range of device workflow which the manufacturers of non-connected devices have little or no direct experience. Herein lies an often unrecognized challenge for manufacturers.

Users are intimate with their current workflows. New connectivity solutions are evaluated on whether it takes the user more or fewer workflow steps to use the device. If the new solution takes fewer manual steps, the product is terrific and will be widely used with joy. If the new solution takes more manual steps than the unconnected version, it will be a source of staff dissatisfaction and dropped in the toilet, lost in a drawer, or forgotten in an unoccupied room.

Interoperability Requirements

Unlike conventional stand alone medical devices that are self contained within an enclosure where everything is controlled, designed and manufactured by the vendor, with connectivity manufacturers have to interoperate with numerous devices and systems not under their control. Leveraging connectivity for medical device transformation results in transforming your once standalone medical device into an information appliance that exists within an open IT infrastructure - the enterprise IT infrastructure for acute care, and the broadband wireless infrastructure for ambulatory markets.

This means the manufacturer must integrate or interface with a variety of peripherals, IT components and other information systems all controlled by someone else. Each of these points of interoperability requires specification, design and testing before it can be sold. Then that interoperability must be installed (and made to work) and supported over time.

The challenge with being an information appliance is the rapid pace of change. Many of the devices and systems the transformed medical device will interoperate with change every 6 to 18 months. Manufacturers must proactively manage this requirement so the timing of projects can be managed and to reduce unforeseen incompatibilities introduced by interoperability changes.

Business Delivery System

To paraphrase Adrian Slywotzky, in Value Migration, a business delivery system is, "the totality of how a company selects its customers, defines and differentiates its offerings, defines the tasks it will perform itself and those it will outsource, configures its resources, goes to market, creates utility for customers, and captures profit." As it relates to connectivity, I divide the business delivery system into: finance, R&D, regulatory affairs, marketing, sales, installation, service and support.

Medical device transformation impacts each of these areas of business operations. Some changes entail changes in expectations (e.g., factory margins and finance), some require investments (e.g., enterprise IT infrastructure test lab), and some training (e.g., sales training for selling solutions rather than boxes).

All of these operational changes need to be mapped out so they can be planned for, budgeted and implemented in a way that supports the plan for the transformed product. When these changes are not addressed, they result in poor service levels, backlogs, higher than necessary operating costs, lost sales and other things to be avoided.

Summary

Connectivity features are often enabling technology of almost any kind of contemporary medical device transformation. And some transformations are based purely on benefits provided by connectivity. In either event, the result includes changes that are not always easily anticipated by either the manufacturer or buyer. The consequences of missing changes however, is hard to miss.

Can you think of any additional transformation domains that I missed? Given the breadth of content to cover in a presentation I think I will stick to one case study. If anyone has any case study suggestions - to replace blood gas analyzers - or as better examples of some transformations, let me know.

I hope to see you in at the Hyatt Dulles next month!

UPDATE:  I can't believe I didn't include this transformation domain: value proposition! Product changes, especially those incorporating connectivity, can dramatically impact a medical device's value proposition. Let's use a glucometer as an example. The value proposition for a glucometer used within a hospital or physician office is likely to center on the accuracy and precision of the result, and perhaps the elapsed time and cost to do the test. This is about the same value proposition (plus ease of use) for the manual glucometers used by diabetics in their daily life.

When you integrate that glucometer to a smartphone and a mobile app, the value proposition is transformed into something else. Now accuracy, precision and ease of use are assumed, and the new desired value proposition is an improved patient outcome made possible by providing the ability to better track the history of glucose readings and perhaps correlate that with additional patient provided data on diet and exercise.

As a glucometer vendor, the rationale for adding an app to your consumer glucometer is to increase market share and consumption of test strips. For whoever provides the time and/or money for the app, the benefits they're seeking are quite different. The market's justification for the app is reduced complications resulting from better management of glucose levels. Glucose management apps that don't deliver meaningful improvements in patient outcomes can be expected to realize poor levels of adoption of time.