A common theme in the literature about ICT in other industries is the importance of transitioning to business-as-usual (often called BAU), or, in other words, closing down the project in a structured way, and making sure the right support is in place.
When it comes to clinical systems, and especially EMR, this is a challenge to say the least.
I’ve been to most of the leading sites in Australia where an EMR has been deployed for several years, and I can tell you pretty much everybody is still in “project mode” to one degree or another.
The idea that EMR projects ever really finish is simply a myth.
Implementation of EMR is a journey, not a destination.
There are a number of reasons for this. Let’s explore some of them:
Firstly, it is very unusual for any hospital in Australia to “go-live” with a full stack of EMR solutions on one day. About the only places that have come close to this are Hervey Bay and RCH in Melbourne.
For the rest of us, there simply isn’t the money or the resources to deploy a complete solution in one day, particularly in a brownfields site.
In some sites this might mean going live with a surgical module that doesn’t have anaesthetics included, or there may not be other specialty modules that are important to that hospital, or device integration may not be included…
The fact is that there are so many individual pieces in a modern, complex, integrated EMR that not one site can actually install them all at one time anyway. There is always more to do.
When you compare EMR to, say, a payroll project with the “go-live” at the start of the financial year, for example, those projects typically have a defined end and a defined beginning.
I can talk to this with some authority, as I once implemented a payroll system across the Waitemata Area Health Board in Auckland.
We ran a typical RFP process, got the vendors in to demonstrate the products, selected the most suitable one, and rolled it out after about six months of planning design and testing.
We set up a hotline number that anyone could call with any queries when the new system went live. We did all we could to make sure that everybody in both the big hospitals and the community centres was aware of the upcoming change – pretty much all the Change Management 101 stuff you would expect to see in any ICT project.
I think we did a pretty good job. The system went live on the planned date.
And no one noticed.
Well actually, that’s not strictly true; we did make a small change to the way in which leave was recorded on payslips, moving from showing accrued leave as days to showing it in hours. So we did get a few calls on our hotline about this change, but otherwise the whole thing went pretty much unnoticed.
And that was success from our point of view. I even got paid a small bonus for getting the system in on time and on budget.
Once the system was turned on, and everybody was being paid okay, the plan was that there might then be gradual further improvements or new modules to deploy, but basically the project was finished, the ICT team was dispersed and the payroll staff themselves picked things up from there.
You can immediately see the difference between this kind of fixed-term fixed-outcome project and an EMR implementation.
First up, oftentimes with smaller implementations such as payroll we are not talking about truly transformational change that goes across the organisation. There’s lots of talk these days about transformational change, but in the health environment it’s only truly relevant when it impacts clinicians in a big way.
Secondly, and most importantly, the simpler implementations are mainly ICT projects. They can be run by non-health people, and often are. The main skill needed in your project manager is project management.
This traditional ICT model may even work for implementing departmental clinical systems, such as PACS/RIS or even ICU systems. Once they are deployed, that should be it until the next upgrade. But clearly it does not work for EMR.