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
The recent recall (links below) for McKesson’s Anesthesia Care system raises interesting questions about potential information system failure modes as well as what system/software functions cross the imaginary line between unregulated EHRs and regulated medical devices.
First the facts. The FDA announced McKesson’s voluntary recall of its Anesthesia Care system in several on-line (here, here and here) postings. This trio of postings is interesting because the first links only to the second, the second does not link to either of the other two. The third also does not link to the other two, and was not part of any of the announcements, but it is the most complete.
The statement of the reason for the recall is that, “There was an occurrence where the patient case data did not match the patient data when the case was recalled in the anesthesia care record (ACR) in that it included data from another case.” It was further noted that, “Use of this affected product may cause serious adverse health consequences, including death.” In the third link the FDA identifies the product as,Read More
The HIMSS conference is so big, with so many different kinds of attendees and exhibitors that it’s almost impossible to have one big theme for any given year. Yet the question of theme for any given HIMSS is something we all talk about. The themes one perceives are at least partially defined by our own interests and area of focus. Consequently, the #HIMSS14 themes for me were:
- The shifting product and value proposition focus of many of the vendors I track,
- The tension between spot solutions and enterprise solutions, and
- The big buzz word of the show, population health.
Two of the market segments that I track with big shifts in value proposition were medical device data systems (MDDS) and messaging middleware. We’ll talk about specific shifts in a moment, but I think it worthwhile to consider why this change in value propositions has occurred. One obvious factor among MDDS vendors is acquisitions. Capsule Tech (registration required), Accent on Integration and iSirona have all been acquired. Acquisitions are major events when everything about a company is reevaluated in an effort to wring greater value from the acquired company. The other factor I think is the growing adoption of MDDS for clinical documentation into EMRs may have caused sales growth to temper a bit, causing vendors to look beyond clinical documentation and explore for ways to add value and differentiate. Let’s look at some examples.Read More
I wrote in the beginning of 2012 that perhaps that year was the year for mHealth to ‘breakout. ‘ I cited several proclamations and organizational activities to support that claim. mHealth and the use of remote monitoring as an integrated healthcare offering is still not as prevalent as one would think it would be two years later. Even in the Telemedicine & E-Health LinkedIn Group, one sees angst at the low adoption rate of the use of telehealth solutions. Inevitably, when I speak with my colleagues and other people involved in healthcare, economic and clinical effectiveness questions prevail. Two specific conversations I had with clinicians stand out. In one, the cardiologist had not seen enough evidence that the quality of care and cost would justify a large addition or change to the existing healthcare offerings. In another, the clinician reminded me that with chronic diseases, one is attempting to get patients to change their behavior, which is very difficult, regardless of any technology involved.
With the above in mind, I’d like to offer the following results from the Renewing Health (RH) project in Europe, a randomized control trial which endeavored to compare the use of remote monitoring technologies and workflows with traditional workflows in the management of chronic disease in both economic and clinical terms. While the final results of the whole study are due out this summer, Veneto, Italy, has presented their findings for congestive heart failure (CHF) and they are fairly impressive.Read More
Introduced in the House back in October was the wittily named Sensible Oversight for Technology which Advances Regulatory Efficiency Act of 2013 which has the acronym SOFTWARE. Not to be outdone on the creation of legislative acronyms, now comes the Senate version with a bill entitled Preventing Regulatory Overreach To Enhance Care Technology, which of course gives us PROTECT. Both of these bills seek to define and sub-define medically related software, and then to take part of what they have defined away from the FDA, and do something else with it that has not yet been clearly identified.
The premise of these bills is that the FDA inhibits entrepreneurs by peskily requiring, at least in some cases, that the developer meet regulations that are supposed to provide some measure of safety and efficacy before these products are used for or by the public. These issues arise in part because the definition of a medical device does not explicitly include or exclude software. This has allowed the occasional debate about whether and what kind of software is or is not a medical device. The FDA’s position is to simply look at the function of the software and the definition, and then to say that if what the software does meets the definition then it is a medical device. Debating this with the FDA is typically not a fruitful endeavor. Some other countries have explicitly included software, presumably to try to end the discussion. For example the UK explicitly includes “software” in its list of the multiple categories of things that may be a medical device.Read More