Comparing features and capabilities between various health care messaging solutions requires an understanding of how messaging systems do what they do, and a common vocabulary so you can talk about it with others. And because health care messaging is a growth market with first or second time adopters, there is not yet a widely accepted or understood framework or terminology for describing how various messaging systems work, let alone comparing them. This framework applies to basic secure messaging systems, clinical communications and collaboration and messaging and orchestration solutions.

In the absence of an accepted organizing principle, vendors and providers both tend to come up with their own unique way of talking about things. When every manufacturer's product and buyer's requirements have their own organizing principle, it's very difficult to determine how solutions differ or are similar to one another or to buyer requirements. Using a common organizing principle allows for the consideration of solutions and requirements on a more consistent basis across buyers and sellers.

Not everyone has actually formulated an organizing principal or developed an explanatory framework for their messaging solution — either the one they hope to sell, or the one they plan to buy. In this case, a shared organizing principal can also add depth to the analysis of requirements and product/feature fit for a specific purpose.

This post is an effort to provide a conceptual framework to provide the basic vocabulary that describes how messaging systems work. The goal is to foster meaningful dialog between buyers and sellers. Let's get started.

This post is not intended to serve as a detailed and comprehensive list of messaging system features (that post is already in the works).

Capitalized words are key terms with specific defined meanings in the following framework. This framework is presented as a hierarchy starting with ACTORS, EVENTS and then MESSAGES.

Actors

A health care messaging solution is only aware of occurrences in the real world — a medical device alarm, a critical test result or a message initiated by a user —  through the ACTORS that are connected to and interact with the messaging system. The types of ACTORS supported and their relationships and characteristics are key differentiators across messaging systems.

An ACTOR is an entity that can generate, respond to and receive messages. An actor can be a USER (a person), a DEVICE or a software APPLICATION.

A USER is an individual that sends or receives messages through the messaging system via client apps installed on smartphones or tablets, a web interface using a desk top computer or computer on wheels, a pager or via a proprietary interface on a wireless VoIP or DECT enterprise phone. The USER often generates and replies to messages.

A DEVICE typically an embedded system device that connects directly to the network or through a system. Typically the device in question is a nurse call and/or medical device that generates data that can result in MESSAGES.

An APPLICATION is a software system that generates data that can result in MESSAGES. Examples include clinical decision support systems, real time location systems (RTLS), patient flow applications, temperature monitoring systems, lab and radiology information systems and various EMR modules such as ADT, CPOE and the patient's clinical record.

ACTOR NAME describes the ACTOR in the system presented to USERS.

ACTOR UID uniquely identifies each ACTOR in the system that is able to send or receive messages and is used by the system (or other APPLICATIONS) rather than USERS.

ACTOR PRESENCE indicates the status of the actor:  available, busy, or unavailable. In addition to PRESENCE, some systems may be able to indicate the ACTOR's location by integrating with an RTLS. ACTOR's location can be important information about USERS and mobile DEVICE ACTORS like an infusion pump or portable patient monitor.

ACTOR ROLES are a type of ACTOR META DATA that allows for ACTORS to be associated with job responsibilities, patients, locations or units. These ROLES are typically dynamic associations that last a shift or a few days and help route MESSAGES to the appropriate recipient when the actual ACTOR's name is not known.

ACTOR META DATA includes data known about the ACTOR by the messaging system. This can include roles, membership in groups of USERS, association with patients, locations or units. Likewise, ACTOR META DATA  for DEVICES and APPLICATIONS can include device names and locations, association with patients and USERS, and a definition of the kinds of payload or meta data available from that specific DEVICE or APPLICATION.

ACTOR DIRECTORIES organize ACTORS in the messaging system and facilitate the incorporation of ACTORS across different enterprises. Many messaging use cases require messaging with patients and/or health care trading partners outside the enterprise, and must be supported by the appropriate ACTOR DIRECTORY services.

Events

Events are what drive the creation of MESSAGES and their management throughout the message life cycle. While modeling MESSAGE behavior on EVENTS (with a beginning, middle and end) best reflects what happens in real life, not all messaging solutions fully support EVENTS. Rather, some systems treat EVENTS as triggers sending whatever MESSAGE is appropriate at the time the EVENT occurs for the use case. Once the MESSAGE is sent in response to the initial EVENT, the trigger resets and awaits the next occurrence of the EVENT.

In certain use cases, trigger oriented systems can be a limitation. Because the trigger only responds to the initiation of an EVENT, these systems are unable to generate MESSAGES based on the length of an event exceeding a predefined time period. (A trigger could initiate a timer to measure elapsed time, but would not know whether the EVENT had already ended when the timer hit the target elapsed time.) Nor can trigger oriented systems take action when an EVENT has ended. The end of an EVENT can cause a system to automatically remove MESSAGES from a USER's INCOMING or ACTIVE MESSAGE queue that have expired as a result of the EVENT ending. A simple example is alarm notification, where active alarms are automatically removed from the USER's MESSAGE queue when the alarm condition ends, thus eliminating the need for the USER to manually clear inactive alarm messages.

