Entrepreneurs are all about commercializing their novel technology, getting to market, driving adoption and realizing an exit strategy. Yet with the incredible focus on transforming their novel technology into something customers can buy, few startups take connectivity requirements into account until too late in the process. The consequences frequently result in revised go-to-market strategies, like going to market without important features or shifting to niche markets with lower connectivity requirements.

Customers Want More than the Box

There are many barriers to entry in health care: regulatory hurdles, entrenched competitors and gatekeepers like group purchasing organizations (GPOs). Increasingly, connectivity is becoming a barrier to entry - or perhaps a new price of admission. There are few medical device product categories that don't have some connectivity requirements. (More on the actual requirements below.) But besides buying the embedded device, providers are increasingly interested in buying whole product solutions.

Coined by Geoffrey Moore, a whole product solution is just that, all of the components and services required to fully realize the potential of the overall solution. Thus if one of your connectivity requirements is integration with an EMR for electronic charting, just putting a serial port on your device is not a whole product solution. Of course neither do you have to do the whole solution yourself. Frequently the best strategies entail providing part of the solution directly (developed yourself, outsourced, licensed, etc.) and creating the rest through business development and alliances with other vendors.

Connectivity As Competitive Advantage

Sometimes connectivity can be leveraged to gain competitive advantage. Point of care testing (POCT) startup EPOCAL is a great example. This company has apparently done an exemplary job in recognizing market requirements and formulating a design that maximizes connectivity features and capabilities, while minimizing development costs and time to market. If this new system is successful, established competitors will have to scramble to catch up.

CardioNet is another startup that leveraged connectivity from the get go.  The acquisition of ECG signals is pretty routine. The algorithms for analyzing ECGs are also well understood, but continues to yield occasional innovations. Besides superior ECG analysis algorithms, CardioNet implemented a near-continuous connection with a remote service center that wirelessly acquires and reviews patient ECG waveforms - during the diagnostic test. This continuous recording and analysis contrasts with conventional holter monitors that record a batch of heartbeats (typically 24 or 48 hours) that are read at the end of the study. This unique connectivity enabled workflow provides CardioNet with unique clinical capabilities that have resulted in much higher diagnostic confidence than conventional holters - and a sustained competitive advantage.

The Answer to the Ultimate Question About Connectivity

A new product is an answer to a problem. And for entrepreneurs, that answer is a product design - some novel way to solve the problem. You can't design something until you have requirements. For entrepreneurs, their focus on finding the answer to the customer problem results in a good understanding of requirements - so the overall design or answer to the customer's problem becomes self evident. Admittedly figuring out how to realize the answer, say determine the level of conscience sedation, can be more challenging.

