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: What’s the other pitfall?
JT: The other pitfall? It seems contradictory to say this but printing is an issue as well. Even though you’re migrating from EMR to EMR there are documents that are going to be printed, like prescriptions. Today prescriptions are printed out of the EMR, hand signed and then handed to the patient. Getting them to the right printer, getting discharge instructions during go live, you want to continue your best practice of educating the patient around what they should be doing when they’re discharged, the reconciled medadmin list, and any follow up exams or procedures that are coming. The info is typically printed. Those discharge instructions during go live often get rerouted or go to a wrong printer--or don’t print at all. Because of the volume of printers and discharge activities, the wires get crossed. The first few days of a go live are spent tracking down ‘where did it go?’ Then you’ve got the privacy factor, for example if the patient was seen for HIV and I hit print but it didn’t print to my printer. OK, we’ve got a problem. Did it go to the front desk, or get thrown out without shredding?
We’re doing a strategy for an ambulatory group that just bought a community hospital. They’re going to tear down the community hospital and build it from the ground up. And part of the expectation is that paperless doesn’t always mean completely paperless. Providing that service to the patient/consumer means providing takeaway things. It’s kind of a key topic in the migration and certainly from a go-live standpoint that’s always an issue. Every implementation I’ve ever been a part of security and printing are the top two issues.
DL: What about the actual data migration? How do CIOs structure their staff for accountability?
JT: CIOs may not have their finger on managing that implementation and the conversion and they may not have their finger on all the data elements that are being migrated. But there has to be accountability to that level. And the way you get accountability is through objective reporting and metrics. I call it the dashboard from the executive management standpoint that has the details coming up from the owners and stakeholders in the key areas. So for example, data migration is a key area in moving from one EMR or the next. There are metrics that are measurable and objective that the CIO should be aware of. Some of the measures might be number of patients and encounters that were in the old system and number in process of converting to the new system. There should be metrics that the CIO is keeping the pulse and should at least be aware of, because there are going to be unknowns. I think the challenge for a CIO is identifying those unknowns more quickly than not, and capture them in a way that you can measure progress to the timeline. The CIO's mechanism for keeping a tab on that is key tools such as a dashboard, or two through a governance and structure that the CIO set and making sure there’s accountability in the groups, the clinical and financial realm from a decision making standpoint.
DL: Do you need to restructure your IT team?
JT: Absolutely! I think the IT team HAS to be restructured from EMR to EMR. Because you’ve got two camps, you’ve got the legacy system to keep the doors open and then the new structure with project managers and implementation specialists who are going to need to be trained. It depends on the vendor, of course, but if they’re going to have accountability for building out and meeting with these operational areas to define new workflow and to define build, that’s one of the questions a CIO should ask right up front: how do I restructure the organization to become successful.
It would have to be very clear accountability to the legacy system and a vertical that is focused on the new. But then there’s a matrix reporting structure as well because one of the key issues is, you’re not going to fire your legacy support team when they’re done You want to bring them into the new, you want to bring them over. So the question is how do you keep that legacy staff engaged in the implementation and keep the lights on with the legacy application. A couple of the organizations we’ve worked with have come to the conclusion that it’s a dual reporting structure for a few of the people in that legacy vertical. Their primary responsibility is resolving issues, keeping the legacy applications operating and ensuring the costumers need are being met. Btu they’re also contributing to the new application development, bringing that legacy application and workflow expertise to the table as subject matter exert. To define the new and also doing some of the build and getting their hands dirty in the build so when the cutover actually happens they immediately go onto the go live support team they go on to resolving issues and being that new application expert. But that’s a big challenge, it’s a new line of thinking for the IT staff that’s been restructured. There a lot of turf wars and thinking they’re going to be left behind.
DL: So how do you resolve that conflict?
JT: It’s really just about over-communicating and ensuring that those folks are involved in the new discussions, but that it’s measured. So if you spent 50 percent of time on legacy and 40 percent on the new, there should be accountability for that. What will happen is those analysts will want to spend more time in the new applications and you’re going to have to pull them back and say you’re going to have to stay focused on the legacy.
DL: this may be an odd question to ask you as a consultant, but what about using consultants in this arena?
JT: One other strategy that consulting organizations have jumped on is hey we can fulfill your legacy support applications while your team move to the new. Consulting groups are pitching it and have dipped their toes in that pool. It works and it doesn’t work. The IT organization still has to have ultimately has to have accountability for that legacy support. It’s very difficult to transition, similar to hiring an IT organization to lead your implementation and all the knowledge remains in the consulting minds and it’s very difficult to extract that and to get the employees up to speed. That’s a bad model. It’s similar on the legacy side, you can’t just farm it all out because of the decisions that have been made, the history, the background. It’s a delicate balance. But there are options and different was to structure the IT organization to make sure you maintain your current level of support and focus on the new implementation.
DL: Any final advice?
JT: The key takeaway is keeping it a partnership model with the new vendor and the legacy vendor and ensuring that there’s candidness in all relationships and clearly defined expectations starting from the contracting phase and implementation phase, and accountability between vendor and IT and organization. As long as you’ve got those things covered you’re OK. CIOs are good at what they do, they’re professional problem solvers.
