How NOT to implement a system

I thought about this as I was in the midst of a system implemented by a CCHIT certified group. My thought was kakistocracy.

I have the pleasure of being in the midst of a medium size install from paper record to computerized system. There are 25 providers and 80+ ancillary, administrative and financial staff. Training was an issue immediately. The company had fixed training courses available to the group from 1030-1130 or 1 pm -2pm for a five day run. Our organization had made no preparations to close for the changeover.

Our first glimpse of the system was provided by our IT manager who clicked through a group of features from the system. When something wouldn’t work, he’d say “we’ll get to that later’. He is an able and competent administrator but clearly overwhelmed by what happened next. We, the staff, had one other opportunity to see the program in training mode one week before the changeover date. It was done on a projected screen, not on distributed computer. We had no hands on experience.

My organization started the program in full force on a weekday morning. IT was busy checking to see if servers, thin clients and workstations were functional. We, the users, were having a terrible time of it. Many of the support staff do not type or at best type poorly. The program requires intensive keyboarding and is not particularly intuitive. Additionally clinical staff cannot access patients until they have been checked in by the front desk. It was 1030 before the 815 patient could be seen.

Because IT chose a stepwise install, many of the system parts, such as printing, were not readied nor installed. Because this is a very heavy server side application our adequate server proved grossly inadequate to the tasks. Screen delays of 3 or more minutes and time outs from the programs were commonplace.

It is now the end of week #1. Printing is not enabled. Much of the schedule is printed from our prior system because we cannot regularly access printing and cannot format our appointment listings.

Overall I think the system may be complex and wonderful (in a physics major sort of way); however, it has angered users and customers.

What might have been done differently?

1.Assess the staff capability better. Knowing that there is an undercurrent computer phobia and some skill sets missing, set about to improve the skill sets or augment or replace non-functional staff.
2.Assess the REAL TIME needs of the servers to prevent waits and losses. Angering users and making the delays so great that people joke about the system has not improved the ability to change over.
3.Assess the training ability of the company better. There was no cross talk between users and the company, only between administrators and the company. There were plenty of hands on trainers from the company; however IT was very thin (our own people).
4. Find realistic ways to do training. Training in mid day with a full throttle organization is sure to disappoint everybody.
5.Find ways to train hands on. Training watching a screen may be ok for the computer savvy (perhaps 1% of our population) but not for the phobics.
6.In addition to downloadable manuals for staff, make small groups to run through the program with 4-6 people, again hands on to see that they can accommodate the needs of the program; assess and address those issues before full implementation.
7.Evaluate ways to have HIPPA security in rooms. Use or plan use of devices that allow some plasticity or flexibility.
8.Involve the staff. Involve the staff. Involve the staff.
9.Do hardware fixes outside of clinical/office runtime.

These are some suggestions for a happier migration to a new system. As our system goes further, I plan to update this blog.