With Google’s Project Glass  as well as Apple and Samsung’s smart watches soon upon us (and of course the infamous Kickstarter fueled Pebble), there’s new attention to wearable communications devices that’s interesting to see unfold. For any of us who have fumbled with mobile device interfaces for the last 15 or 20 years, the focus on eliminating physical barriers is encouraging. Best of all, it is likely to yield some significant user experience improvements that should carry over to the non-cyborg day-to-day devices we carry.

As an inveterate geek and entrepreneur, my hat is off to these technology behemoths for trying to stimulate a new category to extend their respective reach. But while they may indeed generate buzz, in the near term their exploration is not necessarily driven by truly useful needs that will lead to quick adoption. In verticals like acute care hospitals, it’s a different story. The need for devices (and platforms) that are ergonomically suited to mobile workers has a higher level of urgency.

Smartphones and In-Building Communication Platforms for Healthcare
Because of my work, I’m most intimate with how this plays out with proprietary voice/data devices that are primarily the province of Cisco, Polycom (Spectralink), Ascom, and Vocera, but also increasingly with smartphone applications like Voalte deployed on Android and Apple devices. Since the mid-nineties hospitals have been looking to these devices/platforms to provide better throughput and to close the communications gaps that have always plagued the often chaotic world of hospitals.

While wearability will always matter with healthcare workers looking to verbally communicate with their team members (where does the iPhone go when you are wearing a scrub?), the need especially comes into focus when an organization makes a decision to enable integration between these smart devices and alarming applications like nursecall or physiological monitoring. In those use cases notifications are passed from the originating system to a caregiver’s device, and in some cases the caregiver’s response is transacted from the device back to the originating system.

Follow nursing staff around who are tending to patients and you will begin to understand the traditional smartphone in your purse or clipped to your hip is not optimal. Let’s say there’s a critical threshold that has been reached for a patient you are covering? How do you get to your device when a Bed Exit alarm has been tripped? I have been working on two side-by-side integration projects, one using phones, the other Vocera, and while both will have successes the wearability differential is significant and will impact the respective results.

Ease of Response/acknowledgement is Critical Workflow Element
While my 10 years of experience in the Vocera ecosystem would speak to a potential personal bias on this, of the solutions currently on the market in healthcare, Vocera’s is the only one that organically addresses the wearability issue. And this is not just a matter of style, preference or bias. I’ve been involved in wide scale deployments of many of these platforms and recognize each of their merits,; however, save for Vocera, wearability is 100% an afterthought^*.

A current focus for my team at T2 has been on supporting patient satisfaction results through improved response time metrics. Our customers have tasked us with understanding the originating data and the response data from customers deploying Vocera and its competitors. A couple of conclusions have really stood out for us:

1. Integration between alarming systems and mobile devices is now no longer a convenience add-on. Caregiver response is a key data point in understanding staffing and response issues
2. Ease of response/acknowledgement is a critical workflow element. How one wears the device can significantly impact a caregiver’s ability to response to a patient

Project Glass and Nursecall Integration?
I realize that most people would not put Google’s Project Glass and nursecall integration together, but the larger point is that a high quality interface is a critical success factor, and in an increasingly mobile device-centric world, it’s even more important. Extend the reach of core systems like nursecall with mobile devices, and matters of interface and wearability can no longer be an afterthought. Same with if you are looking to measure and improve your organization’s performance.

Kenny Schiff, is Managing Partner and Founder of T2 Technical Services.  An 18- year veteran of the healthcare technology business, Kenny is considered by his customers and peers to be no-nonsense trusted resource who can be counted on to deliver complex solutions with high impact. Visionary always, but never afraid to be hands on, T2 is a great creative platform for Kenny’s entrepreneurial and technical passions.

Last spring Gary Blumberg at Midstate Medical Center (Meriden, CT) called to ask if there was a way to tweak their nursecall/Vocera workflow to accommodate staff members taking breaks or leaving the nursing unit. While I enjoy giving rapid fire sage wisdom to my customers, the answer was not as simple as having users pressing the DND button on their Vocera communication badge.

If you know anything about the way nursing units work, you will understand why what seemed like a relatively simple request turned into deeper discussions about nursecall workflow in general…

So if someone went to lunch, who should receive patient notifications? and what would happen if they were tied up with another patient. And how would that be different at night? or on weekends? And what if the nursecall was urgent? or trivial?

