Medical Connectivity » Business Planning

Market Trends Series #3: Shift from Dept to Enterprise Focus

Brian McAlpine — Wed, 04 Nov 2009 00:32:52 +0000

From what I have observed over many years, Hospitals have historically approached medical device connectivity projects as a tactical issue to be dealt with. Up until relatively recently, technology alone could be used to solve the connectivity issue (i.e. getting data from point A to point B) with little to no negative impact on clinical workflow. Further, the scope of connectivity projects has been mainly departmentally focused and deployments have been relatively basic. By basic, I refer to projects that have focused on connecting one or two bedside medical devices to a single CIS application or EMR.

Evidence of all of this can be found by looking back at the past 10 or more years and examining typical implementations of biomedical device connectivity to information systems.

• Most implementations up to now have been in very specific care areas such as the ICU and OR.

• Most implementations are relatively small in scope, often in the area of about 20 to 50 beds. Incidentally, for most US hospitals this happens to be about the same number of ICU beds per facility.

• In the ICU, the key devices that are interfaced are typically multi-parameter patient monitors and sometimes ventilators - but vents to a much lesser degree than monitors.

• In the OR, the key devices are typically patient monitors and anesthesia/gas machines.

• Outside of high-acuity care areas, in the general ward there are some limited niche interface solutions for mobile vital signs data capture. Many of these are only semi-automated in terms of truly automating both the data capture and the clinical workflow.

• For virtually all of these implementations, the data collected from the devices is identified though a mapping of the medical device’s location – that is a bed or room location identifier is used to associate the data and alarms.

• The device workflow - that is the steps clinicians are required to perform at the bedside to interact with devices to establish connectivity – has been limited. This is because most of the devices are actually fixed to the location – i.e. the monitors in ICU are mounted to the wall and data is interface via a networked gateway with outbound HL7. Therefore few if any steps are required by clinicians because the devices are permanently tethered to a local PC or terminal server that facilitates the data collection.

But as discussed in some of my previous market trends postings – requirements for connectivity have been changing and in some not so subtle ways. Many hospitals are (more…)

Medical Device Open Source Frameworks

John Zaleski — Thu, 16 Apr 2009 18:37:52 +0000

The Big Picture

Medical device interoperability and standardization is a hot topic, and with the efforts surrounding adoption of the 11073 standard, IHE and patient care device frameworks, and the drive towards implementing electronic medical records, the field has become essential to the future of the healthcare industry. Yet, as we look to realign medical devices and their communication mechanisms away from proprietary intercommunication and towards standards-based communication, we should think “outside the box” to other fields, technologies and technical disciplines for inspiration and guidance on best practices. Perhaps an obvious one that comes to mind is the USB 2.0 standard. The simple idea being proffered is the ability to plug a medical device into a computing platform and have it recognized and joined automatically to the operating system. While we are a long way from this vision as a universal standard, there is ample evidence to demonstrate its feasibility in the existing Windows and MAC OS architectures today.

Driver Bundling

Key to the seamless and universal use and acceptance of USB devices is the bundling of device drivers delivered as part of base operating systems. When a new device is developed, it could be adopted for incorporation within the base Windows and Mac operating system environments. However, even before that adoption, manufacturers of these drivers could consider bundling them as part of hardware delivery. The drivers could be installed at run time or prior to usage and, from there, no other special attention would be required: attaching a medical device to an accompanying computing platform would automatically result in that device “joining” with the base operating system. The challenge, of course, is how best to develop drivers that support consistent and common access to data. While the common Patient Care Device (PCD) framework fosters such an idea, it has yet to be realized as a universal standard.

One theme embodied by the IHE medical device connectivity demonstrations featured at HIMSS 09 (pdf) in Chicago was that of following a patient from admission through a critical care room, in which patient information was gathered at the bedside from and to the various medical devices present there, including infusion, bed, monitor, and mechanical ventilation. The ability to collect and integrate these data into a bedside electronic health record was accomplished in concert among the several medical device manufacturers through access to the communication frameworks peculiar to the many vendors participating in the demonstration. The bundling of device drivers and publishing of a common syntax required to communicate with the various devices could provide a starting point for enabling universal biomedical device communication.

(more…)

Facing FDA Regulations for the First Time

Tim Gee — Sat, 14 Mar 2009 00:53:03 +0000

