Clinical Systems Implementation – Five Things You Need to Do!

April 22nd, 2015 Blog Eric Lake

Recently I wrote a blog about the steps required to successfully select a clinical systems vendor that will truly deliver against your needs.  To review: write a business case, collect detailed requirements, write a clear RFI, quickly narrow down your list of candidates, host some dog & pony shows, and finally make a decision. Whew!  That’s a lot, and each step is a lot more difficult and involved than it sounds.  But that’s the case with just about everything in life really, so I’m sure that being the smart and determined blog reader/system selector that you are, you managed to get through them all.  Nice job!  By now however you probably realized that systems selection is just the tip of the iceberg.  Now that your company has dropped a good chunk of change because you wrote that nice business case explaining why buying the system was such a great idea, you have to make sure that people actually, you know, use it.  Clinical systems implementation can be a tricky business.  All the business cases in the world won’t help if the system doesn’t get rolled out properly, and even the most perfect of systems won’t be of any benefit if implemented in a vacuum.

Spare Some Change (Management)

Any time there are changes, there are going to be problems. People don’t like change. The lack of a change management strategy is one of the biggest reasons these shiny new systems fail to deliver on what they promise. In short, management needs to communicate the changes well before they start happening so people can prepare themselves. Really what needs to happen is essentially a marketing campaign – first teasing the upcoming changes (and the new system), then some ‘benefits management’ (letting people know what’s in it for them…you still have that business case, right? Time for a little copy/paste…), setting expectations for future shifts in the way things work, a big launch that’s given some degree of fanfare, and a follow up campaign to reinforce the new order of things (and to remind people how great everything is working out). All of this needs to be scaled to match with the impact that the new system will have on the organization – be careful not to overdo (or underdo) it!

People Power

While this is covered to a degree in the change management piece, it goes a lot deeper than that. First, you need to find the system a home – who is going to ‘own’ it? You also need to make sure that every layer of the organization that will be affected by the new system is addressed in a more ‘personal’ manner. Have conversations with individuals to get a better understanding of their concerns and perhaps more importantly get an idea of their expectations of the new system. Hopefully you’ve already addressed everything way back when you collected requirements, but things change and people come up with new ideas as they see for themselves more of what the system can do. Regardless, you need to make sure that what the people need (a good set of reports, for example) will be available from the system at launch, or you’re setting yourself up to fail.

At a higher level, some organizational changes may be necessary to get everything out of your new system that you want. For example, before the new system you may have had people doing manual data entry as half of their jobs. But the new system uses fully automated data feeds – what are you going to do with all of that free time now? Or the opposite might be true, where you need some kind of system administrator or business analyst permanently attached to the new system. Make sure you plan ahead!

Process is Paramount

A new system will almost always require a new set of processes. After all, the reason you’re getting a new system is that it’s better (and therefore different) than your old system. But it’s not just the actual interaction with the new system that will need to be looked at. This is a great time to step back and evaluate your overall processes in the area that the new system is a part of (and you’re already of a continuous improvement mindset anyway, right?). This is a great way to “market” your new system – because let’s face it, the old system wasn’t that bad. Usually the problems are at least 50% process oriented, if not more. By revamping your processes you can not only make them more efficient but they can be designed in such a way as to dovetail nicely with the new system. When you are issuing your communications throughout the system selection/implementation project, this becomes a much more powerful message than merely touting a new system. “Hey, we’re overhauling everything so your lives are about to get way better!”

Testing Users’ Patience

There’s nothing worse than rolling out a system that people find to be buggy and unstable. Even if the issues are minor, a bad first experience can leave a bad taste in people’s mouths for a long time (and perhaps forever). Doing thorough system testing (especially if your system has been configured or customized) is critical. User acceptance testing will also help to get a greater number of future users involved to not only spot technical issues but to identify general deficiencies in the system before it gets rolled out to the population at large. Testing is painful but necessary if you are to release a quality “product” to your organization.

Systematic System Training

Even the most simple of systems will require some training, and there’s nothing better than some hands-on sessions where users get their hands dirty. Just keep the extent of the training in line with the complexity of the system – don’t overcomplicate things. Further, training should be focused for each job role as there’s no reason that a person in one job needs to know every little thing a person in a completely different job does in the system (other than at the highest of levels). A training plan should be developed well before system roll out so everyone knows what to expect and blocks off time for training on their calendars. But training doesn’t end with the actual training – users will also need access to detailed documentation for refreshers, and creating other aids such as “cheat sheets” and FAQs can go a long way in making sure people can easily put your new system to good use.

By now you’re probably regretting purchasing this new system. Whose idea was this anyway? Take a deep breath and fear not, for with some planning and oversight (and a good fully dedicated project manager) your system can experience a smooth roll out and significant user adoption. Which means you did such a good job with this one that you’ll be the one put in charge of the next one…way to go!

, , ,