Turns out that in spite of Rauland’s Responder IV nursecall meeting their general needs, process wise no one at Midstate had really good handle on the rhyme or reason of its setup. And until Gary joined Midstate full time in 2011, there was no one with wherewithal or responsibility to cook up how calls could flow from patient to caregiver more smoothly and in a more meaningful way. Even something as simple as the significance of the colors that corridor lamps flashed outside patient rooms was a mystery to most clinical staff. No real knock on Midstate here, this is par for the course at most customers we visit with.

How Did they Handle the Break Issue?
I’m excited to share the details about how we worked with Midstate to solve the “what to do about breaks” workflow problem, but also how Midstate used this as an opportunity to provide a streamlined nursecall escalation process (with key failsafes built in), and to provide ongoing reporting on types of patient requests (and the amount of time it takes to close these).

Best part of this story is that Midstate has been able to leverage existing technologies without significant capital expenditure. No forklift platform upgrade required.

By shifting the call processing intelligence from their legacy nursecall to their Connexall workflow engine, Midstate is extending the useful life of an existing legacy nursecall platform. All this while improving patient response times and adding a layer of reporting and accountability that had not previously existed. Nothing really revolutionary here. Together we built something very smart and practical that didn’t requiring massive process re-engineering, without it costing a ridiculous amount of money.

Some Background
Midstate had been using Globestar’s Connexall alarm notification middleware to connect Responder IV with Vocera since March of 2007 (their initial launch was the first Connexall/Vocera integration anywhere). Prior to Vocera/Connexall, Midstate had used in-house pocket pagers (beepers) for receiving nursecall notifications with the workflow managed and orchestrated by their existing Rauland system. Before and after, the system was simple, easy to manage, and reliable.

Given the significant change management involved with their initial Vocera implementation as a whole, when Vocera badges were introduced the desire was to simply replace the beepers with badges workflow wise. A patient pushing their call bell would receive attention from the caregiver covering their room. Midstate kept everything flat, with no escalation involved, or differentiation of alarms. To keep things familiar, the assignment process was kept in the Rauland system. And even though they had the capability of calling back into rooms from Vocera badges, that functionality was never widely advertised.

CIO Jen Comerford always knew that they could do a lot more with what they had, she was just looking for the right opportunity and timing.  That opportunity came in 2012.

Good Bones Already in Place, But Still Room for Improvement
The building blocks of Midstate Rauland Responder IV System were originally put in place when the hospital established its new campus in 1998. In 2003, and then again 2010 it made the most sense for the hospital to add on to their Responder platform as new inpatient units and additional services were added. While an upgrade to a newer platform could potentially add some useful new features, changing out a nursecall (or “Call Bell” to the rank and file) system is not trivial, especially for a community hospital like Midstate.

Workflow wise, during most nursing shifts Midstate has operated using Triage/Dispatch model. A Clinical Information Associate (CIA) answers most nurse calls and then uses the Rauland console to dispatch a specific caregiver by choosing from a preselected list of “Service Requests” alerts that are then dispatched to caregivers covering the room that originated the request. For example, if the patient tells the CIA that they need pain medication, an alert is triggered to the RN covering that patient. If the patient needs help getting to the bathroom, the request is sent to the proper Clinical Care Associate (CCA). This methodology worked well for them with beepers and carried over with them to Vocera.

What had become clear over time was that there were incidences where a request had become forgotten or the covering staff member was not available or not properly assigned. This inevitably automatically triggered nurse call overtime alarms which needed to be silenced in the room by a staff member. As we looked at this, we determined that Midstate struggled with four major problems:

• Excessive response times, sometimes for basic request like bathroom assistance, or worse for more critical needs like pain medication
• Difficult to manage and awkward staff assignment process
• Unnecessary alarm noise from patient or service requests that have not been responded to (and the nursecall system upgrades to “Overtime”)
• Lack of data supporting where the bottlenecks or process disruptions were

With increased attention on life safety (e.g. fall prevention) and patient satisfaction scores due to adoption of HCAHPS driven surveys, the need to tighten up and perform better is on everyone’s mind. It was clear that Midstate had most of the components already in place to fix this.

Nursecall Integration Reinvented
As we looked at solving the problem technology wise, we knew that no one single component system would provide the solution. Rather the solution would be the sum of the parts (Rauland + Connexall + Vocera). We’d leverage what each system did well.

The first decision was to move the call processing that delivers alerts to nursing staff’s Vocera badges out of Rauland and place it in Connexall’s workflow engine. This gave Midstate enormous flexibility in tailoring escalation timing, alarm differentiation and ongoing nursecall reporting. Connexall’s hierarchical callpoint framework could catalog every type of nursecall alarm and give it specific behaviors. Connexall would keep track of every nursecall, its type, its originating location, and what happened all the way through cancellation. And because Connexall had visibility to the entire process end to end, it would be the backbone of the reporting engine.

