Meditech 6.0 Diary: Part 2 — Reassessment & Reevaluation

Our journey from Meditech Magic to 6.0 continues in what I will now call month two. In the last posting, I mentioned being a CIO new to the Meditech business model, product lines, and also new to a single vendor model (having lived for 15 years in multi-entity, best-of-breed environments). In the first post, I discussed some of the initial Meditech and Dell/Perot challenges along with our re-evaluating the 6.0 upgrade decision.

After four weeks of meetings and discussions with the vendors, executive staff, and physicians, we have decided to stay the 6.0 upgrade course but continue to evaluate whether to stay with Meditech’s Emergency Department (ED) module or instead go with a best-of-breed ED system. I will discuss the ED decision more in depth later in later on in this article.

Let’s start with examining why six months after the contract signing to go to 6.0 we chose to revisit the decision. First off, when the decision was made, not all options available were put on the table. That factor changed in the months after contract signing and were, if nothing else, worth a serious discussion.

Secondly; we garnered much more information on the upgrade. Some of the information was as simple as fully understanding that the upgrade is not truly an upgrade in the commonly experienced sense of the word. It is more like a reinstall and, hence, would require almost one-year level of effort to just to 6.0 for your existing applications. That’s not counting new modules like CPOE, ER, or Bedside Medication Reconciliation. Finally, drilling into the total level of effort, the reference documentation from Meditech showing 149,000 man-hours of effort was a significant concern.

In reviewing some of the available options, at the time of the decision there was a lot of concern about Magic sunsetting or not being a product Meditech would consider for Meaningful Use. Although Meditech has never sunsetted a product, and had never openly stated they would not commit to supporting Magic as a certified Meaningful Use application, there was lots of concern from the CIO and consultant community around that. After the decision to go to 6.0 was made, Meditech openly announced that Magic would be submitted for certification and be part of their Meaningful Use offering. This prompted the question, “Do we stay with Magic?”

So the $100,000 question on everyone’s mind is probably; “Why go 6.0 and not stay with the Magic platform?” For us, there were numerous reasons. The most important of those was that we felt 6.0 would best align with our corporate strategies. We also felt it would be difficult, based on physician feedback, to drive adoption of CPOE on the Magic platform. We wanted to be an employer of choice for physicians in our service area and are convinced that the need for a new look and feel of the CPOE application (as apposed to the current Magic application) will achieve that. It is also the perception of the evaluation teams that the 6.0 product has improved clinical look, feel, and capability, equating to their strong support of 6.0 over Magic.

Another key driver is that our Magic application was installed in 1994. Since then, we have aligned and adjusted business processes to that dictionary build and core set up. Going to 6.0 would act as a strategic driver to review and redesign all business processes, allowing us to be better positioned and more efficient to handle the changes, pressures, and needs of today’s healthcare environment. This driver is even more critical when looking at how to handle Accountable Care Organizations (ACOs), Home Health, and other changes in financial models hitting healthcare like a hurricane.

In going back to the second reason we revisited the decision — namely all the additional information, like a 149,000 man-hour level of effort — we spent a significant amount of time to document and address each issue. For instance, as the CIO, I personally called 10 other CIOs who are live or right at live on 6.0 and discussed the Meditech documentation and how it related to their actual experience. What I found is that that regardless of size of the organization I surveyed, the level of effort was fairly close at around 30,000 man-hours. Obviously this is still a large number for an “upgrade,” but it is significantly less than the published 149,000 man-hour effort required.

Most of those organizations also took the opportunity to realign their business processes just as we had planned to do. If you think of the 6.0 upgrade as a HIS installation, I think that arguably 30,000 man-hours is not out of line with other industry applications. Internal in-depth discussions, and putting these types of issues into context, helped us overcome the initial reactions driving us to revisit the decision.

A lot of our internal meetings revolved around the impact of allocating 30,000 man-hours of staff to the project; the impact to the budget (yes, we are right in the budget cycle) especially around overtime and stipends; impact to patient care and wait times; total cost of ownership with the new software (additional hardware); and other such topics. Also, we discussed corporate strategy and how 6.0, Magic, or another solution would get us to where we hoped to be.

So why are we still reviewing whether or not to go with the ED module? While there are pros and cons for staying with Meditech; the real issues come down to the clinical functionality and efficiency benefits of an integrated approach over the usability and functionality of a best-of-breed approach. Many hospitals have opted to use 3^rd party best-of-breed ED systems interfaced into Magic, CS, and even 6.0 as a viable approach to gain physician buy-in. Since we contract with an independent ED physician services provider group, that buy-in is extremely important. We have involved them in the decision-making early on and, while their initial buy-in was based on not having options other than the 6.0 ED product, we felt it was important to evaluate all the options. In revisiting the decision, we are heavily considering what our competitors are doing, clinical functionality, physician workflow, implementation efforts, and revenue generating ability.

The preliminary feelings are that while Meditech ED could work, it seems like the Meditech product is still not fully developed, will do little to focus on revenue generation, and may not meet the physicians’ desires. Being a rural hospital with a limited staff, the level of effort to implement the Meditech ED module is fairly significant and, thus, important to consider. Feedback from organizations who are live on the module also indicates that the continued support needed from the analyst or physician champion could be fairly heavy. That is also of concern to us.

In addressing the relationship issues experienced in the last month, Meditech has worked hard to meet our requests and stepped to the plate with additional demos; introduction to the project manager; discussions with myself and their management teams on how they function as a company; and resolution to existing issues. The same type of meetings have happened with Dell/Perot around the hardware issues and deliverables. While I am still not overly delighted with the Meditech project management model or the sole-source Dell/Perot relationship, at least the concerns have been discussed. I do not see these any more or less problematic than issues experienced in the best-of-breed vendor market.

Next month is our true project kick off. Up until now, we have been in the “archiving/clean up” phase of the project. That was a needed effort, even if we had decided to stay with Magic, so we feel it was not time wasted. The slippage we will see due to the hardware issue will have no true impact on the rest of the implementation, so turned out not to be critical either. Of course, if we had experienced better project management, communication, and coordination on the Meditech/Dell side, it might have been avoided altogether.

In my November article, I will share information on the project kick off, install of the hardware like the EMC SAN we purchased for it, initial staffing impacts, and other items of interest. If any of readers have specific topics they would like to see addressed in future months please feel free to email me, and I will work to address them.