In his 05/01/09 post Tim reports on case studies shared by three Canadian hospitals who are using Globestar’s ConnexALL® to meet their respective workflow and alarm management requirements. And while these case studies will be of great interest to hospitals attacking similar requirements, Tim’s posts from Portugal makes some important commentary regarding the “middleware” space as a whole that go beyond ConnexALL.

In his closing comments, Tim notes that “automating workflow through improved messaging is a need that spans the enterprise. Consequently, manufacturers in this market segment have enhanced their products and repositioned them as enterprise wide solutions.” He goes on to say that, “an enterprise architecture is more cost effective and is easier to manage than a series of disparate messaging products.”

These are very well taken points, and there is no doubt that a coordinated organizational effort that adheres to enterprise standards will yield the most impacting results. And in as much as the stories told at WorldConnex are wonderful representations of what can be done by creative folks working across departmental lines, the actual state of the products on the ground often tells a different story.

Let me explore this a bit here…

Middleware Politics
Because of the specific “point” needs that have driven organizations to adopt middleware implementation (e.g. nursecall or patient monitoring), middleware applications have quietly crept into hospitals for over 10 years, often with very little visibility. In many cases, the players involved with fulfilling the immediate need didn’t even think to consider larger organizational collaboration or standards at all (e.g. a nursecall middleware project may have been bundled into a construction budget).

In the last few years, this has started to change, especially since the middleware applications increasingly require IP network connectivity that requires IT involvement. But while this connectivity is a welcome move forward, it has quickly changed what was once a much simpler “acceptance” dynamic.

Today, when one of these solutions becomes necessary for a project, middleware can become a battleground between BioMed, Clinical Engineering, IT, Telecom, and various other enterprise stakeholders. Throw in middleware vendors hungry to keep their competitors out, and those on the input/output side (devices and end points) not especially eager to cooperate for their own selfish reasons, and nasty turf wars can beak out that can grind these projects to an absolute halt, the enterprise be damned.

As an example of how this can play out, I was recently involved with a project where the nursecall integrator simply refused to allow connectivity to their system in spite of the fact that the customer had already purchased the middleware application. And having been involved in this space for 6 years, I can assure you that this is not an isolated incident.

Enterprise Positioning Yes. Enterprise Implementation, Not Ready for Prime Time
But it’s not just organizational and vendor politics that make the enterprise middleware vision a difficult goal to achieve. As I’ve observed (and worked with) the key players in this space (Emergin, Globestar and Ascom), enterprise thinking has absolutely crept into the feature set and marketing materials, but there are still large gaps here in respect to enterprise-readiness when it comes to product and system implementation.

Despite the fact that these solutions are becoming more common, this is such a small niche that you won’t see technical reviews or evaluations that explore these issues. Customers are truly left in the dark for lack of available information.

Without going into a deep technical comparison regarding enterprise features, let me share some examples of of enterprise weakeness that maybe useful to an organization working through alarm managment middleware adoption:

• Many customers are forced to employ more than one middleware application (from different vendors) to achieve their desired results, often because of technical reasons, but sometimes because of inter-vendor issues. This can lead to crafty (and potentially shaky) workarounds by customers or their integrators looking for messaging to traverse systems
• These systems maintain their own directories and security models that live outside the enterprise
• Middleware application often prefer their own local databases (sometimes proprietary or sealed to the outside world). Yes there are options for other type of connectivity,  but may systems in production weren’t built from the ground up for enterprise database management or connectivity
• Redundancy and high availability are an after thought. Like the database limitations, there are methods for providing some resiliency, but these are not natural parts of the application
• The listener components that evaluate incoming messages prior to delivery to output devices may exist as discrete applications, rather than system services, creating unnecessary failure points and security vulnerabilities. (Note: We have several situations, where the restarting the application because of a system change, literally requires a human being to relogin to get the application going again.)
• The user experience is a low priority. When these applications lived primarily in data closets, the UI was a reasonable place to cut corners. As these applications grow to have visibility at the nursing unit level, there is need for cleaner more contemporary UI standards

Once You Open the Alarm Floodgate, it’s hard to control
To be fair to the middleware vendors, keeping pace with rapid changes in the input and output devices is a dizzying effort. The demands on their respective engines for the delivery of an increasing amount of traffic has forced attention on bolstering a core framework that was never built to anticipate the current demands. Throw the likely tide of regulatory attention into the mix, and you can understand why we haven’t seen entirely new platforms built to contemporary specifications.

In as much as I may be poking holes in the current state middleware applications, the promise of applications of this technology that cross departmental boundaries outweighs whatever weaknesses I point out. The technology is far improved and the potential for an enterprise future state is within reach. Indeed, as was pointed out to me by an insider close to Globestar, the soon to released ConnexALL® V4 will have a high availability and database connectivity features not seen in earlier versions of the product.

Some Potential Solutions
As we talk to customers regarding alarm management initiatives, we advise to not rush to conclusions or assume that any one product can magically bring devices, users, and alarms together in a cohesive fashion. Great gains can be had here; however, one needs to start first with the business issues that are driving adoption, rather than the technology platform.