Given its simplicity, ease of deployment, and the lack of additional costs required to deploy it, Vocera’s Connect Console application made the most sense for the staff assignment process. By placing the assignment process in Vocera, users would reap the benefits of Rauland and Connexall’s technologies without having to directly interact with any of the complexities behind it. Nurses and CCAs would continue to use Vocera badges as they always have, but we’d introduce some enhancements to the way alarms were displayed and could be interacted with. Midstate would also start introducing new Vocera B3000 devices into the mix which are better built for alarm integration (improved front-facing display and front-side alarm interaction buttons).

Vocera Connect Console

Workflow Modifications
Nursing determined that we would continue to the Triage/Dispatch model during times that a unit was staffed with a CIA. During those shifts, all nurse calls would go to the console with the CIA being the first responder. The original alerts would also go to a caregiver team (RN + CCA). If the alarm was not canceled within 90 seconds, then it would be escalated to a backup. Any staff member could “cancel” the call (and stop further escalation), by either talking to the patient (from the console or badge), or by going into the room and pressing the cancel button. During shifts where there was no CIA, the caregiver team would become the first responder without any modification to the system.

New Workflow for Patient Initiated Nurse Calls

If a CIA was in place to triage calls (day shift), then a “Service Request” would be sent to the appropriate caregiver. If the staff member was unavailable or tied up with another patient, the request could be escalated from the Vocera badge with a simple voice command or button press.

New Service Request Workflow

Behind the scenes we worked to synchronize the alert process so that any member of the workflow canceling the alarm would stop further escalation, but also remove the alert from all others who may have received it. We also created a mechanism that allows any member of the workflow to be bypassed if they are not available (e.g., on break, or at lunch).

Data = Knowledge
To get our new framework ready for production, we did extensive testing and validation. With most of the kinks worked out, Midstate trained all CIAs (in staff assignment), RN/CCAs in alarm integration and general nursecall. All RNs, CCAs, and CIAs are required to test out of the class to ensure consistent understanding of the nursecall response process. You can see the  excellent training video that Gary created to support the rollout here.

On April 3rd we launched to Midstate’s Pavilion 3E (an inpatient med-surge unit). Perhaps the most significant outcome of the initial rollout was the dialog between nursing management and staff regarding procedure. The new system immediately forced a discussion regarding operating issues that had previously not been discussed or adequately defined.

The good news is that the initial results are encouraging. The new framework has led to an immediate reduction in response times by 30 seconds.

Preliminary Results

Here’s a sample snapshot of data for a full day/night on 4/25/2012

Nursecall Distribution Chart

Update (6/26/2012): With 3E operating smoothly, the rest of the nursing units have progressively been rolled out. June 25, 2012 the final 2 nursing units and the Emergency Department went live to complete the project’s launch.

Some Final Thoughts
While it is way too early to claim complete victory, there are a few fundamental outcomes we can be certain of that will lead to improved patient care and safety at Midstate.

1. Defined and Documented Workflow—All nursecalls have a defined destination that includes multiple backup layers and failsafe escalation to a responsible managerial member of the team. Even if responsible caregivers are somehow not available, the system will properly distribute calls to the proper backup entities.
2. Improved Understanding of Patient Response Process—Nurescall workflow has been clearly defined and communicated to the entire clinical staff through a well designed and executed training program that will now be built into orientation and ongoing staff development.
3. Ongoing Performance Data is Easily Available—Nursecall performance data is available to management via a push mechanism. It is easy for managers to compare results from week-to-week, day-to-day, shift-to-shift. Additionally, should there be a patient/family complaint, or an incident, it is easy to drill down into the data to review actions based on room location and time. The reporting process doesn’t require IT or other support services to execute.
4. New Workflow Didn’t Require Complex Operational Changes—Assigning caregivers (and backups) to room/patients is an easy process that gives immediate visibility to who is assigned where. Users now have more meaningful alerts on their devices and the ability to easily escalate or rollover calls to team members

and last, but not least

5. A process for handling breaks

We recently collaborated with Midstate Medical Center (Meriden, CT) to deliver a tightly integrated workflow that quickly and efficiently connects patient alarms and caregivers.

Midstate’s goal is to provide a “safer and more satisfying experience” for their patients. This short Midstate produced training video show off their processes in action and clearly demonstrates how the organization is working to achieve their patient goals.

