In this post we will delve into a growing enterprise software category, health care messaging orchestration or clinical communications and collaboration, consider the underlying technology, and explore the ways this technology is being developed and applied in health care.

System of Action

A system of action provides the right information, at the right time, in the right format, to the right user(s). As a near real-time information system, systems of action are optimized for quick use by mobile users, rather than waiting for clinicians, caregivers, techs, and even patients, to return to their computers to interact with a conventional enterprise application.

This system of action represents a new class of enterprise software emerging in health care. Let's call this class of software messaging and orchestration systems (M&O). These systems are also referred to as clinical communications and collaboration systems. Lesser capable systems are simply called secure messaging systems.

Both Qventus and TigerText have used this term, systems of action. A system of action is in contrast to systems of record, like EMRs, that offer a retrospective and abstracted or condensed view of a patient encounter, and systems of display that provide retrospective analytics and dashboard displays.

A system of action is much like what Gartner describes as real-time health system (RTHS) technology. The objective of a RTHS is providing the right information, at the right time, in the right format, to the right user(s). In a RTHS, systems are designed to sense the need for a change in process, operations or strategy. Gartner attributes the following characteristics to a RTHS:

  • Aware — a RTHS utilizes situational awareness and generates context-sensitive information
  • Adaptive — a RTHS is more proactive (anticipate and predict) than reactive
  • Collaborative — a RTHS uses a conversational user interface to engage clinicians, staff and patients within or across healthcare organizations.
  • Mobile — a RTHS optimizes workflow and timely access to patient information.
  • Demanding — a RTHS demands very high service levels, better user experience, high availability, and is ideal for mobile or remote users

While these 5 attributes apply to the M&O systems under discussion here, Messaging & orchestration systems are only one of numerous types of RTHS applications identified by Gartner.

Currently, M&O systems support a variety of different use cases. A few examples of these use cases include clinical communications and collaboration, patient engagement, care management, patient flow, and medical device alarm notification. The full spectrum of use cases is discussed in this post.

In the past, these kinds of systems were called messaging middleware.  In health care this was a term of art first coined by Michael McNeal of Emergin in the early to mid 2000s. As the name of a product category, it is descriptive of the underlying technical features of the product. Unfortunately this term has nothing to do with how the products are actually used, which can vary considerably. Over time, messaging middleware has come to refer to what is now called secure messaging and collaboration, a specific use case.

The underlying technology used by messaging and orchestration systems has three key components: a messaging platform, middleware and a reasoning engine. Unlike conventional enterprise software where features are implemented in source code, these modules are like software "engines" where specific functionality and workflow is implemented through configuration or scripting. Let's look at each of these three components in more detail.

Messaging and the Conversational User Interface

The messaging platform enables person-to-person (P2P) messaging between individuals and groups, like basic secure messaging solutions. The platform provides encrypted 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 failure modes. The messaging platform also provides the transport and user interface for communications between users and the system for workflow automation. All of this communication is recorded and logged in a database to provide management information and big data analytics opportunities.

Another important part of messaging is user directories. Secure messaging systems must have predefined users listed in one or more directories, and optionally a method for extending a secure messaging framework to opportunistic users outside of the directory on a per message or conversation basis. Systems intended for use within a single enterprise have one monolithic directory. Systems intended to support messaging with patients or across multiple health care trading partners in a community have a directory structure that supports multiple enterprises.

A conversational user interface is another important characteristic of messaging and orchestration systems. Rather than a keyboard and mouse oriented graphical user interface (GUI) with pick lists, radio buttons, drop down menus and entry fields, a conversational user interface is just that, a conversation — in text or voice — between the user and the software system. Such a user interface is ideal for mobile devices with small screens suited for scrolling text based conversations.

Unlike a command line user interface or GUI, conversational user interfaces require little or no user training. Conversations can be implemented using text or voice (using natural language processing, speech recognition and text-to-voice technologies). Applications using conversational user interfaces are often referred to as "bots" or "chatbots." Chatbots can be separate applications, add-ons to enterprise applications, or a feature in a messaging and orchestration solutions.

Middleware and Systems Integration

Middleware provides integration with other enterprise information systems and devices that generate data, such as EMRs, medical devices and real-time location systems. This data is used to generate or terminate messages, provides information for message routing, payloads, or contextual information used to automate processes.

