One of the realities of the IT domain is that, unless you are the first vendor to offer a solution for a particular domain, you are quite likely to be replacing a legacy solution with your offering.

The existence of a legacy system makes the process of EHR implementation much more complex compared to lack of it, and this complexity is usually not managed very well, leading a couple of repeating, hard to avoid problems. The definition of a legacy system is important in this context, since I am claiming that it is a part of an anti pattern. I’d like to describe the legacy system a little bit more, so that the upcoming problem definitions do not refer to a vaguely defined context.

A legacy system, in the context of this anti pattern, is a system which has an established user or more frequently a set of users in a healthcare institution. It is usually build with an older technology compared to new offering, or at least with a more traditional architecture. Database oriented, mostly monolithic solutions constitute the large end of the scale, and file and document oriented desktop applications (like many GP offerings) constitute the small end.   Given this hopefully better description of a legacy system, let’s see what kind of repeating problems occur.

Legacy technology issues
An EHR implementation, replacing an existing legacy system is likely to offer a more recent technology, and this is one of the main selling points of vendors. Cutting edge technology is a good label for sales meetings, even if people do not question the actual benefits of cutting edge technology given their roles. Established legacy systems, unless operated by an unusually incompetent set of people, are well setup. The operating systems, the network setup, security settings in the IT infrastructure, even the hardware is compatible with the software. New technology means new deployment and maintenance processes. A good example is a multi tier, modern piece of software replacing an Oracle forms based (or Paradox) software. A db server working with a couple of (sometimes many) clients, where they are relatively old computers, with older OSs. When a new EHR implementation with a technology that is at least two generations younger than the legacy software arrives, unforeseen consequences begin to emerge. You need to setup .NET framework, but that requires some other updates, or it does not, but when you start updating the computers, suddenly the legacy system stops working in some computers, or you need the latest version of Java runtime, and the update breaks something else. Unless you are performing an overnight migration (quite unlikely), you are in trouble, since you broke the existing system, and you are not able to offer an alternative yet. Assume that the setup went flawlessly, but you’ve just realized that the previous software was running happily with 14 inch monitors with a 1024×768 resolution, but your solution does not exactly fit into screen, or the screen estate is not giving a satisfying user experience. What? Everybody is supposed to have 17 inch monitors these days? I’m afraid that is not the case in many healthcare institutions. Or the screen estate is ok, but your software is running slow. A single patient admission operation which used to take under a second is now taking 10 seconds, and with each typo, this is leading to an unhappy queue. You are inclined to defend your solution of course, everybody knows that a multi tier modern software architecture distributes processing tasks to multiple layers, the back end db, the application server and to clients. It appears the decade old database technology did not require much client power at all! It is quite likely that technical people either knew this would happen, or guessed that it might happen, but they were not allowed to say anything that would put the contract in danger, and the sales people did not mention this to avoid either losses in the profits, or a more expensive offer. As obvious as it may seem, this situation usually causes a lot of pain in the first couple of months of many gradual EHR implementations. Someone has to buy faster switches, larger monitors, faster computers, install better networking and the financial and operational costs of these steps are not easy to neglect. Now to people.

Legacy people issues
Yes, legacy people is a valid term. No I’m not referring to people older than 85 or people who have slayed dragons in the past. I’m talking about the users who are very used to existing system. They know all the keyboard shortcuts,all the tricks and problems of the software they use, and they are absolutely not happy about learning the new system. Here are the things they’ll usually do, which lead to more issues. First of all, they are rarely consulted about a new system during the purchase, so they can’t easily justify the switch to new system. When they are exposed to the new EHR system, this will be during their working hours, and if it is not, they will certainly hate the system more. They will go into a room to either get training for the new system, or to provide opinions about the new system as it is being installed. Unless they have to use it in their daily routine, they will usually say that it is ok, it is working etc. So the training will be considered as complete, the project managers will put a check next to another item, and both institution management and the vendor will move towards deployment. When the deployment actually goes live, the same people who said that it was OK, will start complaining about missing features.  At least you’ll hear things like “we used to open up a patient’s data with this keyboard shortcut, now it takes forever since we have to use the mouse etc etc.” This is not always necessarily true, but it is usually a mismanaged situation. If the management can’t convince them to adopt to new way of doing things, they’ll turn to vendor and ask for changes so that the new system can look like and work like the old system. If you let this happen as a vendor, or if you let it get out of control, you are doomed. “But this is a web based application, that was a desktop application!” is not a valid excuse, they want their shortcuts, and the system is useless if the mouse pointer does not blink in purple when there is an error… This will get even worse when users begin to ask for more, this time related to legacy processes.

