System Testing, Testing 1-2-3

March 24, 2015

Testing illustration

Steve Jobs once said “Everything is important—success is in the details.” For those of us in the world of IT, sometimes these details are curveballs when we aren’t prepared for them. Whether it’s changing an HL7 interface to a new vendor, adding a new product, or applying a patch to existing systems, unexpected downstream effects from planned changes can threaten the live production environment and cause downtime not only in the system being changed, but also in integrated periphery systems.

Back in the 80s and 90s, it was common to take down customer call center systems in the middle of the day for upgrades and new rollouts. Back then, communications weren’t as reliant on tech systems, and downtime wasn’t a huge issue. But over the years people have become more and more reliant on technology to make their work more efficient—and with this reliance comes the flipside that it’s now very hard to work without technology.

Today, contact center operations, clinical alerting systems, and physician communication tools are considered key to managing critical communications in healthcare. Downtime, even for a few minutes, can adversely affect operations and possibly put patients at risk.

Unfortunately, we’ve seen downtime in hospitals all too often. For example, we received a call from a customer in the middle of the night last month because they installed a patch and it brought down their entire communications infrastructure. We were able to help with this particular issue and get them back on track after several hours of investigation, but there’s a better solution that comes with a lot less stress and a much higher rate of success: planning ahead and using a test system.

Illustration of doctor in front of testing machineA test system allows you to mimic your live software environment and install patches, new software, upgrades, etc. to see how the changes will impact operations. This is done without risking a failure to vital hospital systems that staff rely on to do their jobs. If there are failures in the test system, they can be examined for the root cause, and solutions can be devised and further tested for effectiveness. Test systems allow interoperability trials with newly purchased products. New workflows can be tested before being rolled out across the organization. Once you’re confident everything is working in the test environment, changes can be applied to the production system with a high level of certainty that everything has been done to mitigate the risk to the patient environment. This is best practice to avoid jeopardizing a live systems environment within the hospital.

So why doesn’t everyone have a test system? We hear three main reasons.

  1. It’s just not top of mind. Spok software solutions often fall under the umbrella of the telecom department where folks haven’t necessarily had bad rollout experiences and the exposure to what can go wrong.  So, the deployment of a test system is a nice-to-have, not a need-to-have. Where communications are mission critical, such as in a hospital, prevention is the best form of medicine and test systems can help prevent downtime that risks the timeliness of patient care.
  2. It may also be a stretch to the budget because a test system requires a separate server. This server can be virtual, and only the most critical pieces of a solution need to be installed to see the effects of changes, but anything extra does add additional cost. The alternative, though, can be more costly. The ROI of a test system is the reduction of lost time and extra resources that would be needed to fix a rocky rollout in your live environment.
  3. A hospital already has redundant systems and believes this eliminates the need for a test system. Test systems are not the same as redundancy (back-up systems). Back-up systems are identical to production, in parallel, ready to become the main server if the primary fails. Test systems, however, remain just that, separate systems for testing. Both test systems and back-up systems play an important role in business planning and continuity, but their functions are very different. 

So what about your location? Are you planning a system upgrade or thinking about installing a patch? What about six months down the road—how are you going to handle a new release?

If you don’t have a test system in place to make sure everything works smoothly before changing your production environment, please let us know! We want to make sure the right resources are available to assist with your Spok solutions if there is a problem. And if you don’t have a test environment and are interested, we can help with that, too. You can contact your sales rep or write to us for more information.

By Rich Meyers, Sales Engineer and Kathy Veldboom, Vice President of Technical Support

Rich Meyers

Rich has more than 10 years of experience installing Spok products, from big systems to small ones. He has an excellent working knowledge of how Spok products work and has been a sales engineer for four years, helping prospects and customers learn about what Spok solutions can do to enhance their critical communications in healthcare and in public safety.

 

 

 

 

 

Kathy VeldboomKathy has been with Spok for 27 years. She has served as a field engineer, project manager, and has led Spok’s global support team since 2007. Kathy currently leads four technical support centers that provide global customer assistance for Spok’s mission critical solutions.

 

 

 

 

 




Archive

2017

     September
     August
     July
     June
     May
     April
     March
     February
     January

2016

2015

2014