The data accessed through the middleware can be used in four ways:

  1. As a source of messages:  nurse call, medical device alarms, ADT messages, new orders notifications, critical diagnostic test results
  2. To identify messaging recipients:  user directories, user roles, on-call scheduling, members of groups of users, nurse to patient assignments
  3. As a source of context by ingesting data to run against a reasoning engine:  determining the importance of a medical device alarm based on patient diagnosis or medications, patient discharge planning and coordination, or whether a diagnostic report is critical based on patient diagnosis or medications
  4. To facilitate orchestration:  patient surveillance monitoring, optimized capacity management and patient flow in the hospital, ED, surgery, ambulatory surgery and diagnostics

These middleware platforms often support both industry standards and are configurable for proprietary protocols like those found in most medical devices and many clinical information systems. Typical standards supported include HL7, FHIR, Active Directory, LDAP, SIP, TAP, SMTP and web services.

Some middleware platforms also provide event management where messages or workflows are triggered, executed and terminated based on how and when specific types of events begin and end. Event management best practice reduces message fatigue by removing messages from user's message queues when certain events end and those messages are no longer valid or active.

Reasoning for Workflow Automation

The reasoning engine (or semantic reasoner) provides the logic used to generate, shape and route messages, and automate workflows. Think of the data acquired through middleware and message content as a data warehouse. There are many types of data: ADT messages, abstracts of patient history, orders, diagnostic test results, monitoring and therapeutic medical device data, nurse call system messages, location data for equipment, patients and staff, and more. Reasoning engines are used to extract meaning from this sea of data as alarms/alerts, worklists and workflow automation. Reasoning engines fall into two categories, deterministic rules engines and probabilistic machine learning and artificial intelligence.

A rules engine is the most mature reasoning technology and typically uses boolean logic applied via pre-written rules run against system data received via messages and middleware. Rules must be scripted in advance for every intended step or variation of the workflows to be automated. Rules engines use proprietary or standards based scripting languages to write the rules with the intent to enable clinical analysts (and perhaps trained end-users) to create and update rules rather than software engineers.

Rules engines that support hundreds or thousands of rules also need software tools to manage those rules, identifying rule conflicts and facilitating testing. When situations exceed the rules written to automate them, or when rules are "broken" due to conflicts, false positive and false negative results are generated resulting in improper alerts and workflow automation messages, or no messages when there should be messages. Rules based systems work best when all the situations for which rules are written are known in advance.

Recently, machine learning and other artificial intelligence technologies have been used for reasoning engines in messaging and orchestration solutions. Both of these technologies use algorithms that can learn from and make predictions on data. Rather than scripting rules, machine learning and AI must be trained using an optimal set of data. The result of this training is a model. After training, this model is used by the prediction algorithm to classify incoming data in the right way, which in turn leads to sound decision making.

Models can be taught and predictions scored in many different ways. Proper reasoning requires rather large sets of training data that includes the necessary scope and breadth of experience in the data set. Filtering and prepping the data, changing or combining algorithms or merely tweaking algorithm parameters is required for an optimal outcome. If the model is not taught correctly, or there is a learning problem, false positives and negatives will result.

The following diagram shows how the different components of a messaging and orchestration system relate to data sources, use cases, users and user computing devices.

How M&O Solutions Differ from Enterprise Applications

Traditional enterprise apps use a graphical user interface and are intended for use via desktop or laptop computers (requiring a keyboard and mouse). The software architecture for many enterprise applications is organized into functional modules, but does not have software "engines" like the main components that make up a messaging and orchestration system, described above. Each module in an enterprise software application is written in source code with limited configurability built in. Workflow is expressed through source code that defines data entry fields of various kinds in a screen and the flow a user follows through multiple screens to accomplish a specific task. Enterprise applications tend to also have limited systems integration capabilities. Any use of middleware by enterprise applications is via a connection to a separate middleware or integration engine.

Can a messaging and orchestration system do everything that an enterprise software application does? In theory, yes, but writing in source code allows engineers to accomplish computing tasks that are beyond the three software engines that make up a messaging and orchestration system. Examples here could include complex or unusual data visualizations, signal processing or some other complex data analysis.

Pure M&O versus M&O As an Add-on

