Meditech 6.0 Diary Part 13 – An Exercise In Timing and Trajectory

As summer moves into fall, we progress from dictionary build to a greater testing focus. For 6.06 Service Release 1 (SR1), which Meditech loaded for us, there are over 8008 Meditech Development Tracking System test scenarios that need to be addressed. Many of these may not apply to your environment, as they may be Canadian specific or related to modules or functionality your site may not be using.

Still, you will end up with several thousand DTS-related testing events to validate. While not difficult, they are significantly time consuming. For instance, one of our staff came in on a Saturday and worked full time only to complete around 120 or so of the over 690 Data Repository (DR) DTSs.

In the past, I have commented that other organizations say staff costs can easily exceed 2 to 3 times the cost of software and hardware combined. Testing will be a large part of that cost. In just generic terms, the cost of completing 8008 DTSs could well exceed $50,000. But it is not just the FTE time in terms of salary. Add to that the loss of productivity or overtime for other staff to take on extra work and that $50,000 can easily double — and that is just the time expended on completing the DTSs. Now expand that to include dictionary building, training, and testing of interfaces, and one can easily grasp how that figure can grow into the millions of dollars.

There is also no easy way to manage the DTSs from the Meditech Website. While they do an excellent job of defining what the DTS is and the procedures a user should follow, they are bundled to reflect a total version or SR upgrade and not site specific or even country specific. In our site, we downloaded much of the information from the web site into a SharePoint format that is easily grouped by module (team focused) and has tracking capability allowing us to easily manage the DTS process. While the individual DTS is listed on the Meditech site as module specific, you will also find that many of the tasks require teams from other modules to test a function in their module. Using a collaborative workplace tool like SharePoint allows teams to assign tasks, leave notes, or provide group-based documentation in a more user friendly manner than how it is presented on the Meditech site.

Another reason such a tool is important is that, like us, you may find that Meditech has loaded an SR level that was already outdated when they did so and so need another before your go-live. In our case, we are hoping to load SR 2 in the November timeframe so that we still have time to test all the DTSs before go-live.

We also have the added challenge of having to test that release while we are in parallel-run mode. It would have been nice if we could have loaded both releases together and completed all the testing at one time, instead of having to do some of it twice. I also find it interesting that it takes weeks to get on the Meditech update calendar and that weekends don’t seem to be an option. One would figure that weekends are the most prime time to do an SR update in a test environment, since most of the users testing or configuring in the test environment are likely to be out and utilization of the system should be at its lowest.

Once this far into your implementation, you might also find that users prefer not to use all the Meditech functionality but rather split that between other 3^rd party vendors. For instance, we were on RL Solutions for quality and risk reporting. After a review of the Meditech Q&R module, it was decided to move to that product. During build, we found that RL Solutions met some functional business needs in a more efficient manner, so a decision was made to keep both and integrate.

These types of decisions are not unique and go to the crux of the age-old systems debate around best-of-breed versus consolidated single-vendor product. In my opinion, there will always be some level of 3^rd party applications in a single-vendor type of an approach and that it’s probably better defined as a core-vendor approach. Look at your core vendor and, if they meet the 80-20 rule, go with them. If not, add in additional solutions. The driver, though, should be that those add-on solutions come with a Return On Investment (ROI) of some type. In other words, there should be measureable system functionality, efficiency, revenue, user satisfaction (adoption), or other gains.

In terms of time impacts, we also had the kick-off meeting for Meaningful Use utilization. Surprisingly, Meditech does assign a resource to help you through understanding Meaningful Use as it relates to the use of their products, and also has a lot of documentation available. Like lots of Meditech processes, there is documentation overload, so having a real person walk you through their tools is a great thing.

Like with most other processes, there are many decision points to go through, including deciding whom at your organization has responsibility for achieving Meaningful Use (remember it is not about the software but getting people to change processes and use the software as required to achieve compliance) and working in a team approach to manage the requirements moving forward. Fully understanding how the application (be it inpatient or ambulatory practice) collects meaningful data points is key in driving user compliance later. This is a time-intensive task as it includes running the Meaningful User reports in the future and working with users to achieve the goals mandated by ARRA.

There is a fighter pilot saying, “timing and nose position is everything.” The same is true when aligning your 3^rd party application to the 6.06 build. You will have to review every system and note whether or not a second test environment is needed. If you are doing billing or test ordering through those systems and have made Charge Description Master (CDM) changes or Order Master changes in 6.06, then the likely answer will be yes. Numerous vendors have told me that the logic in 6.06 is different enough from Magic to have significant impact on the interface configurations, as well as internal setup to their 3^rd party applications. Be it true or not, we are finding that to be a very real cost, both in direct vendor support and in time needed for testing.
Another “nose position” issue is when you can have the vendors start, and ultimately complete, the 3^rd party test builds. Obviously they need to be tested for their own functionality, but to do so you must have completed the Meditech dictionary changes and ported those over into the new test environments. Additionally, there is the timing of when to have the interface ready between the 6.06 test environment and the 3^rd party vendor test systems to allow for fully integrated testing.

The timing of this cannot be stressed enough as, from a project management perspective, you must have all the resources ready in unison for the parties to interact in the testing process. Depending on how many 3^rd party applications or interfaces you have, this may require a lot of testing to be done in a parallel fashion which can negatively impact the clinical units like Lab or Rad from an FTE perspective.

So, in summation, my advice is to look at all the test points early on. Remember Meditech’s project management model will not focus on the timing of 3^rd party interfaces unless they are creating them, and then only from a task perspective, not globally. Again, that falls on the site PM or CIO. Plan out the 3^rd party application and get a good list of all interfaces and flat file transfers early on, then align them on an MS Project Gant Chart or other tool to achieve a full overview of all resources required and how to stagger or stage them accordingly. It will also provide the organization a great FTE cost-projection tool and help explain in advance the FTE testing costs.

I will be at CHIME in October and, should any of my readers have additional questions or wish to plan a one-on-one discussion, I will try and free up time for you. I have already received a couple of requests and ask only that you email me in advance, if possible, to ensure I can dedicate enough time to fully answer any questions you may have.

Hopefully I will see you all at CHIME!