Tips for structuring a successful device pilot
One of the most common mistakes hospital systems make when implementing a mobile device strategy is choosing the wrong devices. Problems like devices not roaming well from access point to access point, or even simple manufacturer quality issues, can sabotage a strategy’s success.
It’s easy to assume that if a device costs upward of a thousand dollars it would meet almost any need a clinician could have, but many hospitals have found out the hard — and expensive — way that a high-dollar price tag doesn’t guarantee the best device for their user groups.
The best way to avoid this risk is to pilot any device before making a big purchase.
The importance of end-user input
The most important thing to keep in mind when piloting a new device is to conduct the pilot in real-world situations. There is a greater chance of a successful pilot if the devices are put right into the hands of end users and are used throughout the day within normal workflows.
Most end-user groups in hospital settings are very mobile by the nature of their jobs. Clinicians must be in many different places throughout the facility at many different times of day. And it’s necessary to make sure their devices roam effectively throughout your facility, without falling off the network.
For example, be sure to test the user experience at somebody’s desk, in a patient room, and in common areas of the hospital such as hallways, cafeterias and conference rooms. Don’t forget about areas outside the hospital, if personal devices are going to be included in your strategy.
Also, have a variety of end-user groups — e.g., nurses, ER directors, residents — test the devices. Apply as many variations as possible to the pilot process to increase the probability of finding a deal-breaking oddity. This will help you avoid purchasing and deploying expensive devices that aren’t going to work well within your hospital’s workflows.
Consider maintenance needs along with functionality
When it comes to workflows, test the devices against IT’s own needs. Think about the IT team’s ability to maintain the agreed-upon devices and policies, as well as manage them. The devices and the device strategy need to work just as well for IT as they do for the end user.
Another critical but sometimes overlooked element of the pilot experience is to test installation of commonly used applications. The goal here is to avoid any showstopping surprises after the devices are purchased and in the hands of hundreds, maybe even thousands, of end users. There are application limitations that are common to certain operating platforms, and if these limits are not tested before a device is selected and purchased, a breakdown in workflows and strategy adoption is likely.
For example, there’s a common assumption that by purchasing an Android device, end users will be able to run any app from the Google Play Store. The reality, though, is that some of these devices are on old versions of Android — i.e., 4.9 or lower — or they are heavily modified versions of Android that don’t support the Play Store or don’t support Google Cloud Messaging.
Since Google Cloud Messaging is used for push notifications, that’s the default push notification mechanism. If devices don’t support this feature, then extra work will be required.
You want to be as informed as possible about what you’re buying and how it’s going to work in real-life scenarios within—and beyond—your hospital walls.