Many traditional applications have a use case for conversational user interfaces, especially for mobile users and users with limited access to a conventional screen, keyboard and mouse. When an EMR or other enterprise software vendor adds a conversational user interface they make it easier for certain users in certain situations or environments to interact with their application. This does not make the enterprise application a messaging and orchestration system, nor does it necessarily make the conversational user interface a general purpose messaging solution for users.

When a conversational user interface is added to a conventional enterprise application, the middleware and reasoning functions are provided by the enterprise application. As a result, these systems' ability to message and orchestrate is limited to the data interfaces and workflow automation provided by the enterprise application. The ability to support use cases outside the scope of the enterprise application are very limited or non-existent. It is also possible for an enterprise application vendor to integrate P2P messaging or even a full messaging and orchestration system with an enterprise application.

M&O Advantages

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. These software engines used are often from open source projects or licensed from developers specializing in a category of engine.

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 over engineers, application specialists are currently a less expensive human resource.

In 2009 I spoke at a M&O vendor's user group meeting; many of the presentations there were by customers describing their experiences with the vendor's system. Numerous customer case studies described scenarios where the system was purchased and implemented for one use case, and then after hands-on experience with the system, the customer realized they could configure the system to also handle a different use case in another care delivery area. Sometimes the vendor was brought in to do the configuration for the new use case, and sometimes there was little or no vendor involvement. In all of these examples, the customer extended the use of a system they had already purchased through their experience using and administering the system for the original use case. A conventional enterprise applications, such as a pharmacy information system, can only be used for that application. Enterprise applications lack the configurability that enables them to be easily repurposed to address different use cases.

One of the biggest costs for many types of information systems is systems integration. And the inevitable changes to interfaces and workflows as they are upgraded or optimized over time only add to total costs of ownership. A messaging and orchestration solution uses one set of systems integrations through the middleware that can be leveraged against multiple different use cases.  Traditional enterprise applications, typically one for each major use case, each require their own set of interfaces. While some data sources are not used by all potential use cases, there is some overlap. The messaging and orchestration architecture can greatly reduce the scope of systems integration and associated costs at installation and throughout the life cycle of the deployment.

With the M&O approach, the reasoning engine is configured to automate the preferred workflow for each use case. This contrasts with an enterprise application where workflow logic tends to be mostly expressed in source code that is written by engineers, with a much more limited range of configurability. Also, the traditional enterprise software approach can result in a separate enterprise application deployment for each desired use case. The messaging and orchestration architecture can reduce the number of vendors required to automate a number of different use cases to as few as one, while providing a greater range of configurability compared to enterprise applications.

Already more than a dozen different use cases are touted by various messaging and orchestration solutions. Some M&O solutions currently support as many as seven different use cases using the same product architecture based on messaging, middleware and reasoning software engines.

Summary

Will messaging and orchestration systems replace traditional enterprise applications? Perhaps. For some use cases, such as alarm notification and clinical communications and collaboration, messaging and orchestration systems are clearly the preferred software architecture. Certain traditional enterprise applications, such as hospital and emergency department patient flow are already being threatened by messaging and orchestration solutions. In some cases enterprise applications may just need to add a conversational user interface to their existing enterprise application to better support mobile users. In other cases the unique capabilities of messaging and orchestration software architectures may overcome enterprise applications to become the dominant product architecture.

One thing is sure, the conversational user interface, and messaging and orchestration systems are here to stay. Outside of health care, messaging has received extensive hype (here, here and here), and investors have poured gobs of money into both horizontal and vertical market messaging startups. Health care has seen a similar level of investment resulting in some 200 odd competitors in the messaging and orchestration market. In horizontal markets, the messaging platform has become a platform for applications, where often these applications running on the messaging platform are from third parties in addition to the messaging vendor.

As this is an emerging software category, whether a vendor's solution is a messaging and orchestration system, an enterprise application or a chimera incorporating both can be fuzzy. Even comparing what are clearly messaging and orchestration systems is not necessarily straightforward. Not all of the solutions in this product category include all of the components noted in the diagram above, and there are often qualitative differences between the different software engines included in vendor's solutions. There are also key features in some vendor's systems that are not included in this diagram (e.g., on-call scheduling and voice over IP telephony). Another potential source of obfuscation is the quality of an implementation. Were requirements and workflow properly understood? Was the configuration of the messaging, middleware and reasoning engine an accurate reflection of the requirements?

All of these factors, and more, will become by those seeking to adopt these systems of actions to improve their workflow automation.