For many use cases, especially secure text messaging use cases, triggering messages based on EVENTS works fine. Other use cases with more complex workflows can be greatly enhanced by the ability to model EVENTS with a beginning, middle and end.

An EVENT reflects an originating action, state change or occurrence that is captured by an ACTOR and results in a MESSAGE. More than one ACTOR can record an EVENT in response to the same real world activity.

One or more EVENTS may initiate or modify a MESSAGE as a consequence of some analysis by the messaging system (e.g., by some sort of reasoning engine).

EVENT NAME describes the event in the system and may be unique to that message or expressed as a predefined description, characterization or category of the EVENT.

EVENT UID uniquely identifies each EVENT that is received by the system.

EVENT SOURCE describes the ACTOR, e.g., a person, device or software application that generated the EVENT.

EVENT LIFECYCLE describes the process and steps that chart the the initiation of an EVENT and the specific way the system captures the beginning, middle and end of an EVENT and associated MESSAGES that can be generated at each step of the lifecycle.

TRIGGER LIFECYCLE describes the process and steps that chart the the initiation of an EVENT and the specific way the system generates a corresponding MESSAGE.

EVENT START TIME documents when the EVENT began.

EVENT END TIME documents when the EVENT ends. Not all events have an END TIME, for example when a medication is administered. Some messaging systems treat EVENTS as triggers for messages and have no awareness of an EVENT after the initial occurrence.

EVENT RESOLUTION means the transition of an EVENT condition to its original pre-event state, or some state other than the state that initiated the EVENT. A MESSAGE may precipitate an action that results in the resolution of an EVENT, or the EVENT may be resolved on its own.

EVENT ELAPSED TIME is calculated by measuring the difference between the current system time and the EVENT START TIME, and is calculated until the EVENT ENDS.

EVENT PAYLOAD is data associated with a specific instance of an EVENT and can include system data (e.g., a waveform, operating parameter or measurement), image data (e.g., from an IP video source or diagnostic image) or alphanumeric data (e.g., message text such as a diagnostic report, description of an order or some other report or output from the system originating the EVENT) that may be included in a MESSAGE.  EVENT PAYLOADS can be defined globally for the entire system, or defined on a per EVENT basis as a consequence of some analysis by the messaging system (e.g., by a reasoning engine). For example, an EVENT may be more or less important based on the patient's diagnosis, in some cases resulting in a MESSAGE or the inclusion of contextual PAYLOAD or META DATA and in other cases resulting in no message at all. Per-EVENT payloads are often contextual information relating the EVENT to the patient.

EVENT META DATA includes data known to the originating system, such as associations to people or places, or a status or priority assigned to the event by the EVENT SOURCE.  EVENT META DATA is highly variable and ultimately defined by what and how the data is made available from the source generating the EVENT, and the capabilities of a reasoning engine.

Message

Everything up to this point serves as an enabling framework for the creation and management of MESSAGES. The following framework describes MESSAGE characteristics and a MESSAGE life cycle.

A MESSAGE is what is generated in response to an EVENT and is associated with the originating EVENT in the system.

MESSAGE NAME describes the MESSAGE in the system. The MESSAGE NAME may be taken from the EVENT NAME, EVENT PAYLOAD and/or generated by the system.

MESSAGE UID uniquely identifies each message that is generated by the system.

MESSAGE CHRONOLOGY describes how time and timing is handled by the system over the lifecycle of the MESSAGE.

MESSAGE START TIME is used by the system to indicate the time a MESSAGE is generated.

MESSAGE EXPIRATION TIME indicates when the MESSAGE becomes INACTIVE.

MESSAGE QUEUE MANAGEMENT describes the process by which MESSAGES move through various queues, depending on their chronology, status and resolution.

MESSAGES may become INACTIVE for a variety of reasons: when the EVENT driving the MESSAGE ends and the MESSAGE is no longer pertinent, or when the MESSAGE has been ACKNOWLEDGED or received a reply. Often, INACTIVE MESSAGES remain in the MESSAGE HISTORY QUEUE for subsequent review.

INACTIVE MESSAGES are removed from INCOMING MESSAGE QUEUES and ACTIVE MESSAGE QUEUES and are moved to the MESSAGE HISTORY QUEUE.

MESSAGE RESOLUTION means the transition of a MESSAGE from ACTIVE to INACTIVE as a consequence of ACKNOWLEDGEMENT, EXPIRATION or RESOLUTION of the MESSAGE. The actions on a MESSAGE that result in MESSAGE RESOLUTION are typically configurable by MESSAGE TYPE.

MESSAGE PAYLOAD is associated with a specific EVENT and is based on the EVENT PAYLOAD. How the system is configured determines what portion of the EVENT PAYLOAD is used, and how the MESSAGE PAYLOAD is presented to the user.

