Meditech 6.0 Diary Part 5 — Don’t Assume

This past month’s journey down the road of our Meditech 6.0 upgrade has been full of surprises. As a matter of fact, there seems to be one surprise after another as we start getting into the training, dictionary reviews, and other implementation tasks. When I finished out last month’s article, I stated that one of the topics for discussion this month would be the Zynx physician order sets. Since they turned out to be a major surprise, let’s start there.

In discussion with Zynx — a Meditech business partner for physician order sets — we were provided two options; the first was their base group of 24 or so order sets, the second was their full blown package of all order sets. A team reviewed their product and several of the order sets and really found them to be useful. They then contracted with Zynx for the basic package, thinking it would be aligned to smaller rural entities.

Maybe we did not understand what was being provided or what was included in the bundle but we ended up with only 16 or so useful order sets. Since most rural entities do not do tertiary care, the order sets pertaining to Abdominal Aortic Aneurysm Repair, Coronary Artery Bypass Graft Surgery, Critical Care Management-Neonatal, Critical Care Management-Pediatric, and Heart Valve Replacement just did not apply. This was a surprise since we had assumed the basic bundle was more aligned to smaller rural entities. We had subsequent discussion with Zynx customer representatives on this, but they stressed they did not have a bundle for small hospitals and that they only offered a basic bundle or all inclusive bundles. We found this interesting since their sales force focused on how their product would really benefit smaller rural entities. Call me silly, but if one can only use two thirds or so of a product, it is less than of benefit. One would think that since the Meditech products are geared towards smaller entities, they would bring in business partners who can be of use in such an environment. Caveat emptor.

Also stated in December’s article is that we were sending the IT staff to training. We sent two clinical analysts, one financial analyst, and a Microsoft AD/Server Administration person. Lessons learned were that user management and printer management is extremely different in the 6.0 environment. Also how 6.0 plays and is supported by Meditech in the thin client or Citrix world has the possibility of being very challenging. No surprise there, since the 6.0 product is very AD centric.

The surprise came in the dictionary training portion. The trainer, when going into depth on some of the dictionary build, stated there was a cause-and-effect aspect as to how the dictionary was set up and built, regarding its interaction with other modules. When we asked what that was or if we could see the screens in the other modules, the answer was “No; we would get that in the training phase of those modules.” The problem is that different people would be in that training. From the Meditech perspective, that means people going to the first dictionary training need to come back and tell the other group exactly what to look out for, then come back to discuss those issues with the first group so that the dictionary can be properly configured for maximum downstream functionality. An example or two of this is that there are certain dictionaries in the ITS module that effect PCS, or how BAR is set up can effect billing and how you will need to set up PCM later.

I guess this goes back to the whole Meditech training strategy mentioned in my pervious postings, namely that if you want a total overview of the module and a cause-and-effect educational program of the dictionary interaction and downstream impacts, you have to go to a third-party consultant. Honestly I am not sure why the siloed approach is so ingrained into the Meditech process. Maybe I don’t fully understand their business strategy, but it seems that an educational overview or training approach is critical for customers to fully understand the impact of some of their configuration decisions. Additionally if you are a new Meditech customer, how are you to know to add the cost of third-party training and configuration consultants to the overall budget of the project?

I have heard from other consultants that one of the key assumptions that Meditech makes on the upgrade is that you fully understand your system today and what you want it to look like tomorrow. Yet it seems Meditech does little to fully help the customer get a good holistic picture of what tomorrow should look like, let alone discuss best practices. In discussion with a Meditech representative on this, they asked if it was an invalid expectation on their part to assume we fully understood everything about our system today and why it was set up the way it was.

I was surprised to hear that question and had to explain that, at least from my perspective, it was an invalid expectation on their part, as often Meditech systems were set up (like ours) 10-plus years ago, or more, and that many of the people having the institutional knowledge capital around why things were set up the way they are have left or been overcome by events. Also that, in many cases, they are the way they are not by any real choice, but that it would have been too problematic, costly, or challenging to change them. Realistically, how many hospitals go back in and fully restructure their Meditech products once installed?

