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.Read More
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 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.Read More
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:Read More
Challenges with alarm notification and fatigue have plagued the health care industry for decades. Long before alarm notification systems like Emergin (now Philips IntelliSpace Event Management) and GlobeStar Systems (ConnexAll) appeared, some hospitals addressed alarm issues with the original alarm notification system, monitoring techs. Monitoring techs remain an accepted and effective tool in the constant battle to reduce alarm fatigue and avoid failure-to-rescue events.
With the growing adoption of electronic alarm notification systems, is there still a role for monitoring techs? Are electronic alarm notification systems superior to flesh and bone monitoring techs? This blog post will explore monitoring techs as a solution and consider whether they might be a compliment to an alarm notification system, or whether an alarm notification system should take the place of monitor techs.Read More
One of my favorite Clinical Engineers called today, prompted by last week’s post on the Emergin acquisition by Philips. Like many that I’ve talked to, this person was surprised that Emergin was not snapped up sooner. A list of potential bidders were mentioned, but my lips were sealed. I will say this about potential suitors for Emergin – the lines are blurring between conventional categories of vendors, on both the health care IT and device sides.
Also discussed were two continuing problems with medical device connectivity, alarm notification and point of care automation (we’ll just call it “middleware” for this post). The first deals with hidden costs – on both the device side and infrastructure side. As you work through the details of plumbing everything together, you tend to uncover situations where to get feature X you have to upgrade your medical device system to version Y. If this happens more than a time or two, the cost of your upgrades quickly eclipses the cost of your middleware.
On the infrastructure side few enterprise networks, wired or wireless, were designed to support the life critical applications of medical devices. Providing surveillance and alarm notification are more than mission critical, and require proper management, monitoring and documentation. Historically, device vendors installed their own physically separate networks so these issues were not apparent to hospital IT departments (and IT departments didn’t mess up device vendor’s networks).
Medical devices are becoming enterprise applications, and no longer justify isolated networks. Hospitals looking to benefit from the features of a system like Emergin’s are looking at rejiggering and upgrading their network (and maybe a lot more). So after you’ve upgraded your medical device systems and network, your total middleware costs have perhaps tripled from original estimates. Ouch.
Medical device vendors continue to push device integration issues off on hospitals. Sure they’ll install a server and manage it (apply upgrades, diagnose problems and get it running again when needed), but they won’t take any responsibility for the actual operation of device connectivity. What clinical engineers need is a software app that actually monitors medical device connectivity and interoperability – sort of like an HP OpenView for medical devices.
As things stand, the biomeds responsible for medical device integration can’t even tell if a disconnected serial cable is the cause of an interruption in data from a medical device. This is way outside the core competencies of medical device vendors. But there are solutions to this kind of problem, Nuvon for one. Presently hospitals are left to their own devices to solve this problem, unless they know to insist that device vendors fill this gap.
Most alarm notification, point of care automation and medical device connectivity solutions continue to be difficult to buy solutions, mainly because everything out there is a partial solution, with gaps and overlap everywhere. In marketing-speak, this is still an early adopter market. The early majority of the market is sitting on the sidelines until someone can field a whole product solution.
Pictured right is Smiths Medical’s Cadd System Pro meds administration software.Read More