MESSAGE META DATA includes data known to the system, such as MESSAGE STATUS, EVENT ELAPSED TIME, associations to people, places, devices or systems.

MESSAGE TYPE is a descriptor that characterizes a MESSAGE in a way that is meaningful to USERS. Examples of MESSAGE TYPE include descriptors based on the name of the ACTOR generating the MESSAGE, and/or a descriptor based on the MESSAGE content (e.g., a STAT order, critical test result, or medical device alarm).

MESSAGE STATUS indicates the progression of a MESSAGE as it moves from initial generation in response to an EVENT, through the 3 status levels described below. The system will track a "delivered" and "undelivered" status for each of the 3 status levels described below. Depending on the workflow defined and the course of the message,  the MESSAGE STATUS may reset to an earlier status (e.g., from ACTIVE MESSAGE STATUS back to INCOMING MESSAGE STATUS) when MESSAGES are ESCALATED or DELEGATED to another USER.

INCOMING MESSAGE STATUS applies to all MESSAGES when they are first generated from EVENTS that have not been viewed by the user, ACKNOWLEDGED, DELEGATED or ESCALATED.

ACTIVE MESSAGE STATUS is indicated for messages that have been viewed or ACKNOWLEDGED by a user that has received the message. In the event that multiple users receive the same message with an INCOMING MESSAGE status, once a user ACKNOWLEDGES the message, the message is removed from all other user's INCOMING or ACTIVE MESSAGE QUEUES.

INACTIVE MESSAGE STATUS is the final status of a MESSAGE's life cycle. A MESSAGE becomes INACTIVE after an ACTIVE message has been resolved by the USER, or the EVENT that initiated the MESSAGE has been resolved, ceased to exist, or changed to an inactive state.

MESSAGE PRIORITY is the priority assigned to a MESSAGE by the system, based on EVENT PAYLOAD, EVENT META DATA and site specific rules or configuration. MESSAGE PRIORITY is used to prioritize messages and can dictate how MESSAGES are annunciated, displayed and generally presented to users. There are typically 3 priority levels in the system: LOW, MEDIUM, and HIGH. For clinicians and caregivers, priorities are associated with patient risk. Users engaged in hospital operations (e.g., housekeeping, facilities, patient transport, etc.) have priorities associated with the urgency or criticality of messages and related tasks.

MESSAGE CONTEXT is the application of MESSAGE META DATA by configurable rules to automate workflows such as MESSAGE ROUTING to identify specific recipients of certain MESSAGES (e.g., the nurse responsible for a particular patient, or the individual who is the respiratory therapy tech covering a specific unit during a given shift), or to associate an individual with some specific data (e.g., the data coming from a medical device with a patient, or a particular medication, an order for that medication, and a particular patient).

MESSAGE ROUTING is the determination of one or more specific MESSAGE recipients based on MESSAGE CONEXT (especially ACTOR ROLES) and rules defined in the system intended to automate workflow. When an EVENT first precipitates a MESSAGE, MESSAGE ROUTING is formulated resulting in assigning one or more specific recipients to receive the MESSAGE.

MESSAGE ESCALATION is a form of rules based MESSAGE ROUTING that changes the recipient(s) of a MESSAGE in the following situations: 1) when a MESSAGE is not acknowledged within a configurable time frame, 2) is declined by the the recipient, or 3) is DELEGATED to another USER.

MESSAGE DELEGATION is where the MESSAGE recipient delegates the MESSAGE to another USER.

MESSAGE RE-NOTIFICATION is a periodic audible and/or vibratory signal to a user of unviewed INCOMING MESSAGES and/or unresolved ACTIVE MESSAGES. In response to this signal, the user opens the INCOMING MESSAGE and/or ACTIVE MESSAGE queues to review and act upon their MESSAGES.

How to Use This Framework

This framework has been created with system buyers in mind, however this framework should also be of some value to vendors as well. For buyers, every use case to be supported by the messaging system should have a formal "fully dressed" use case. Data in the use case should provide requirements for the specifics of the defined framework above. For example, all the specific ACTORS and their characteristics should be defined in the use case. Things like preconditions, minimal guarantees, success guarantees and triggers can be used to capture much of the EVENT oriented specifications. A sufficiently detailed main success scenario, along with exceptions and variations, will provide the data needed to specify the messaging items.

In the framework the least structured but still important areas are the items describing meta data and payloads. It is important that buyer workflow requirements are accurately depicted in these areas. Without focus on these areas it is easy to end up with a system that is not able to automate the desired workflows.

This framework is a work in progress. Feedback and suggestions are welcome.

All of this started out years ago as a spreadsheet. Now the spreadsheet's been transformed into this narrative to better explain the framework. After some noodling, the concept model at the right was created and tells the same story as this post, but in a more visual way. This post, along with the concept model really tell the whole story.