Not only will this require process engineering, but change management that’s difficult to manage within healthcare. It’s easy to quickly assume that “enterprise” is a hard technology concept, where we would argue that it’s a systems principle whereby the components (not just technical) are intended to serve the larger organization. The manufacturers have struggled with participating with this process from a distance, and this is a place where systems integrators like TPC Healthcare can help (shameless plug). It’s not easy to fly in a swat team to work through the type of complex re-engineering that’s likely to be required.

The manufacturers need to get closer to customer requirements (especially the end-users) to understand what they need to do with alarms, escalations, notifications, and the resulting data trail left behind. If they observe closely, they will see that interfaces need to be simpler, and that changes to workflow and reporting shouldn’t always require deep technical intervention (especially from the manufacturer’s HQ).  I would also argue to that there needs to an openness at the application level that we’ve yet to see. Today this is all way too hard to prone to error because of lack of standardization.

Closing Thoughts
As the Globestar global user conference case studies clearly show, compelling business issues (that involved alarm notification and workflow) can be solved by smart folks with good enabling technologies. Globestar, Emergin, Ascom, Amcom/Commtech (and others like Radianta) have a great opportunity to step up and see past their own platforms and create better tools that are truly aligned with customer’s enterprise needs.

Kenny Schiff (www.tpchealthcare.com) is founder and President of TPC Healthcare, a specialty provider of point-of-care communication technologies, such as wireless voice, alarm notification, and workflow automation, to hospitals and healthcare organizations.

Bill and I had a bit of hit list at HIMSS and we worked to catch up with vendors who work in our areas of focus: voice communications, alarm management, and workflow automation. And while we saw continued evolution from many, including the newly launched Ascom d62 handsets, the Motorola EWP2000 (and its Vocera M1000 derivative), and interesting new personal location tag (in an ID badge form factor) from Centrak, I ultimately was most intrigued by the Tampa Bay area startup, Voalte.

An iPhone App Suite Built Around Alarm Notification
Dressed in hot pink scrub pants, Voalte (pronounced “volt”) showed off their iPhone application suite (including server side components and hooks to Emergin’s middleware engine) for presenting and interacting with alarm notifications (and other text-based messaging), along with SIP-based telephony integration to complete the workflow loop between care givers (via voice) and clinical alerts (and other alarms). In addition to the iPhone, Voalte can be deployed on the iPod Touch (without voice for now). For now the suite is Apple-centric but plans are in the works for other platforms.

Here in front of all to see was a vision of a smart focused healthcare messaging application running on a device with elegant human factors design. This was not a brick you carried on your hip, or a clumsy interface driven application. Rather the experience of picking up this device and seeing and interacting with a nursecall alert or lab data had an organic feel that gave me a moment for pause.

Granted Voalte can take no credit for Apple’s refined hardware and interface design, but they were smart enough to recognize that this would be a great jumping off point for a different approach to Point-of-Care communications. And while there are many hurdles for a consumer-oriented device like the iPhone (or Android, RIM, or Palm) in the healthcare enterprise, I can’t help but smile at this disruption at work.

Rebalancing the Messaging Equation
Alarm integration into handsets and PDAs is not new in healthcare, and Ascom, Cisco, Vocera and Polycom all manufacture highly evolved solutions that are widely used in the healthcare market. Ascom’s solution always treated messaging as a natural extension of their handset with its tight integration to their Unite messaging platform. Vocera’s badge and application design is highly attentive to the user experience, a solution that when it’s properly tuned is organic and transparent, allowing the user to work without thinking about the device. But where Vocera’s real center is the “voice” (hence the name), with messaging taking a back seat, Voalte potentially rebalances the equation.

As Trey Lauderdale (Voalte’s Vice President of Innovation) was quick to point out, Voalte is still early in their startup journey. If you wanted to, you couldn’t just pick up and buy iPhones with Voalte apps running on them for your clinicians tomorrow. Trey doesn’t see a final product until end of 2009 at earliest.

What It Will Take to Make this Ready
There are many practical and tactical issues that implementing a Voalte solution will surface when customers try to move this into production: workflow engineering and design, asset management, survivability, wireless network readiness, legacy system integration (including TDM telephony), and wireless (and application) security.

One also wonders how enterprises will manage the control of software distribution to the traditional (if you can call it that) iPhone user – the Physician. Often they aren’t hospital employees and how do you get their phones to get the latest client application. Finally, there is the traversal issue that the F/MC (fixed mobile convergence) vendors like DiVitas are trying to solve. What an iPhone suggests to the user is that the device can be used within the physical bounds of the enterprise (using WiFi), but also outside using 3G. Healthcare organizations considering this type of solution will grapple with technical challenges of session persistence, but also the operational and regulatory considerations of sending clinical alerts over a carrier network.

And of course, other more mundane issues like device cost, carrier costs (assuming the iPhone is used), battery life, battery replacement (not especially self-service oriented), group charging solutions (wall mounted rack chargers), and host of other aspects of the healthcare user experience that are not baked yet into the iPhone (and hence Voalte).

Missing pieces aside, Voalte’s very being will likely stimulate the creative juices of healthcare users looking for better ways to communicate and respond to their patients. I look forward to seeing how this further evolves.

Kenny Schiff (www.tpchealthcare.com) is founder and President of TPC Healthcare, a specialty provider of point-of-care communication technologies, such as wireless voice, alarm notification, and workflow automation, to hospitals and healthcare organizations.