Building off of their legacy Rauland Responder IV nurse call system (circa 1998), Midstate’s workflow processes are tied together with Connexall’s alarm messaging workflow engine, and Vocera Communication badges. The end result is a refined process with detailed performance analytics that is helping the hospital deliver quality care to their patients.

In spite of seemingly having enough licenses (300 Enterprise), one our customers hit the wall Vocera licensing wise. There was a huge discrepancy between the number of active users in the admin console and the number of logged in users. For some reason the customer had chosen to not enable auto-logout (default for this is 60 m) in their setup.

It seems that large numbers of users have been using the system but NOT logging out of their devices. It is likely that they are either turning them off, or taking them out of the building. Since “auto logout” was not enabled, the system was taking up “seats” for all these users, in spite of the fact that they were really not online.

If you ever run into the situation that you need to quickly release licenses for users who are off network, enable auto logout and set it to 2 min. Since Vocera pings badges every 30 seconds to determine where they are at any given time, that will give the system 4 tries to find a badge. If it can’t find it by then, it will release the login slot that it’s using up. Once you have the license level down below the limit, you can change the auto logout to something more practical (e.g. 60 or 120 min).

As is the case most of the time, healthcare customers don’t really care whether they have active or passive RFID technology only that it solves their business problem. The only time they begin to care is when they realize the tag and infrastructure expense and consider the real return on that investment. In addition to the tags, all RFID solutions require varying degrees of sensing technology to be layered on top of the existing environment. This often opens up a complex set of issues for facilities, IT and the clinical staff. For both passive and active, the value proposition gets challenged when looking at the growing need for infrastructure. The big attraction to passive RFID is the much lower cost and often disposable nature of the tags as compared to active tags that can be in the $40 each and up range. However, passive becomes an impractical option when granular location identification is required.

So what are some good examples of passive RFID in healthcare and what should you look out for? First, think of passive RFID as EZ-Pass in a hospital. The technology is very good for capturing the incidents of a tag that passes by it and when. It does not do a good job of knowing your location on the highway or bridge after you pass the toll. This is where active works well.

Here are some good examples of passive RFID in a hospital :

• Patient elopement (walk-outs) in the ED.
• Equipment containment within a floor or a unit
• Securing equipment at entrances and exits.
• Tracking cardiac catheters in and out of inventory.

So, what should you be aware of prior to exploring a passive RFID solutions?

• The big issue is that if you begin to tag equipment, it’s likely that you will not be applying an active tag in the future. It’s certainly possible, but highly unlikely for the next few years.
• Make sure that the technology you choose can detect motion and directionality. Up until recently, passive RFID systems could only tell if there was a tag within its reading zone. Given the use case, you’ll want to know if someone is going out, or going in and also whether the tag is moving or just happen to be near the reader.
• Choose tags wisely. It’s a bit of an art to determine the right tag for different applications. Factors such as metal content, water content, distance and orientation to antenna all play in determining the right tag solution.
• Know what you are going to do with the data collected. Example: Do you need an audible alarm each time an IV pump walks off the ICU? Or maybe to record the event? Do you need security to get an immediate message that a wheelchair leaves the building? Or maybe the control center should get a pop-up on their screen.

There’s no question that active RFID is much more evolved in healthcare applications. There are many active RFID vendor solutions that are well documented. Awareness and education of another possible solution could save you time and money.

Is Your Hospital Considering a One Communication Device Strategy?

Here are some key points to consider from my recent article in EnterpriseMobileToday.com.

1. Usability matters. A NICU nurse whose hands are busy diapering a baby has very different needs than someone dispatching code teams, or an anesthesiologist. In pointing out the difference between purpose-built healthcare devices like those from Ascom, Vocera or Cisco (and say a BlackBerry or an iPhone), Emergin often talks about “buttonology.” Visualize code team members fumbling for the Chiclet-sized keys on a BlackBerry Bold when needing to respond to an emergency situation. When seconds matter, better to have a single button push on a Vocera badge, or a simple soft key on an Ascom Medic handset.

2. Where are the applications? Healthcare-specific applications do exist for the BlackBerry, and Palm and Windows mobile smartphones, but they are far from perfect, often without true device/application integration. And mobile healthcare professionals require devices with deeper and tighter integration between hardware and applications.

While software providers like Globestar have smartphone-ready, hospital-friendly applications for alarm notification, escalation and dispatch, they lack tight device integration, making them imperfect. Again, the purpose-built applications, like Ascom phones or Vocera badges, currently have the leg up on the competition, though this may not last for long.

