Meditech 6.0 Diary Part 11 – As Go-Live Nears, Challenges Mount

As we get closer to the planned dual processing testing (scheduled for August), there seems to be no rest for the weary. As you can imagine, we find ourselves busier than ever and discovering minor challenges that need to be overcome. Add to this the implementation of ancillary systems and continued rollout of eCW (Boy, could I write a book on that challenge!), and I often lay awake at night wondering if Meaningful Use has organizations doing more IT than clinical work.

One challenge for us right now is getting the 6.x interfaces up and tested. Those of you on Magic with existing interfaces will have to convert all those to 6.x.This is no small job, and we have a fair number of existing interfaces due to taking a Core Vendor approach over a Single Vendor model. Iatrics is our interface partner, and we have no full time internal interface resources. They assure us that the interfaces will be ready in the next two weeks but it will come down to the wire. A lesson learned from our Medhost and eCW installs is that interface delays are common, and you cannot do enough interface testing.

Thinking back to my best-of-breed environment days, interface development and testing was much more structured and controlled since it was all done in-house and had become a daily or common function. In the Meditech world, many small hospitals have to rely on business partners or external resources to get the job done. This can come with inherent challenges since you actually have little control over the time allocation by those resources, and they are most likely on numerous projects at one time. Also, internally to your organization, the user community may not be familiar with interface testing nor have a structured process for testing in place.

As the IT lead, it is up to the CIO to ensure that both challenges are properly managed. Borrowing testing plans or processes from best-of-breed peers can be a big help in ensuring interface readiness at go-live. Additionally CIOs need to educate users on interfaces, whey they are needed, and how to effectively test so that the user community has a full understanding of what is needed from them and why.

Speaking of challenges, another one we ran across is that the current versions of 6.x do include a module or way to manage swing beds and does not allow for reporting of MDS data to CMS. Interestingly, the advice from Meditech is to move to the free CMS “RAVEN” product which cannot interface to 6.x and will force nurses to work in two separate systems doing manual reconciliations. After much prodding and discussion, we got Meditech to agree to create (at their cost – something you will want to negotiate into your upgrade) a custom interface to MAGIC so that our nurses can at least work in the existing product and do a 6.x reconciliation until the 6.6 release is out which is suppose to have that functionality. Since we need to get off the MAGIC platform for numerous reasons, not the least of which is that we only have 20 months post go-live use of MAGIC, we have contacted Meditech to get an estimated release date for the 6.x product, but have not received an answer as of yet.

Other challenges we continue to work through include the conversion processes not being clean or working the first time. As previously reported I had heard from numerous peer CIOs that the conversion tools are less than perfect and require numerous passes to get correct. You may also find that — like in our HIM conversions — you will find errors or files that will never convert and require manual intervention to resolve. Part of that is due to internal issues like duplicate medical record numbers or other chart deficiencies. The gotcha on this one is that the project plan is tight to start with, but the internal level of effort by your conversion teams could be increased based on how clean your internal data is. For the 6.x project managers out there, I recommend at least doubling the amount of time you allocated to your internal staff in dealing with conversion issues.

Reports continue to be a challenge too. Again, as previously noted, custom reports will not convert into the 6.x environment and need to be rebuilt from scratch. There is no way your internal analysts will have time to rebuild each report prior to go-live. It is therefore critical that the user community fully look at what they needed the custom report for and what key data elements they are seeking, then compare that to the much more robust set of standard reports in 6.x. They also need a change of mindset from focusing on reporting to the 6.x work-list features that can deliver alerts, reminders, and tasks as opposed to the older reporting/task reconciliation processes. Another feature of 6.x that can help reduce the number of reports needing conversion is the sort feature, which has much greater depth and is more finite than in MAGIC.

If report conversion is required, the user community should develop a priority listing which will need to be managed as project tasks by your internal 6.x Project Manager. Depending on the number of analysts with report writing capability, reports requiring conversion, and resource availability, a governance group may have to be convened to manage the prioritization of those tasks. Alternately, this is one of the areas it makes sense to bring in external resources if you have the funding to do so.

Managers and project leads should also not underestimate the time required for the development of new policies and procedures. From a quality/risk and accreditation perspective, it is important to remember that much of the existing workflow will change, especially if you are implementing electronic medication reconciliation and bedside medication management (BMV).Those workflow changes will require review and edit of existing policies and procedures.

One tip is for teams to take on that work, and also create sustainment training documentation as they complete each Meditech assigned task. This should become part of the internal requirement to complete that task. Remember, from the Meditech side, there is only a task to review, update, or create policies and procedures. They do not go into detail nor provide much guidance to you, just expecting you to check the task as completed.

In terms of patient risk, another challenge encountered is that 6.x does not seem to have a way upon discharge to reconcile or even recognize former ambulatory drugs which may not be in the hospital formulary. It lists the medications separately instead of the previous combination drug. A simple example provided by a peer at another hospital is that the patient came in on Prinzide (Combination Lisinopril and HCTZ). Since the hospital does not carry this in the formulary due to cost, while in hospital the patient is given HCTZ and Lisinopril as separate medications. Upon discharge, it is not able to be reconciled easily and essentially it seems that formulary interaction with ambulatory discharge medication and the inpatient formulary interactions are broken/near unusable. One way another 6.x hospital is dealing with this problem is by making a free-text form for discharge medications. We have contacted Meditech on this and requested more information and guidance, but have not heard back from them as of yet (it has only been a few days though).

Maybe that is a point worth noting; when you encounter issues or challenges in your build, do not expect immediate answers. Their resources may be assigned to several customers at a time and not available, as is the case with our PM who is on another go-live. While they may assign backup resources to you, they may not be up to speed on your project or be easily able to jump in. While not unique in the industry, Meaningful Use implementations have definitely put a strain on all vendors, and we are seeing longer than usual lags from almost all of ours.

You may find the same is true of your staff, especially once training starts. To meet the training needs of our small organization, we had to find and resource five additional meeting/training room. Nursing will have most of their staff in 2-3, 4-8 hour training sessions, and that means lots of overtime and other scheduling challenges, the least of which is meeting room availability. In a Webex put on by a 6.x early adopter, they pointed out staff time costs were almost double all other costs combined, including hardware and software licenses.

As we get in the hardware requirements by department for the point-of-care documentation, it is clear we significantly under-budgeted that at $350,000. Between carts, wall mounts, tablets, software licenses (don’t forget Microsoft or M$ as the Unix world calls them) — all required as your model for care delivery changes — it is easy for people to confuse need versus want. As a non-clinician, it is difficult to push back when, “We are saving babies and puppies” becomes the argument of the day. You will need to engage your clinical leadership and have them validate requirements versus wants, and that may include education on 6.x and what the new processes will look like.

In summation, the challenges grow the closer we get to go-live. While many of those include human resource challenges, you will also find budget and system opportunities and frustrations. Don’t be daunted, this is normal and it’s better to bleed during training than during go-live. Projects have their ups and downs, and some vendors manage project deployments better than others.

With Meaningful stretching the whole vendor community thin, you would likely be in the same boat no matter whose application you were deploying. That having been said; project management is the key to keeping you on track. I cannot stress enough that since Meditech has a very challenging project management process, you need to ensure you have one in-house that makes up for vendor challenges, be it Meditech or others that are part of your deployment. Also, it is an internal responsibility to coordinate the efforts of all the various vendors and consultants assigned to 6.x or any system deployment, and a good project management model is core to successful completion.