A growing number of organizations — large and small, within health care and outside of it — are facing regulation by the FDA. Those potentially affected fall into 3 camps. All of the examples I’m going to talk about deal with multi vendor systems (or systems using lots of off the shelf components) that become the regulated medical device.

Just what is a medical device? The legal definition of a medical device is,

an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a component part, or accessory which is:

recognized in the official National Formulary, or the United States Pharmacopoeia, or any supplement to them, [i.e., a drug]

intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals, or

intended to affect the structure or any function of the body of man or other animals, and which does not achieve any of it’s primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of any of its primary intended purposes.

According to the New Oxford American Dictionary, a contrivance is “a thing that is created skillfully and inventively to serve a particular purpose.” So a medical device can be made out of anything, as long as it falls under at least one of the three bullets above.

Who Is Impacted?

(more…)

Requirements, Trade-offs and Sales Objections

Tim Gee — Tue, 10 Mar 2009 18:20:21 +0000

This is another installment of a series on selling connectivity. You can read the first installment, with links to subsequent posts, here.

There is no one product that best fits every customer’s requirements, yet the goal of product management is to develop product requirements that addresses the greatest portion of the market possible. Of course, it is neigh impossible to create a solution that is optimal for every customer. This raises a couple interesting questions. For any given project, how much of the addressable market’s requirements can be met? How are such trade-offs made, and what is the role of sales in all this?

Security As a Requirements Trade-off Example

A good frame of reference for requirements trade-offs is wireless security for medical devices. There is a plethora of security standards, and the target is always moving; new standards are implemented, some of which have varying degrees of reverse compatibility with previous generations of hardware, and some require upgrades or replacements to work. Likewise, different markets have different requirements. For example health care has HIPAA, the credit card industry has the PCI data security standard, and other industries have their own requirements. Next, individual customers make security choices based on the infrastructure installed, how current their infrastructure is (is it currently sold by the vendor, is no longer sold but still supported, or is it discontinued), and what security standards they chose to adopt and enforce (sometimes chosen capriciously, often enforced vociferously) in their enterprise.

Like the workflow automation that wireless connectivity enables and the necessary security required to support it, there is a finite degree of requirements variability that can be practically implemented — systems can’t be everything to everyone. Creating a product that address 100 percent of the target market is virtually impossible. Trade-offs must be made so that a product can also reach cost of goods, design budget and time to market objectives. (more…)

Interoperability - Barriers to Adoption

Tim Gee — Fri, 31 Oct 2008 19:50:25 +0000

There’s been some great comments on the recent post about the announcement of MD FIRE. That plus some other activities I’ve been involved in have inspired some thoughts on barriers to adoption for medical device interoperability.

For this discussion, interoperability refers to the ability of a medical device to be controlled by another medical device or third party information system. Medical device systems from a single vendor frequently include interoperability between the medical devices and applications running on general purpose computers, but since all the components are from the same vendor I’m excluding them from this discussion.

Like everything else, medical device interoperability will walk before it runs. In a recent comment, JimW suggests that MD FIRE’s focus is on driving the adoption of, “tightly coupled, low latency, deterministic connection[s].” I beg to differ; I found the MD FIRE text to be very general and that it avoided any kind of design solution whatsoever. Further, it is interesting that what little multi vendor interoperability that is actually on the market, is based on “tightly coupled, low latency, deterministic connection[s].” The example that comes to mind (actually the only one I can think of right now) is the use of CANopen to integrate radiographic equipment with contrast injectors in diagnostic imaging. Perhaps someone can provide additional examples.

Jim is right that such interoperability presents considerable product design and verification challenges, which is why I think that a different kind of interoperability will broad gain market traction before designs with tightly coupled deterministic connections. If you’ve heard Julian Goldman speak on this topic, he provides numerous examples of interoperability that revolve around simple safety interlocks like:

Using a patient monitor to cease therapy delivery (and sound an alarm, of course) on a PCA pump when respiratory arrest is detected,
Linking a heart lung machine and ventilator in surgery to ensure that one is turned on when the other is turned off, and
Linking diagnostic imaging with a ventilator to ensure ventlation is restarted after it is stopped to reduce motion artifact during imaging.

A portion of the 500 patients who die unnecessary deaths every day in U.S. hospitals are killed because simple safety interlocks like these don’t exist. Why? Clearly such interoperability is not rocket science.

