Alerts and Notification Platforms (which many of us affectionately call middleware) splashed into the healthcare market in the early 2000s. Suddenly, hospitals were no longer limited to just a pager notification from one initiating device. We all used the phrases “Bat-Belt or Tool-Belt” when describing the quantity of devices that clinicians used to receive patient notifications. The market exploded as hospitals looked for ways to consolidate devices, reduce costs of managing multiple platforms, and increase caregiver satisfaction by relieving them of their “bat-belt”. Many of us launched our careers from this emerging category. Products such as Emergin (now Phillips), Connexall, Amcom (now Spok), and later on Extension (now Vocera) boldly staked their flag on the hill of progressive health systems.
As with many emerging categories, the government soon got wind of an opportunity to create regulations and oversight – necessary to protect patients from potentially risky tech. These regulations have proven to be a positive move, but created a large barrier to entry for newer more flexible tech. As the market grew so did the alarm volumes and a new challenge of Alarm Fatigue. The deluge of issues of automating a problem from one location to another exasperated nurses – an issue that many of us data wonks warned of early on.
Now this enabling platform is poised to enter its next generation of use – will it stay a simple translation and traffic cop engine or will it emerge as a smart decision support tool? (Many will say it already is a smart decision support tool). Changes in branding such labeling middleware an IoT engine or clinical enablement platform or even, dare I say, AI have pushed the envelope of what it is and what it will be.
Questions you should be asking as you employ the middleware of your current provider or those you are reviewing:
- Does your tool have the ability to do complex processing of alerts and notifications? – can it think outside of the action of on or off? Many hospitals limit their abilities to design alarm automation and workflow by purchasing middleware that can only translate and transport information. There are platforms available that employ basic “thinking” principles. Â What does this mean? It can be as simple as If, then, and (or) or a watch and wait process. It could be as complex as loading an algorithm to process multiple alarms (or pieces of information) thru and “decide” what the best course of action is for that alarm. Listen for phrases like “contextually aware alarm processing” but not just “we provide contextual awareness with the alarm”. That’s just code for more info….not more thinking.
- In the database design, does it support multiple sites/ enterprise abilities? How do they handle enterprise? Can their abilities augment other more standalone electronics based technologies that lack of ability to create enterprise database? Make sure you identify which pieces of data you will be missing in this model…there are some. Data strategy on an enterprise level must allow for full consumption of the electronics activities – many middleware tools throw away “unimportant” pieces because it does not impact their action. Those pieces can actually be important when painting a picture of the patient’s experience.
- Libraries of interfaces will decrease in value as the standards of interoperability are forced by the Healthcare providers – what limiting factors does your middleware have in this area? The whole point of a middleware is to normalize different electronic-based systems to provide a seamless caregiver experience. Many of the electronics firms today use blocking strategies to leverage their market share to “own data” – do you really want that? Look for electronics firms who are open to working agnostically with any middleware or your chosen engine – in your chosen interface language – your strategy matters. Look for a middleware that is open to consuming any platform and flexible to be able to consume it. You are the customer – own it. To quote our home builder “I will give you my opinion, but what really matters is your decision. You have to live with it – I just have to build it.”
Alerts and Notification engines are, by their nature, translation engines; they are like the United Nations. They receive information in one language and translate it into another so it can be delivered. A nurse call speaks French and a wireless phone speaks Spanish – middleware puts both in a common language and drives compliance to a specific process. They are also traffic cops – they make sure calls don’t collide (though there is debate around this area). But they also have to think thru the traffic pattern, and the condition of the drive at both ends (the one generating and one receiving the information.) Remember, the logic here is can it be done another way and what could make it better?
Many nurse call platforms are starting to enter this arena though none can provide a platform that enables Cardiac Monitoring processes. This regulatory based interface limits their ability to meet the growing needs of the Health Delivery Organizations. Be wary of utilizing a electronics based platform to enable your workflow process – does it meet your requirements and needs. What benefits are you getting beyond just middleware to take on this process?
So, can an Alert and Notification Platform replace the role of Nurse Call…no, there is no ability to collect the patient’s action. The physical connection to the patient is not available. Unless a middleware platform can offer a device to touch the patient and allow for physical creation of an alert then it cannot “be” middleware. However, Gartner’s point is without the regulation of the wire in the wall – it would have capabilities to provide the same processing (or greater) ability as nurse call.
Next Week we will be exploring IPC and CC&C platforms.