Over the last year and a half, many of you have followed our journey from Magic to 6.x with all its challenges and nuances. It has been a daunting experience and not without its frustrations. If hindsight is 20-20, then hopefully our experiences have helped you. In this article, I will attempt to summarize where we are today and answer the question I keep getting again and again which is, “Would we do it again?”
So here we are 8 months post go-live. As of a month ago, we had over 32 issues with an aging of older than 60 days and some as old as 253. After a meeting with Meditech senior leadership on issues like medication reconciliation, AR still not aligned, and DR still not fully functional 6 months post go-live, they sent out a SWAT team to address many of those issues. That was a very productive engagement and many lingering issues got resolved along with additional education to our user and support community around the functionality of the 6.x product.
All parties involved stated this was a huge benefit and should be part of the normal Meditech implementation program to send a cross-functional team out 6 months post go-live to address lingering issues and assist customers in getting the most out of their product after they are familiar with it. We learned many tips and tricks, and Meditech stepped to the plate creating custom reports and making system recommendations to enhance our efficiency. As stated, it was a highly productive engagement and I recommend all 6.x sites include this in their project plans and contracts.
In terms of lessons learned, the biggest is that, “We didn’t know what we didn’t know.” 6.x was marketed as an upgrade but even Meditech leadership agrees it is a new product and needs to be handled that way. When people (users and support staff) think of an upgrade they tend to view it as a product that functions the same, with just some enhancements. That is like saying a 2012 Corvette is just an enhanced version of 1960 model — outside of them both being cars, nothing is further from the truth. Under the covers, they are light and day different in terms of performance, technology, support required, and capability. The same is true going from Magic to 6.x. Under the covers, they are very different products, and a 6.x implementation needs to be thought of and delivered in the same way you would a totally new Health Information System (HIS) implementation that was migrating you from Magic to a different vendor.
I believe Meditech has a future strategy to help make implementations more successful by handing 6.x migrations as if they were new implementations. Also, they will take a more structured and scripted approach to their implementation. In the past, it has been very much left up to the site on how to build their dictionary structures, but taking a more prescribed approach would really help consistency and successful interoperability of modules.
The level of effort is also equivalent as it would be to implement a different vendor’s HIS. In terms of cost, perhaps the biggest thing we underestimated was FTE cost. In an early adopter presentation, the hospital presenting noted that their FTE cost was 2-3 times what their total software and hardware capital costs were. That was very true for us, and the surprise came post-implementation at the additional FTE costs needed for ongoing support and operations. A couple of examples are that, moving from Magic to 6.x, we went from 9 patients per RN to 8. This was due, in part, to the addition of nursing using medication administration checking, improved data capture of home meds, and the discharge medication reconciliation process. Another one is that support needs have grown immensely from an IT perspective. The 3 RNs working on CPOE look to be a long-term need and, internal to IT, we will be adding additional 6.x financial and clinical analysts.
Another huge unanticipated cost is around reporting. You will have hundreds, if not thousands, of reports that will need to be rewritten. Eight months post go-live, we are still working on our list, and that was after an outside 3rd party vendor assisted us for a 2-month level of effort. Interface support costs and FTE costs are also likely to increase dramatically. While the interface costs are not all directly related to 6.x, indirect costs were added by such factors as choosing to go with a 3rd party ED system, MU requirements, and other initiatives.
We have also had surprise costs associated with hardware upgrades (mostly memory and disk) required by the Meditech server farm. Although we bought exactly what Meditech/Dell Perot scoped, it has proven to be underpowered in real world usage. The level of effort to get through printing during pre-go-live was also a lot more draining that we anticipated.
Yet, for the most part, the users all see an overall benefit in 6.x over Magic. The provider community also has noted some efficiencies and benefits in the 6.x product. Various levels of integrated data points between 6.x, practice management applications, and our ED product has also added to a more consolidated data approach and helped drive the 6.x acceptance. Back to the $100,000 question: “Would we do it again if we knew what we know now?”
I spoke with the good folks at KLAS and several of my peers. The consensus is that about half the CIOs would not have done it again. From my perspective, I think it comes down to 2 things. The first is how much money you have. If, like several of our competitors money is very tight, and you can’t justify the soft benefits then, no, we would not do it again. This is a broad view of a large question though. In my opinion, the cost of 6.x, when everything is said and done, is likely to be competitive with a McKesson, Cerner, or non-Soarian Siemens product. Had we known then what we know now, we might have looked more closely at the competitor products. The driver then becomes more around why you no longer want to stay with Magic? As stated, 6.x is not a Magic upgrade but rather a whole new replacement product.
That having been said, it now is more a strategic discussion than one around finances. For us, the 6.x product is felt to be a market differentiator. To start with, like others, we question whether MEDITECH can effectively support 3 product lines with all the MU enhancements, system improvements, and other challenges on the horizon. Also, even if they can, which is likely to get the bulk of their resources? Additionally, with 6.x being their flagship product, we are hoping to see marketable advantages from going with 6.x. Our leadership noted that even though the implementation went very well, it was exceedingly disruptive and left us reeling. Not sure any of us really can answer if the pain was worth the gain….
In summation, yes we still have lots of nagging little issues. We are still opening over 13 work orders a week, many of which go to development. At least we have stabilized, and the product has gained user acceptance. Meditech support is improving and (although it won’t benefit us) they have new implementation strategies gathered from lessons learned. The product is very different from the old cast iron Magic and, being Microsoft centric, will continue to provide new challenges and lessons needing to be shared across the CIO community. That is the way most new products are, and 6.x is still in its infancy. As such, we are likely to continue to see issues, product changes, and support challenges. On the benefit side of the spectrum, things are much better than they have been — CPOE is rolling out well and on the way to a full adoption, user acceptance is positive and thing are well in the world of IT as far as Meditech is concerned.
I hope you have enjoyed my series on the Magic-to-6.x migration and that I have provided a nugget or 2 of knowledge that helped you with your implementations or decision making. As always, feel free to continue to contact me either here or via my email for specific questions or comments. Thanks for your time in reading these ramblings.