One-on-One With Healthia Consulting VP Jonathan Thompson, Part I

A growing number of hospitals are now beginning their second cycle of EMR implementations. But migrating from one vendor to another can be daunting. Healthcare Informatics editor Daphne Lawrence recently talked with Jonathan Thompson, a vice president at Minneapolis-based Healthia Consulting, about his experience with migrations, and his recommendations for an easier transition.

DL: Is switching enterprise systems something you’re seeing more of these days?

JT: There are several folks moving from a legacy enterprise to a brand new EMR--they put the last screw in one implementation and statt another. It’s happening with different vendors.

JT: The question every CIO should ask themselves first is, “What’s driving the decision?” Because that defines where you start. Why has the decision been made and what’s the benefit realization? What are the real issues behind it? Is it around, clinical, financial or organizational goals? Reaching out to community docs? I think functionality is a key driver — certainly from a clinical standpoint.

In particular, integrated EMRs have different benefits. If it’s a clinical or financial or organizational goal to expand into the community, you really have to define what’s your key driver. Some we’re working for right now have the community physician at the top of the list because of the relaxation of the Stark laws. So that’s really driving them to adjust their strategy in this area.

JT: If you’re a hospital concerned about keeping market share in the community and getting referrals by physician groups, that’s going to drive where you start and what your key priorities are. So you will start with your affiliated ambulatory strategy.

DL: How do you achieve lift-off?

JT: Key foundational items you have to have in place are high level planning around your timeline and scope. The high level planning is the high-level IT organization and the new vendor of choice and some of the current vendor. All three are stakeholders in the transition. The CIO ultimately has accountability for it, but certainly in that IT organization, there will be an IT project director who has accountability for it. With the legacy discussion in that planning, there is ownership from the legacy application standpoint and the new vendor. All three have accountability in that planning discussion. You can’t implement the new without understanding where we’re at with the old.

Ultimately the plan needs to be owned and driven by the CIO and the IT organization, with involvement from the operational stakeholders as well. The vendors are advisors and partners in the migration. There is opportunity to leverage third party knowledge (consultants) that have knowledge of both systems. But the ownership really resides within the hospital.

JT: There are key issues that need to be discussed early on in the process and one of those is change management. That’s one topic that’s bubbled up in every migration I’ve done, and that’s “how do you get the IT organization and also the operational folks, physician groups and revenue cycle people, bought in and up to speed on why are we doing this and how are we doing this?” Get the communication messages consistent and relevant to the point of project from the very start throughout the lifecycle of it.

Another key topic is the structure. You need to align the organization differently when you’re doing a migration. The organization needs to take into consideration the support of legacy applications and the implementation of the new applications. There’s a significant need to keep the engine running on the current train and keep this parallel track running. At some point the engineers hop over to the new train and you’re on a different path. But you’ve got to keep the old running.

DL: And how long is that?

JT: It depends on your project approach and timeline and structure. One system we’re working with is focused on one-year increments. So one year on revenue cycle, one year focused on clinical apps, and another year or maybe less on ancillaries and some of the specialties. That seems to be a typical timeframe. I think organizations are typically doing this in a three-year timeframe. It’s an incremental cutover. During that year you’re running dual systems. You run it out and you’re fully converted and you start with the next component, and by the end of that year you’re converted. It’s a very delicate balance because you’ve got feet in both worlds, and when you’re talking about clinical applications and process, there’s a lot at stake.

The financials, obviously you have to keep the doors open, but the benefits realization of clinical metrics is that the CNO and CMO will get uptight in a hurry if there isn’t a very clear plan with no holes. The Swiss cheese holes should not line up when you’re doing a conversion, because that’s when people die.

JT: I think that’s the biggest challenge in migrating, is how do you continue access to the legacy data. Typically it’s not all in one place. So how do you get that over and keep it meaningful and clean it up so it’s meaningful in the new application without creating safety issues during that transition period.

JT: The downtime is an issue. Vendors are really working hard to figure out how to do minimal downtime, where you keep it running on a backup and you do your transition and cutover, but ultimately there is a downtime when you transition. So how do you do that with clinical? Well downtimes can be measured in different ways, so the downtime I’m referring to is not a hard downtime where you don’t have access to anything; it’s more of a cutover downtime, change management.

You may have all the data converted, but the downtime is going to consist of, operationally, “oh my gosh, we’re doing it differently now.” And there’s an educational process and a ramp up. The downtime I think is more operational. And there’s intellectual downtime in terms of getting acclimating to the new process. From an IT standpoint, traditional IT professionals think it’s data from point A to point B; and you turn it on and you’re good. Well it doesn’t work like that. Ninety percent of it is the organizational change and how are you going to support the end users and get them to be efficient and effective and avoid the safety issues. It’s more painful going from an EMR to an EMR than going from paper to an EMR.

JT: Two things bubble up in my experience that are always issues. The first is access and security. You can’t test and validate and verify enough. In matrix organizations with confidentiality and HIPAA, security is always an issue. I can’t tell you how many times I’ve been in the command center and you flip on the lights and you’re in the new space and 90 percent of the calls the first day are, “I was supposed to have access to this and I don’t.” Security is a big topic in that conversion.

We recommend that there is a tremendous focus on security from the beginning in defining roles and who has access to what. Every EMR is different. There’s a concept that you give access and it may be a little more, and then you have a process to evaluate post-go live and lower it. The other theory is that if you lock it down and just give people what they need, you’re going to have a lot of issues during go-live. There have to be controls in place and accountability, but giving folks access to do their jobs is critical, especially in the clinical setting. But then ensuring that they have a process in place post go-live, to assess that and really and truly go back to ensure that there are inappropriate places out there. Erring on the side of more access and then pulling it back—when there’s a question, okay, we’ll give them access. And really defining it by functional area.

Part II: Coming Soon