3. It’s the Network. If you don’t have a reliable network that can handle mobile communications, you’re going to run into problems. And in a world where medical professionals traverse from office to hospital to home, that network may really be a network of networks. While it may be okay to drop a call mid-conversation when chatting out on the street with your buddy, it’s not okay when a nurse misses a critical alarm from a fetal monitor.

In spite of significant efforts, the medical grade network (even purely at the building level) is not a reality yet. And while fixed mobile convergence (FMC) vendors like DiVitas (or the big PBX players like Nortel, Siemens and Avaya) have solutions that manage the transitions between networks for multi-mode devices (e.g., in-building wireless’3G), they can’t really fix the network of networks problem. And even if they could, the purpose-built, multi-mode device with true application integration has yet to appear.

4. What about workflow? Spend time in an Emergency Department or Operating Room suite recently? This incredibly fast moving world doesn’t lend itself well to ad-hoc asynchronous communications like email or text messaging that is de rigueur with normal consumer smartphones, especially given all the possible sending and receiving points. Reliable communication starts first with designed workflow and an understanding of the journey information must take from inception to delivery, to acknowledgement and response. Once you have a workable flow, then software applications and devices can be considered.

For more information, see In Healthcare Communications, One Device Does Not Fit All … Yet

Kenny Schiff is a contributor to Internet.com’s EnterpriseMobileToday.com. He is founder and President of TPC Healthcare, a specialty provider of real-time location and point-of-care communication technologies to hospitals and healthcare organizations.

Just back from attending RFIDJournal’s RFID in Health Care 2009 conference yesterday in Waltham, MA. In spite of the economic downturn, the good news is that RFID continues to gain momentum in healthcare because it is having real impact on productivity and the bottom line. What was once just a promising set of technologies and solutions is increasingly becoming mainstream.

Some takeaways from the event… it seems that there are enough forces to motivate the market away from WiFi solutions. Second, creative funding models are really what are helping the adoption of enterprise solutions along with managed services. The shift away from capitalized purchases for RTLS and RFID systems may be what moves deployments of these solutions out of the early adopter realm.

The other take away is that passive RFID definitely has a place in healthcare. We heard some compelling case studies regarding high impact, yet lower tech applications of more traditional (if there is such a thing) passive RFID. So even thought there are massive initiatives for enterprise RFID based on active technologies, customers are getting great return from less pervasive and more specific passive technologies. UMass Memorial has such an initiative in the Cath and EP labs. Also, Ray Lowe, the IS Director of Providence Health (a major west coast hospital group) talked about how he will be using Reva Systems (make applications to manage and integrate RFID readers) and ThingMagic (makes readers) as part of workflow in a new facility that will have a WiFi-based RTLS system.

The real story here is that no one auto-ID or location-based solution is going to fit all needs within the enterprise. And that’s not a bad thing. Continued innovation and product maturity, along with more open systems are making this all doable. For hospitals, there are opportunities small and large to take advantage of RFID and RTLS to immediately impact productivity and the bottom line.

Just finished reading David Hoglund’s newest white paper on RTLS in healthcare. If you are in healthcare technology, and are not already tracking David’s excellent Healthcare Wireless and Device Connectivity blog I highly suggest either firing up your RSS reader and pointing it here, or signing up for his newsletter here. You can download the white paper here here.

I’m not always a great fan of white papers as I often find them manipulative point of view wise, but I think this piece (except for a couple of paragraphs at the end) gives a very impartial read on the whys and hows of RTLS/RFID in healthcare. While it details eloquently the short-comings of WiFi and zonal “good enough” approaches, it more importantly couches them properly against the larger more practical business cases for RTLS in healthcare. David’s piece is less a condemnation of WiFi, and more of a call to making this about business not technology.

Hoglund developed this whitepaper for AwarePoint (whose RTLS technology uses ZigBee), but the conclusions could have just as easily pointed to Sonitor (Ultrasound), or Centrak (IR/RF).

The good news is that customers have some solid choices in powering the critical applications that are so desperately needed to help improve healthcare business performance.

Consultant, “Connectologist,” and industry observer Tim Gee’s Medical Connectivity site is one of the rare places on the internet that covers the healthcare alarm management middleware space. Recently he published a series of  posts tracking activities at Globestar’s Annual User group meeting in Lisbon, where he served as the keynote speaker where he brings to life some real life examples of middleware applications in acute care.

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.

After a very exhausting quick two day run through HIMSS2009 in Chicago, my colleague Bill McKenna asked me whether I had any takeaways. If I was true to form, Bill would have gotten a very quick read from me, but as we finished up lunch, I didn’t really have a fast or easy answer. Now riding the plane back to New York, I take a moment to make some commentary.

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.