(more…)

Healthcare Unbound 2008

Tim Gee — Sat, 12 Jul 2008 00:25:41 +0000

This week was the Healthcare Unbound conference. Between the considerable innovation in this market, and the openness with which presenters and attendees share information and ideas, this is always a terrific conference.

The following are some notes from some of the more interesting presentations - be sure to keep scrolling, this is a long post! I’ll follow this up with a post on my presentation at this year’s conference, “How the Network Effect Impacts Adoption of Healthcare Unbound Technologies,” and a wrap-up post.

At 8 am Monday morning, Teri Louden kicked things off. She started her career at Baxter Travenol in the 1970s. Referring to The Graduate, Baxter’s innovative technology of the day was plastic IV bags. Today, things have come a long way from plastics to Healthcare Unbound.

There have been few breakthrough industry segments over time - disease management, home infusion therapy, outpatient surgery - and Healthcare Unbound (HU) is an important pioneering new industry segment.

Teri prognosticated that many of the really breakthrough solutions in health care will come from companies outside of health care - mentioning Intel, Qualcomm, and other electronics and communications companies.

Using CardioNet as an example, Teri described how a new type of solution presents substantive challenges for adoption and effective use. The CardioNet value proposition was unique and required new ways of selling, patient use, and reimbursement.

She introduced Vince Kuraitis and David Kibble, and their topic: The Personal Health Information Network (PHIN): Opportunities and Implications for Healthcare Unbound

The Personal Health Information Network (PHIN): Opportunities and Implications for Healthcare Unbound

Vince introduced the topic with a classic example of the network effect, phones. He asked, what is the value of a single phone? The health care industry is currently the equivalent of two phones representing one to one solutions. The real value comes to the fore when many phones are interconnected, allowing users to contact many other users whenever they want. (more…)

Medical Device Start Ups and Connectivity

Tim Gee — Tue, 24 Jun 2008 17:57:40 +0000

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. (more…)

Selling Connectivity - Sales Strategy

Tim Gee — Fri, 23 May 2008 17:18:50 +0000

Selling anything starts getting serious when it comes to qualification. For you non-sales types, qualification is an assessment of the likelihood of making the prospective sale. This assessment includes the following basic questions:

Is the potential buyer or prospect really going to buy anything - from anybody?
Will my product be a serious contender for the sale, or am I simply cannon fodder to help justify a sales process with a foregone conclusion?
And if I am a serious contender, how does my product match up against the competition relative to the specific needs of this prospect?
Who all is involved in making the decision of what to buy? (More on this in a future post on Selling Connectivity)

A common problem in markets where connectivity is new or dramatically innovative is avoiding prospects who are more interested in being educated than really buying anything. In situations like this, sales reps can get appointments to talk to prospective buyers very easily because they all hope to learn something interesting. The problem is that few of these prospects intend to buy anything, thus taking valuable time away from actually selling stuff.

Sales Strategy

The solution to this problem is an effective sales strategy. A sales strategy is like a cook book recipe that details precise steps that result in a successful sale and satisfied customer. A good sales strategy describes the quickest and most reliable process for starting with a prospect and winning the sale. Effectively selling connectivity and overcoming the qualification challenge requires a good sales strategy. (more…)

Selling Connectivity - New Knowledge

Tim Gee — Wed, 30 Apr 2008 17:57:20 +0000

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: (more…)

Selling Connectivity - A Series

Tim Gee — Thu, 17 Apr 2008 02:40:57 +0000

I’ve written much in the past about the technical and product development issues of connectivity. Just as important are the issues that revolve around successfully selling your connectivity solution. (If you’re a provider reading this, this should provide a bit of insight into how to buy connectivity, and why sometimes vendors to the crazy things they do.)

You can place two seemingly identical medical devices side by side, with the only visible difference being that one has an Ethernet connector and the other does not. That “small” change makes a world of difference when it comes to selling these two devices. Here’s my list of the areas where adding connectivity to a medical device changes almost everything:

Required new knowledge
Qualifying prospects
Dealing with new decision makers (typically with veto power)
Selling a solution, rather than selling the box
Selling one-off systems, rather than cookie cutter widgets
Aligning incentives
Making it work, getting paid
Keeping the customer happy, keeping the system working
Customers want a whole product solution

(more…)