This is a good lead-in to another lesson learned. During the sales cycle, and according to most of the consultants I spoke with, the message was that the upgrade needs to be looked at as a new or re-install and not an upgrade. That it is not the message coming out of training. As a matter of fact (this was also validated by our overview consultant), Meditech has changed its implementation approach a bit. We were previously told to do a lot of dictionary clean-up. Now the message is that all the dictionaries will be brought over and need to be rebuilt in the 6.0 environment, cleaned-up there, or have crosswalk tables built for how you want them to look.

Let me explain with an example. If you have a dirty or miss-structured user dictionary that you want to rebuild, you need to bring it over in its entirety to the 6.0 environment where it gets combined with the provider dictionary into the new “persons” dictionary, and you can clean it from there. If you, however, chose to totally redo something like the user naming conventions, you may have to build a crosswalk table to map the old users to the new names. All this can get somewhat complicated. Not being a Meditech analyst, I suggest discussions with a good consultant or Meditech trainer around what you will need to do in your environment. Just don’t be surprised if it is not as clean as you thought it would be or ends up requiring other discussions.

Also, another surprise was learning in training that none of the FOCUS created reports will come across to 6.0, so they will all have to be rebuilt. One of our consultant also shared with me that it is possible we are not likely to see any 6.0 customization unless it is legislatively driven Federal or State requirements, and that if State-driven, it would be rolled out to all 6.0 customers, and those who didn’t need it would have to just not use it. I have not been able to verify that information with Meditech as of yet. I also received an email from another site that asked not to be cited as a source so that their relationship with Meditech would not be impacted, but basically the message was that statistical reporting was a challenge. “The new Report Designer is much more difficult to use than writing NPR reports, if you can believe it!” I will report on our experience with that closer to go-live.

Since we are on the topic, let’s discuss surprise cost a bit. As a CIO, two of my favorite KLAS questions are, “Did the vendor nickel and dime you?” and “Were there no surprises?” I think the Meditech approach is very nickel and dime. For instance, while they embed some language in the contract — such as that indicating you will pay for some Webex-related training costs (not the content or actually training) — they really don’t define what that will be. Suddenly, you get this surprise call or email from their Webex partner and are informed they need several thousand dollars to set up the Webex training sessions for your teams. Well, maybe I am off-base here, but if a company is providing a fixed-fee implementation, you would think they’d know what the Webex costs should be and embed that into the overall contract, then pass it back through invisibly to the customer. This would help them budget better, capitalize the training, and not have to try to anticipate what other costs there would be. More to the point, in over 15 years of working in best-of-breed environments with all manner of vendors, I have never been charged to attend a Webex training session once having paid for the content. The only time I paid any Webex costs was when we were the providing or originating entity.

The same can be true of really needing outside consultants. It would have been so much more effective and less frustrating to know up front that you should engage outside or third-party consultants for specific information or assistance. That way, it can be planned and budgeted for. Nothing is worse than finding this out at the last second, then having to scramble to find the resource or go back to find the funding. I can easily see how a Meditech implementation could be care-limiting for some CIOs.

The final surprise was that all the third-party companies that are approaching me start their calls by saying they are “the Meditech business partner” for this or that, especially in the document archiving area. I have to go back to Meditech and ask, “What do you use this company for and do I need them?” I don’t know if Meditech sold their customer list or what. It is very frustrating though and I wonder why I’ve contracted with Meditech for scanning and archiving if I need a third party.

On the plus side, our third-party consultant states the Meditech scanning and archiving product is actually very robust and functional, that with creativity and some out-of-the-box thinking it can be integrated into non-clinical processes and has lots of metafile tags that can be used in document identification. The downside is that, most likely, when Meditech estimated disk space they probably only looked at scanning and archiving in the clinical areas with black and white documents and estimated minimum usage and disk space requirements. Having implemented robust best-of-breed document management solutions, I can tell you that the one thing always under-estimated is the disk sizing needs. On the plus side, disk is cheap if you have the rack and tray capability to expand a SAN or NAS simply by adding more disk. It may be an area you want to focus some pre-sales or at least pre-implementation effort to explore ways to really get the most out of this module.

Well that wraps things up for this month. Next month, we will have completed pre-dictionary meetings with our third-party consultant. Also, will have started sending people to dictionary training and will hopefully have more information on specific dictionary factors to consider. As always, thanks for all the notes and calls. I appreciate the feedback and am always happy to answer questions.