Secure Messaging Middleware Market Defined

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.

Contents

What Is Messaging Middleware?
Product Architecture
Other Posts on Messaging Middleware

All of this said, the term messaging middleware is terrible because it’s too generic and the term middleware 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:

Secure communications between message senders and receivers (both messages originated and sent by users, and messages generated by the messaging middleware system itself or other external systems), that can include support for multimedia attachments
Systems integration via HL7, Active Directory, LDAP, SIP, TAP, SMPP, SMTP, proprietary medical device interfaces and web services, communications with EHRs, nurse call, medical devices, phone switches, etc.
User directories that span multiple enterprises to enable communications across a health care community
Role based messaging where messages are sent to a role such as a particular patient’s caregiver or the phlebotomist covering a particular nursing unit rather than a specific individual or device
Message escalation resends the message to a predefined user or role in the event of failure of the message to be received or acted upon within a preconfigured time frame
The assembly of contextual data that is automatically sent with the message, such as relevant clinical data sent with a medical device alarm or a message sent to a clinician or team of clinicians like a rapid response team
Predefined or canned message replies that can be sent with a message to speed replies to speed response or automate workflow
Rules engine for clinical decision support or to automate workflows

In the IT world, middleware or messaging middleware (messaging-oriented middleware) refers to infrastructure that enables applications; in health care, messaging middleware is the application. How these messaging applications are positioned and sold – and the kind of additional features used to differentiate and provide a competitive advantage – are quite varied. Examples of messaging middleware applications include secure physician-to-physician and physician-to-caregiver communications, physician- or hospital-to-patient communications (appointment reminders, prescription adherence), workflow automation applications (patient transport, bed management, rounding, prescription refills, etc.), alarm notification, and mass notification systems to name just a few.

Product Architecture

All of these seemingly quite different applications can be implemented using the same basic product architecture. This architecture is made up of a number of highly configurable modules that are integrated and configured (via scripting and tables) to accomplish specific tasks. These modules, or software engines are very powerful, and an integrated constellation of these engines can provide very sophisticated capabilities. Not all of the solutions in this product category include all of the components noted in the diagram, and there are often qualitative differences between the different software engines included in a particular vendor’s solution. There are also key features in some vendor’s systems that are not included in this diagram (e.g., physician or staff scheduling).

The reasons for this shift to highly configurable software engines to replace purpose written source code are many. One fundamental shift is the considerable reduction in the scope of source code development and an increase in configuration as the primary means to define software functionality. Now, rather than having software engineers coding specific product features and workflows, engineers work on the basic enabling capabilities of the software engines. The task of implementing features and workflows for users can now be done by application specialists who tend to have direct work experience with those clinical workflows as nurses and techs. And besides having a vastly improved grasp of user requirements than engineers, application specialists are currently a less expensive human resource.

Another important consequence of this new product architecture is a substantially reduced time to market and associated reduced product development costs. A team of a dozen engineers would need 3 to 5 years or more to write source code from scratch to implement a basic messaging middleware system. Using engines, a half dozen engineers and a few clinician application specialists can launch a very competitive product in 18 months.