Legacy process issues.
One of the reasons for using a new EHR system is its ability to improve certain processes. Better patient safety, better decision support, or better connectivity to other systems. In order to do this, systems are designed to impose certain restrictions. A common use case is not allowing a particular operation without the consent of a key actor, like the doctor in charge. The problem is, when the new EHR goes live, this rule is reflected on real life processes. The process change is not announced or explained however, it is implicit in software. Users go furious, since they think that it is impossible to work with this new system, and this was how they used to work always. They ask for a change, they say that we should be able to enter administration of a drug without getting the doctor’s approval every time in some cases. Mostly they will  object to security restrictions, role based access and data integrity related warnings. They will complain, and at least for certain things management will again turn to vendor and ask for updates, so that certain things can either work as they used to with the legacy system, or various restrictions are relaxed. The implicit change in the way things work is rarely mentioned in the sales meetings, and this time even technical people can’t warn you, since they are simply implementing some technical requirements. They know nothing about how things work in the practice of medicine. If certain concepts are buried too deep into design, you are in deep, deep trouble. Probably a good example of this situation is turning a workflow supporting system  into a workflow based system. Sure, it sounds great to have a fully workflow based system. Every process has to be planned and documented before execution, and benefits are huge. When this approach leads to chaos in a hospital where no one has ever heard of process improvement, the vendor is forced to turn a workflow based system into a more flexible solution, but the whole system is designed to work on workflows! Even with all the analysis of processes done before deployment, users will simply say “this is not how we work”.  You now have to hide a fundamental aspect of your EHR solution, since no one notified users about what is actually going to happen once they start using the new system.

Solution?
Well, I can go into great detail about what the solutions are, but I’d have to charge you for it, so let me try to list the basics. Try not to hide the actual cost of your solution. In the short run you may think that you are a good sales person or CEO since you managed to get that contract, but in the medium and long run, you’ll end up paying the cost of technology upgrades, and your technical team will suffer trying to run their systems on top of hardware which was never meant to be the target for the solution. Make sure that you have a good estimate of certain cost items, like transferring data from the old system to new system, and include them in your price if you don’t want to lose a significant margin from your profit. This kind of tasks will induce further costs, and you’ll have a bad start from the beginning, which will certainly harm your reputation.
Make sure that you do not skip training about your system in a superficial way. If you can, hold people responsible. If users approve that software is OK before deployment, they should know that it is their responsibility to point out to missing features before the system goes live. At least they should be responsible for checking if the features they asked for in the beginning are there before the kick off. Make sure that the users understand their responsibilities. If you have managers which target reaching certain milestones only, who do not care about under what circumstances those targets are reached, you’ll certainly end up broke in the not so long run, due to hidden costs.
Try to explain all aspects of your system, with its implications on processes. Emphasize the problems that come up often. Most sales people avoid this, they fear that it will make the solution look hard to use and costly. First of all, you would look like a professional vendor, who has a deep understanding of what they are doing. Second, even if you hide this fact from your customer, the results will end up as cost items in your budget, you can’t escape it. On the vendor side, this situation is bound to happen if sales teams are simply done once the contract is in place. They get their bonus and walk away, but they are rarely held responsible for the following costs. Remember, maximizing benefits of people in your company does not necessarily lead to maximization of the benefits of the company itself.  These are not the methods all implementers follow, but this is a much more realistic mode of operation, where you have few surprises, which would lead to more satisfying implementations.

I am planning to write about business models of EHR solutions next, so see you then.