Designing a new product or technology without adequate requirements is a common mistake. The resulting solution becomes a "solution in search of a problem." Commonly referred to as a "technology push," vendors frequently turn to consultants to help them figure out how to shoehorn their solution into the most attractive market problems. The end result is usually marginal (and it's no fun being put in a position to deliver bad news). The best time to bring in outside expertise is at the requirements stage, when changes to the solution or business model are easiest and least expensive.

When the question shifts to connectivity, the focus moves way beyond the scope of initial problem to be solved to questions about how the resulting device will be used and integrated into patient care. This shift of focus veers off into an area for which the start up has no requirements - and thus struggles with finding "the answer."

Much like solving the original problem with the innovative product design, finding an answer to the connectivity problem starts with asking the right questions. Many entrepreneurs, anxious to find the answer, start to make trade-off decisions before they have a handle on requirements or the scope for meeting those requirements.

The good news is that if you go about it the right way, solving the connectivity problem is relatively quick and easy. And the sooner you start, the less incremental work it represents.

Finding the Answer

The key to quickly zeroing in on your connectivity solution is to iterate.

  1. Start at a high level and capture the complete workflow that surrounds your product. Cast a wide net in order to define the entire landscape in which your product will exist. Don't worry about the details of every bit of workflow, just get the big picture.
  2. Compare the resulting workflow with your product's key value proposition - not just what it does, but what it means to the buyer and why they will buy it. For example, customers will not buy your POCT device because it allows them to do tests at the bedside. They'll buy because you offer a better (or the first practical) way to shorten length of stay, improve patient outcomes, and avoid unreimbursed "hospital acquired conditions."
  3. Discard the portions of your global workflow assessment that don't directly contribute to your key value propositions.
  4. Now dig in a bit more, and capture enough workflow information to consider some design options and get a feel for scope. Rank the resulting connectivity features by how well they support your key value propositions (this becomes your priority list).
  5. Evaluate the the resulting estimated scope of effort and development costs with your existing budget and time to market. Cut those items that rank lowest on your priority list. Depending on the relative gap between your priority list and the time and money available you can go one of two ways.
  6. Repeat steps 4 and 5 to winnow down your list of connectivity features further, or jump to the next step. There's a difference between workflow that does not contribute to your product's value, and workflow that does. You want avoid the former and do as much of the latter as you can. If you postpone developing essential connectivity features, be sure to create a well considered roadmap so you don't end up redesigning early connectivity features to accommodate later additions.
  7. Evaluate various design options for your list of connectivity features (that is, the entire roadmap). This process optimizes your implementation approaches for your connectivity features, ensuring the biggest bang for the buck and shortest time to market. Options include build it yourself, subcontract, or license technology. There are some innovative new "best practices" that are greatly reducing both time to market and total cost for some connectivity features. Your options also include business development and alliances with other vendors.
  8. You may need to repeat steps 4, 5 and 7 again.
  9. When you've balanced your ability to help the customer justify their purchase of your solution (the connectivity features) against available schedule and budget, start your PDP (product development process) by documenting your requirements. You should complete requirements documents for connectivity capabilities you build, buy or get through bus dev and alliances.

If you're in a hurry, you should be able to go through the above process in 1 to 3 weeks (not including travel time, review cycles, delays scheduling meetings, etc.). If you're not in a hurry because you didn't wait til the last minute, or connectivity is a major focus for your product - like EPOCAL - complete this process in sync with the product's development cycle.

With the core technology of your product, many of the solutions to feasibility and productization challenges seem self evident in hindsight. This hindsight is the result of knowing now what you didn't know at the beginning. With connectivity, remember that you don't know what you don't know. Nor do you really want to gain that knowledge through hindsight, since connectivity has been figured out before. There's little or no value to be gained in reinventing this wheel, and besides, you've got a product to launch.

There are many ways to skin the connectivity cat, so be sure to look beyond what your direct competitors are doing. Besides, what your competitors are doing could be wrong.

Common Connectivity Applications

Connectivity is workflow automation through the integration of the medical device and information systems. Here's a quick survey of the most common types of workflow automation for medical devices.

Research

In some ways, this may be the most important connectivity application for innovative medical devices. First let's start with how research benefits the vendor. The more novel a new medical device, the greater the need to verify specifications, validate the intended use and demonstrate the claimed benefits. This process starts in the feasibility phase and only increases as the product is launched. Peer reviewed studies are highly sought after to justify buying the product. The sooner a start up has "clinical evidence" - published studies - the faster sales will increase.

How does making research easier benefit buyers? The greater the level of innovation in a new product, the more likely that early adopters will be researchers and teaching hospitals. Many of these guys and gals live by their research. Think for a minute about what big pharma does to facilitate research for their clinicians, and contrast that with what medical device vendors provide. Pretty sad, isn't it? Now imagine a luminary physician looking at a new medical device that's not only way cool and new on the market, but comes with everything needed to capture and analyze data.

When phasing in connectivity features, this may be a good place to start. This basic connectivity and support for research can be extended to multi-site  studies, and post market surveillance of the device. With a bit more work remote diagnostics, service and even uploading new firmware are possible - operational efficiencies rarely available to a start up.

Device Use - Operational Workflows

Connectivity features really start with the automation of these basic activities that represent the workflow most closely associated with the operation of the device. Get these requirements right, and you've added considerable value to your product and laid a good foundation for additional connectivity down the road. Get these basics wrong (or skip them) and your ability to meet connectivity requirements is greatly impaired.

Medical devices typically aren't used without a physician's order, configuration of the device, and the necessary documentation. These are the basic  workflows essential to the operation of the device.

These workflows include establishing patient context where data generated by the device is associated with the correct patient. Patient context frequently includes capturing the caregiver and device identification.

Device configuration is manual for most devices, although many devices capture and log how the device is configured. The market is slowly moving to interoperability, an initial application has an order automatically configure the device. This may occur first with smart pumps. In the absence of industry standards, this interoperability will represent a significant new barrier to entry for start ups.

Documentation is an essential activity related to device use. Diagnostic devices must document their results - ideally to a signed final report; monitoring and therapeutic devices must document a variety of things as they occur (alarms, start/stop of therapy) and on a periodic basis (like vital signs).

As EMRs and paperless charting proliferates, the requirement to automate these basic operations increases. In fact, in some market segments this level of connectivity is a standard feature for all mainstream products.

Data Analysis

Connectivity is an attractive avenue for implementing some medical device features because writing software for a general purpose computing platform is frequently quicker than developing it for an embedded system. Also software engineers experienced with general purpose computing platforms are much more prevalent than embedded systems software engineers.

Most data analysis fundamental to the medical device occurs in the embedded system. Sometimes optional features, like arrhythmia analysis, are implemented on general purpose computing platforms using connectivity, rather than in the embedded system itself. There is also a meta level of data analysis related to most medical devices.

The workflow that supports the use many devices includes trending data over an extended period of time - the entire length of stay, or even multiple episodes of care for frequent fliers. Preferences for which variables are trended, and over what periods of time vary by patient and clinician. And trending only tells part of the story.

Many clinicians want to "look back in time" to see the retrospective data generated earlier in the shift or over the weekend. Accessing this data is frequently done by events like alarms or the start/cessation of therapies. Because the data management capabilities in embedded systems are limited, these features are implemented on general purpose computing platforms.

Another key reason for moving data analysis off the embedded device is when the data comes from multiple devices. Many patient safety and outcomes features require retrospective data from all the patients in a unit or institution. Implementing this on an embedded devices would be most impractical.

Visualization

Visualization is really another category of data analysis, except the data is displayed visually like in diagnostic imaging or with tools like calipers for ECG analysis. Like data analysis, essential visualization of  data produced by the medical device is done on the device itself.

Depending on the analysis and visualization requirements, processing power and/or display size and resolution may make implementation on the embedded device too expensive. Secondary visualization techniques such as alternative ways of looking at the patient's data, visualization of retrospective data, or visualization tools packaged as options are frequently implemented off the embedded device using connectivity.

Alarm and Alert Notification

This category entails both life critical alarms and lower priority alerts, and can be sent to caregivers or clinicians. Both patient monitors and acute therapy delivery devices require effective alarm notification. Conventional alarm notification - local alarms or central stations - frequently result in alarm fatigue and failure to rescue. Simply generating a local alarm is the bare minimum required for acute conditions. It is possible to include innovative alarm notification capabilities into a new product offering without a huge impact on time to market or R&D budgets.

Innovative new medical devices frequently produce data that can greatly impact the quality of care and patient outcomes. To achieve this worthy goal, the data must be actionable - meaning the data must get to the individual who is best able to take the action that will result in an improved outcome. Facilitating the process of getting that alert to the right person and making it easy to implement and use is critical to driving market adoption of an innovative solution. Remember, providers want solutions, not tools that they have to forge into solutions themselves.

Surveillance

Many medical device use scenarios benefit from the display of device data separte from the device itself. Miniaturized devices with small displays can benefit from larger secondary displays right at the point of care. These displays can also serve as user interface devices through the use of touch screens. Surveillance beyond the point of care is also a frequent requirement, especially in patient care areas where caregivers are not always at the bedside.

Many health care actors removed from the immediate delivery of care have an interest in device generated data. Whether pharmacists and infusion pumps or busy caregivers and patient monitors,the ability to see a summary of device data - or a representation of the actual display - can greatly impact the use and performance of a medical device.

Event Review

Data generated by the medical device, in full resolution and fidelity, can be valuable long after the data has scrolled off the screen. This data, frequently displayed as waveforms, is used to review a patient's changing condition over time. Events are typically used as markers to quickly find clinically relevant data.

To provide this capability on the embedded device would require transforming the device into a general purpose computer - an expensive and time consuming option. This data is frequently reviewed away from the point of care, and there is frequently a requirement to view this data in remote locations via personal computers or smart phones.

Quality Assurance

Many diagnostic systems require some sort of quality assurance activity. To the extend that this can be automated, the adoption and use of the device is greatly enhanced.

These types of applications are very specific to the device in question, and connectivity best practices play a major role in time to market, development cost, and customer satisfaction.

Remember, it's not the nuts and bolts of connectivity that's critical to product success, but the features and workflow automation that result from connectivity.

A Word About Connectivity Design Solutions

Connectivity is challenging. It is not easy to do and can be expensive and time consuming to implement. In market segments where connectivity is new, prospective buyers can't articulate requirements for something they've never done before. Nor do buyers want to pay a premium for connectivity, although they will pay a premium for clinical applications enabled by connectivity.

Despite all this, connectivity has a major influence in a solution's usability and customer satisfaction - key success factors for adoption. Connectivity has played a major role in the success of companies like Alaris, Abbott Precision, CardioNet and others.

Design options for connectivity are changing rapidly. Architectures, technologies and methods that were standard just a couple years ago, have been superseded by new approaches with shorter times to market and lower development costs. Workflow automation that once required a dedicated server can now be implemented on silicon and embedded into the medical device. Open source software is also impacting connectivity.

Proprietary communications protocols add significant costs and time to market for the systems that incorporate that connectivity.  In the near total absence of standards for medical devices (outside diagnostic imaging and DICOM) implementing connectivity with other vendor's systems is difficult, a situation that greatly advantages large established vendors. The approach to communications protocols is changing right along with connectivity design approaches.

There you have it, a partial answer to the ultimate question about connectivity - specifically for startups.