Wow, I can’t believe it’s been almost two months since my last post. And let me apologize for the delay but things have been rather interesting over the last couple of months.
Recently, we looked at some of the “meat” behind your Medical Informatics Committee (MIC), and in past posts discussed communication in general on a project the size of CPOE.
In today’s post, I’d like to discuss communication between you and your vendor. As with any project, the vendor plays an important part in the implementation, learning, and adoption process. During implementation, we usually have a series of visits, training sessions, and conference calls between the team on the ground and vendor. The point of contact for the vendor is typically an implementation specialist or project manager. In the case of CPOE, we had a CPOE specialist dedicated to our project.
The interesting thing is that most of these specialists only understand the full ramifications of their module. The crossover and downstream effects of decisions on the new system are not always known and have grave ramifications in how everything works together. This is especially apparent in the advanced clinical systems that communicate with a number of other systems downstream.
In the case of CPOE, you will have issues in the CPOE system not because the system was implemented incorrectly, but because something wasn’t changed or set up correctly downstream in pharmacy, lab or radiology. This was the case in our CPOE implementation, and it’s very frustrating. Our CPOE specialists were very good at CPOE, but had limited understanding of the downstream systems. As our system rolled out to the physicians, the CPOE system was getting beat up because it wasn’t working correctly, things weren’t named correctly, etc. but, in the end, it had nothing to do with the actually CPOE system itself. These were all downstream problems.
We spent about three months trying to work through issues like this with our vendor and came to the realization that many of the current vendors still have their business set up to work in silos! Lab guys only know lab because there wasn’t a huge need to understand pharmacy, nursing or radiology. That is not the case any more, and we need to start communicating that back upstream to them. In our case, we did.
In the past, vendors have been very successful in the “silo” type of service structure where system knowledge had some overlap between modules, but wasn’t overly apparent or needed at all times. This approach will not work on CPOE; there are just too many moving parts.
In March, we had a call with Meditech to discuss some of these issues and communicate our frustration and pain. At that point, our CPOE system had been live for almost four months and things were moving forward but not as well as we had anticipated. Our team had too many issues to fight and nothing seemed to be moving in the right direction. During that conference call, Meditech asked if we would like to help them with a “strike team” concept they had been working on. Basically, for the CPOE system, they wanted to put together a CPOE, nursing, and pharmacy team to come in and evaluate our systems, listen to our physicians and work together as one unit to get things back on track. For us, that sounded like a fantastic concept so we agreed to beta the process with them.
The first visit of the strike team happened in April and, as the team hit the ground, things started to work better. After making rounds, listening to our clinical caregivers and physicians, the strike team and my team all sat down in the same room and started working together. It was phenomenal!!
As the Meditech pharmacy guy was talking to my pharmacy guy on something, they could hear all the other conversation across all the other systems. If the nursing group said that something wouldn’t work, the pharmacy guys would interject that, ‘It doesn’t work that way but could work this way,’ and discussion then took the direction of using that process to fix the issue.
The process, communication, morale and every other aspect of the project went up tenfold that day. I was amazed at how much work was completed in the first three days of this new process and how much happier our clinical and medical staff was as well. The strike team left and created a report of all the issues we would work on, as well as the ones assigned to them over the next month.
In May, the strike team was back and again met with clinical and medical staff and worked through more issues with them and our team. Because of this shared communication process, our CPOE ordering percentage has gone from about 30% to over 80%. The system is getting better and better every day and my team has a better understanding of the systems, overlap and issues. As well, they continue to have strike team calls to make sure everyone is making the right decision to fix a problem without creating others downstream. Communication has been the key … having the right people at the right time and place all working for a common goal. It has truly been remarkable the last couple of months.
So, first, I’d like to thank Meditech for listening and helping us develop a plan and strategy that worked to fix our problems. Meditech was fantastic in listening to our needs, concerns and issues and really stepped up to be a partner in the process. They took some beatings and we did as well but, in the end, this new communication structure has worked out very well for all of us. Meditech was able to come to the table as a true partner and, for that, we are enthusiastically thankful. The strike team concept, I hope, will be something Meditech builds into the start of their CPOE projects moving forward.
My recommendation to you is simply this: if you are just beginning your CPOE project, talk to your vendor now! Get it in the contract; work with them to develop a strike team approach to start off with during your implementation. It will make a huge difference. If you’ve already started, talk to your vendor about the process and begin having multi-specialty calls with your systems and support teams. During your vendor conference calls, bring in a lab, rad, and other specialist to make sure your bases are covered.
Our implementation showed us that the only way to be successful with these advanced multi-specialty systems is to take the time to get everyone’s voice in the same room. Listen, define, and hammer out the issues. Don’t let your vendor tell you no. Push this process and your outcomes will be much better in the long run. And, if we all push together, maybe, just maybe, our pain can help others down the road implement these same systems better, faster, and more efficiently — all for the greater good of healthcare in our country.