My first exposure to Mobisante and their disruptive diagnostic ultrasound system was the mHealth Summit in November of 2010. At that time, the consumerization of medical devices had been gaining traction, mostly in the physician office market. Consumerization offers medical device manufacturers advantages in lower design costs, shorter time-to-market, lower product costs, increased usability and lower training costs.

I recently got Sailesh Chutani, co-founder and CEO of Mobisante, on the phone and we discussed their product strategy — a software based diagnostic ultrasound that runs on a variety of consumer electronics platforms.

Your product is clearly a diagnostic ultrasound medical device, but one can’t help but notice the rather unique design and choice of components. What were the factors driving the eventual design and appearance of your diagnostic ultrasound?

Developing and launching a competitive product, and getting initial traction in the market are not inconsiderable milestones. And yet for the entrepreneur and their investors, this is just the beginning. What was record setting last quarter is barely acceptable this quarter, and next quarter had better be back on track.

Developing a solid plan for growth depends on two things: a good understanding of the basic means to drive growth, and a deep understanding of the market. This post seeks to combine both of these in a brief survey of the key factors to drive messaging middleware revenue growth in health care. We’re going to consider three basic growth strategies: organic growth, product line extension, and the roll-up strategy.

I was listening today to the CE-IT Webinar on CE and HIT from the 2014 AAMI conference in Philadelphia. Much of the session reviewed what has happened over the last five years and it got me thinking about my experiences and what I’ve seen over the last ten years in medical device connectivity and remote monitoring. It’s been an interesting ride and yet I realize there are a few basic ideas that have resonated over the years. These basic ideas are:

Specifying those requirements that are unique to my situation are where I have the most control in acquisition;

There are other players in the market who may change the landscape of what is available to me; and,

The previous post in this series suggested a set of characteristics to define the messaging middleware market and described the typical product architecture for these systems. In this post, we’ll look at ways the market may be segmented and how the market is adopting these systems.

Market Segmentation

Market segmentation is the dividing of a broader market into subsets of potential buyers who have common market requirements who then become the target for your product, sales and marketing. Using my favorite market adoption model, Geoffrey Moore’s Crossing the Chasm, this is the bowling alley strategy. Software developers in the messaging middleware market are currently pursuing a variety of market segments or bowling alleys.

What do secure communications, care team coordination, patient engagement various workflow automation solutions and alarm notification have in common? They’re all examples of messaging middleware solutions found in health care. Which begs the question, what the heck is messaging middleware? This label is a term of art that was first coined by Emergin in the early to mid 2000s. As the name of a product category, it’s descriptive of the underlying technical functions of the product, but has nothing to with how the products are actually used – which can vary considerably.

All of this said, the term messaging middleware is terrible because it’s too generic and the term middleware usually doesn’t mean anything to people outside of IT. A survey of the market shows that many companies are avoiding messaging middleware and using words that describe their product in terms of their target market segment – secure messaging and alarm notification as two examples. In this series of blog posts, the terms messaging middleware, secure messaging, and messaging applications are used pretty much interchangeably.

What Is Messaging Middleware?

Messaging middleware provides integration with and transport for data or communications between users, applications and medical devices. The data streams between these entities are mediated by software to orchestrate secure message flow, message payload and can even generate new messages based on the content of data streams. These systems also provide closed-loop communications where the transmission, reception, reading and response of a message is tracked, with messages resent or redirected (i.e., escalated) in response to a variety of possible delivery failures. All of this communications is recorded and logged in a database to provide management information and big data analytics opportunities. Messages sent to or from users typically entail some sort of mobile device, a wireless voice over IP handset or smartphone running a client app. Such systems also have web based clients that can be accessed on PCs for users to both send and receive messages. These systems can include a number of common features:

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: