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:
- 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 a message 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 enterprise-class 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.
How is this different from a typical Service Oriented Architecture (SOA) / Enterprise Service Bus (ESB) architecture? It seems that the “engine” itself goes on top of it rather than within the SOA/ERB? My perspective is that SOA itself will have the graphical user layer and the business logic layer that pulls all the services together. What does the SOA/ERB on your diagram do? What is the purpose of the “engines”? The architecture seems redundant. Thanks.
Raphael, the architectural representation with this post is a very high level example of an imaginary system, not an actual product. Some of messaging middleware systems don’t include a rules engine and only rely on SOA/ESB services, while some also incorporate a rules engine. In general SOA/ESB services tend to be used to support the logic of message flow, while rules engines are looking at data in other data streams or message content.
Excellent post, as usual - and some interesting insight. Your point about reducing human resource costs for development dovetails with my conversation with a telehealth designer who stated he would eliminate human processing of information as much as possible, relying upon the engines gathering the data and the rules applied to that data - he said that the manning of the telehealth center was 40% of the cost.
So as we saw in the hospital, the reduction of staff monitoring central stations on the floor to a centralized area, with concomitant reduction in staff in the centralized area by relying upon rules, similar ideas are being promulgated in the management and communication of healthcare data. And, all of this is relying upon the information technology (telecommunications, hardware and software) infrastructure. Sometimes I wonder if we trust too much 🙂
Thank you for this excellent summary of this market. I’ve been thinking of “messaging middleware” as you describe it, but from the perspective of the beneficial end-users, i.e., the clinicians I’ve led or more recently supported the middleware is or ought be invisible-their interest is the information and device usability.
The challenge I’ve confronted is that IT enterprises like to have “messaging middleware” so invisible it doesn’t exist because they still see nothing wrong with siloing clinical information and human-to-human synchronous and asynchronous communication. From my perspective as clinical leader integrating the clinical information and the communication about it into a single channel is less a technical challenge than culture shift challenge.
I’m glad to have found your blog (HT Alexa Condurso of PatientSafe Solutions) and I look forward to reading your future posts.