Meditech 6.0 Diary Part 7 — Pay Now and Pay Later?

There is an old saying that states, “Be careful what you ask for, you might get it.”

For those who are new to the Meditech contracting model it is important to note that, unlike some other vendors, Meditech’s implementation fees are based on a bundled (not time and materials) approach. In our environment, that meant when we decided not to use the staff scheduling component of the HR module there is no implementation credit, even though it would end up costing us $25,000 if we decided to re-implement that functionality at a later date.

So here is what that looks like: we contract with Meditech for the HR module which includes staff scheduling. They provide a quote of X dollars to implement the HR module, with a significant amount of time to go towards the staff scheduling component. After researching the product fully and already having Kronos, we decide to not implement staff scheduling and request a credit for that portion of the install, since it will free up Meditech assets to be used elsewhere.

Meditech’s stance is that there will be no credit due to their bundled one-cost implementation approach. That having been said, even though we will have paid for not implementing staff scheduling, if we decide to do so later there will be a significant cost. In other words, you will pay for that service twice.

The lesson learned, when contracting with Meditech you really need to fully understand all the modules and sub-modules before signing. Don’t allow yourself to be rushed because, unlike some other best-of-breed vendors, you pay for hours contracted whether you use them or not. That means you really need to lock in what you will be implementing and what you won’t.

OK, enough pre-contract lessons and back to our implementation. We received back the final Magic-to-6.0 dictionary gap analysis and things to watch out for from our 6.0 dictionary consultant. If your remember, we had to get a consultant because Meditech took the stance they don’t advise on gap differences and expected us to know how we wanted to structure the 6.0 dictionary environment. Anyway, there were no real surprises or nuggets of knowledge not already provided during the previous calls or meetings. That is good, in that lots of the knowledge was passed on during the exploration phase of the contract, but also bad because the staff was really hoping for more granular dictionary build guidance.

This goes back though to the whole Meditech implementation model. Remember, they expect the customer to know how they want to set up the dictionaries. Many of our staff have returned from training and stated the training on how to go in and use the product to build dictionaries was good, but that they could have used more guidance on cause and effect of what their decisions to build a dictionary in a certain manner would have on the whole product. That is what Meditech sends you back to your consultants for.

Also, if you are on Magic already, the 6.0 training you receive banks on the assumption that you have implemented Magic before and just need the 6.0 training. In other words, the training is different than what you would get if you have never been a Meditech shop. From staff feedback, this is not a good assumption to make. While most are at least somewhat versed in the use of the application, almost all were not part of an install in the past. For us, Magic was installed around the 1992 timeframe and since that time most of those involved have left the organization. This is something you may want to take into consideration by contracting for the same type of training and implementation services that come with a fresh install into a previously non-Meditech environment. It might cost more, but provide a better install and understanding of the product in the long run.

Ok, more on the build items. We have reached the chicken before the egg stage. The training is structured so that a lot happens simultaneously. This is fine, as long as something does not slip. For instance, you have to have your charge master, GL structure, person dictionary, and insurer dictionary completed before others can do their thing. For instance, even if nursing builds some of their dictionaries (PCS), they cannot run test patients through until the previous dictionaries are completed. Other linkages we have started to see appear include, but are not limited to, Materials impacting OR; Pharmacy builds having impacts on PCS; charge dictionaries having impacts on pharmacy; OR processes having impacts on patient scheduling; and a host of others.

To deal with this communication becomes more and more important due to having separate teams that don’t always know or understand the impact of their build on other teams. Remember that even when in training, if something crosses from one module to another the Meditech stance is “you will get taught that when training in the other module.” The problem is that, for instance, pharmacy staff will not be training in PCS build. So they hit a point where they don’t fully understand the impact some of their decisions may have on other application modules. The solution for us was increasing the frequency of a total group project meeting that was occurring every two weeks to weekly. I cannot stress enough the need for teams to cross communicate and share decision points with each other.

This weekly communication will also ensure that all staff receives the proper access they need for the dictionary structure pathways they will run into when crossing modules. For instance, when Magic was set up, we had pharmacy have access to BAR. The reason being that pharmaceutical prices where hard coded, and it was up to pharmacy to manage that. That is obviously not a best practice. While we are reviewing that and discussing how we want it to function, pharmacy staff would have needed pathway rights to BAR under the existing build. This shows how important it is to ask if things should be done in the future as they had in the past.

Your Magic or C/S upgrade to 6.0 should not just be taking everything you have today and moving it to 6.0, but rather provide an opportunity to review all your current practices and processes, and use a LEAN or a Six Sigma approach to redesign and streamline them to meet today’s healthcare environment. Again, does that sound like an upgrade or a full install?

Having stated the above, remember the Meditech approach is one of least effort and reactive, instead of proactive. For instance, if you want them to review your menu access rights and provide advice (especially for cross module impacts) they will do, so but you need to ask for it.  If you want proactive advice on configuration or set-up beware that, as previously stated, the model is that you bring in outside consultants to help.

To keep consulting costs under control, that means the implementation teams must balance what to take to the consultant partners (before the fact) and what to take to Meditech after the fact. While there is no silver bullet for how best to manage that, a good governance model or oversight team can assist in keeping the costs down. I also think I struggle more with this as the CIO than the rest of my teams. It is my first Meditech install and the process is very unique and so much less collaborative then I am used to from the best-of-breed vendor world.

I also continue to struggle with the Meditech project management model. We have had several instances of meetings and calls being cancelled or moved. When we asked about this, we were reminded that Meditech’s methodology is that the implementation teams are part of “traveling divisions.” That means they are not always dedicated to you or your project and may be on the road. Also, you may get their “B” team.

An example of this for us was the printing resource. We had a meeting scheduled on printing that was moved and, later, we did not get the resource previously assigned. The resource we did get was definitely not up to speed on that function and just basically read to us what he was given from the other resource. End result — he could not answer any of our questions. I’m not sure how ARRA demands are impacting resource availability for best-of-breed vendors but clearly Meditech, while having geared up to meet the industry needs, still has a ways to go to give customers their money’s worth.

We review overdue tasks weekly with Meditech. In some cases, our staff is overdue and, in others, Meditech is. On several occasions, the message has been that Meditech completed the task, but did not update it in their project list due to being a traveling division. This makes it difficult to really note what is overdue and what is not. Perhaps I still don’t fully understand the role of the project coordinator and am expecting project management-based actions when I should not be. I have formally requested an education call to discuss what the role is to better adjust my expectations. I will let you know in my next article if that happened and how it turns out.

That pretty much concludes this month’s lesson. If you only remember one thing, it should be how important the cross-module team communication is and all the cause-and-effect nuances associated with the various dictionary design and builds. Also, a special thanks to the courageous CIOs who continue to reach out to me offering their lessons learned and discussing their implementation issues, so that I can proactively try to adapt them to our installation.