On Aug. 23 we received our Meditech 6.06 upgrade. The decision to do the upgrade was not an easy one, as the fact that Meditech stated it would require an additional 10 weeks of testing pushed our go live from Oct. 1 of this year to Jan. 1 of next. (but I will discuss that more later). The bottom line is that we did not want to wait nine months or more post go-live to get a major upgrade that is available now. In my past article, I discussed some of the features driving our decision but, for the sake of continuity and understanding, will recap a few of them.
To start with, version 6.06 has code allowing the Meditech application to manage swing beds and provides reporting of MDS data to CMS. For the pre-6.06 version, the advice from Meditech is to move to the free CMS “RAVEN” product which is not able to be interfaced to 6.x and will force nurses to work in two separate systems doing manual reconciliations.
- In the EMR, “The ability to provide legal indicators for all visits.”
- In PCS, “Priority pack includes changes made to the PCS Open Chart, Assessments, Critical Paths, Interventions, Patient Report, and the Patient Care Panel to prevent crashes from occurring.”
- In Lab, “Order and Tissue information appears correctly in edit specimen info. MIC analyzers can be restricted by performing site.”)
These are only a few of over eight pages (3,944 characters) of changes, upgrades, fixes, and new features. We felt that, strategically, we did not want to wait for these enhancements when going live with a product that had enhancements and fixes to known issues available. Those of you looking to go live on version 6.05 or less may wish to delve into the 6.06 enhancements and review the value to your organization of not putting it off until a post go-live upgrade.
While there are some plusses for going live with the 6.06 upgrade, there are unfortunately also lots of negatives to consider. The first is that, per Meditech, the upgrade requires up to 10 weeks of additional testing. If you haven’t started your 6.0 testing yet, the real question is how much of that 10 weeks is duplicate testing you would have already done. We did not get a very detailed or accurate answer to this. Instead, we were guided back to the online testing procedure and tasks required by the upgrade and left to our own devices to figure out which are Canadian (Canton-Potsdam Hospital is a few miles away from the U.S./Canada border), duplicate, or needed to be retested. Much of the upgrade is Canadian specific, so that does help reduce much of the build and testing required.
The next problem was the go-live date. When we originally discussed the option of moving forward with the 6.06 patch, Meditech verbally presented December or February as possible go-live dates. Originally, you may remember, we were slated for an Oct. 1. 2011 go-live but, due to the additional testing required and also the interface development delivery shifts, it was agreed that date would be too aggressive. The week before the upgrade, we were informed that December and February were no longer options, and it would need to be either Jan. 1 or May 1. Obviously we did not want to wait until May, since any momentum the project had would be lost. We tentatively decided on Jan. 1, with the internal understanding that we needed to review the risks associated with that date.
In terms of Jan. 1, the biggest issue is that it is a holiday. Meditech agreed to have their team on site for that go-live and stated support would be available, but we are still unsure what “support” really looks like. Usually during a go-live you have the vendor’s “A” team involved both on-site and behind the scenes. With Jan. 1 being a holiday, we don’t know what the true behind-the-scenes support will look like. Additionally, with Meaningful Use requirements, most hospitals are no longer just single-vendor shops. We have eCW, Medhost, and a host of specialty vendors to consider during a go-live; not the least of which is Iatrics which programs our interfaces.
Also as most CIOs know, there is a different level of support provided at a go-live than just the normal call-in or help desk model. While much of the risk can be mitigated with significant pre go-live testing, it is still uncomfortable and somewhat of a risk to go-live with only limited support, especially if your interface vendor has the interface still on their development side of the house and has not transitioned to normal support yet. Past experience also shows that often during go-live, issues can come up that require a tier 2 or development resource to liaise with other vendors on application or interface issues not necessarily their own.
Traditionally Medhost, Fuji, and eCW, as well as other vendors, are closed between Christmas and New Years. When questioned, these vendors have stated they will not have dedicated account staff available on Jan. 1, but will have their normal on-call support. This requires we have a risk matrix of all interfaces and non-Meditech vendors including information on what kind of support will be available, if any, how likely we are to need that application live on New Year’s Eve (i.e. eCW is an outpatient application, so we will not see the first patient until two days post go-live), and what the impact will be if we have issues with an interface or application and it might take time to resolve due to normal support being unavailable. Since Jan. 1 was just presented to us prior to the upgrade, we are still trying to get many of those questions answered.
Part of the delay in completing our risk assessment is the vendor community needing to check with their senior management on how to respond to our request. Go-lives during a major holiday are rather unusual, and we were very surprised that Meditech presented Jan. 1 as an option.
Another surprise was that, in the Magic environment, we only had about a dozen or so point-to-point interfaces. Between the implementation of specialty systems like eCW practice management and the 6.06 upgrade, combined with Meaningful Use requirements like immunization reports and syndromic surveillance reporting, with 6.06 live we will have over 70 interfaces live. Granted, a great many of those are not required on day one (like immunization reporting), but there are still at least six other key vendors, in addition to Meditech, that we need to consider. Based on the final responses we get from all the parties involved and the outcome of the risk matrix, we may have to revisit the Jan. 1 date but, at least for now, are moving forward with it.
So enough about our go-live date and some of the risks involved, I am sure you are wondering how the actual upgrade went. For the most part, it went very well. Remember, we only have a Magic upgrade to compare to, so can only say that it was easier than the original 6.0 load and conversions. Generally, a separate test ring is created and updates are tested ahead of time, being placed into our system for use. Some of the core problems you might expect are:
- Needed to run Update Client – this was not communicated to us and, as users logged on Wednesday morning, it appeared that the update didn’t happen. Once the client update ran, the system allowed 6.06 to properly display.
- Some users inexplicably disappeared – couldn’t connect to routines/applications they had access to in 6.05. Each one is different and each is still within the applicable access groups as before. Meditech stated they hadn’t seen this previously and the effected applications specialists are investigating this (ADM, PCS and MIS).
- One user had issues even after we totally deleted their log-in and rebuilt them from scratch. With the help of Meditech, we were able to resolve this, although it did take several days.
- Errors when accessing clinical data from the status board in PCS still persists, although the update was supposed to address this.
- Many of the supporting dictionaries have field changes. Since we couldn’t see these prior to the update taking place, these fields were blank and adversely effected some routines – i.e. access to the eMAR. Compounding the problem, help screens did not update to the newest version.
If you are considering the 6.06 update, I would suggest that you might want to suspend training for a few weeks post-upgrade to ensure all problems are resolved. In terms of training, one of the internal things we did is to create a Share Point page with a back-end database for teams to check off their testing requirements. We downloaded from the Meditech site the list of testing tasks (thousands in some cases) and put that into an easier-to-read format with embedded links back to Meditech and status indicators for the user community to manage their testing in an easier to track fashion. This was very well received and seen as much more user friendly than how Meditech presents them.
So, overall, the upgrade was pretty smooth and support was good. On a side note, as you may remember from my last article, we were experiencing a system lock out every night sometime after midnight and often lasting into 4 AM. You may also remember that we had Dell/Perot, our internal system staff, and others fighting this issue, since Meditech stated it had to be an external job running behind the scenes or an OS hardware issue. Well, magically, the problem went away after the 6.06 upgrade and is no longer an issue. If you are experiencing a similar lock up after midnight, I would suggest you reference our issue and solution when dealing with Meditech.
Share Your Thoughts
You must be logged in to post a comment.