When I worked for the military we used to say that we train today so we don’t bleed tomorrow. The same is true in our journey to a Meditech 6.x go-live. Over the past months, I have written 14 articles about our journey to Meditech 6.x. Much of the material has focused on our experiences in transitioning from the Magic to the 6.x product line. Now with less than two months before go-live, the culminations of our efforts are being tested in parallel runs and other testing processes. In terms of a loose analogy — this is the same as the military’s version of training. By finding problems and weaknesses during the parallel runs, it will hopefully reduce the “bleeding” during go-live.
These efforts result in no shortage of lessons learned and realization of things we have yet to tweak or fix before our “G-day” or Go-Live day. In last month’s article, I stressed not to underestimate the level of effort (time) required to get your interfaces all up and tested. I can only re-stress how important it is to take plenty of time to build and test them all. One of the challenges you will have on getting them all completed and up in time is the availability of all parties required to be on regular calls or testing process meetings. You will find it a lot like juggling hot potatoes. Another challenge will be in keeping the various test environments aligned, especially if you are still making changes to your CDM, Meditech Orders sets, or User rights.
While you juggle the Meditech build and testing tasks, you will also need to juggle the testing of interfaces. Here you may find that your testing resources (BAR, LAB, RAD, IT, and other super users or analysts) may already be stretched thin due to continuing dictionary changes, parallel runs, and other testing. If you read my last article, you might remember that I stated you should plan on having 6-10 weeks of testing set aside, per interface. You may have several results or billing interfaces and need to ensure that resources to perform testing on several interfaces at a time are available. As previously stated, we have a separate Gant chart just for interface development and testing. This tool has been invaluable in helping us manage all those resource needs and maintain that critical overview. That having been said, if you have numerous new or duplicate interfaces needing development and testing for your environment, I would suggest doubling the amount of time you have allocated to complete those tasks.
In terms of time allocation, I also recommend having several months available to get through your test claims with your payers. Our experience is that the payers may not be as responsive as you might expect or need them to be. The earlier you can generate test claims and get payer sign off, the better you will be. We also got in a letter from Medicaid that we had not been testing the 5010s with them. You will need time to work with your clearing houses and ensure they are contacting Medicare and Medicaid for you, if that is the process you are using.
Additionally, give yourself lots of time for the BAR conversion. You will likely require several attempts over time, with either your analysts or Meditech needing to address individual problems like Physicians or Charges missing (our last run) and needing to be manually scripted. Early on, I had stated that I heard the Meditech conversion tools were not perfect and require multiple passes and manual intervention. This has definitely proven to be our experience and might cause you to have delays or exceed the time suggested in the Meditech Project Plan.
User access is also not a clean process. We have rebuilt most users from scratch, some numerous times. We still have problems this late in the game with E-signing for some users, especially around co-sign rights. Our analyst’s view on the E-signature set up is that it is pretty much hit and miss. In terms of time drains and delays, do not think that just because you open a task for the Meditech staff the problem will get addressed or fixed in a timely manner. Many of our tasks seem to sit out there for numerous days and even weeks before getting completed. Also, we have numerous open problems that have been worked, or in work queues, for months now.
For those of you planning on using the Meditech Scanning and Archiving Module, our experience also suggest you may wish to build in some time to address the various scanner settings and document settings required to adjust image quality for the more challenging documents, like fetal monitor strips, color paper, or others. Also, you will need to find, purchase, and test a MS WORD add in to address barcoding and true font needs.
Our parallel runs have been very valuable and enlightening. To start with, a fair amount of both analyst and support staff time was required to deal with the 8-plus years of existing hardware we have. Many of the monitors had formatting issues and printing cannot be tested enough for the various report formats you have. Other items we thought we had down, but were caught as problems during the parallel runs. These include, but are not limited to:
- Claims and charge issues
- ED module still active and looking for data even though we will not use that module
- Still some changes required in labels and wrist bands (pay special attention to new-born bands; may also require special printers)
- Test your swing bed processes and documentation
- Lab orders not the same in all modules
- Account updates not coming across in real time
- Personnel: having some problems with employee conversions – department #s have changed for SOME – 4 didn’t come over with the last conversion – correcting
- PHA: problem with AMB orders and home meds – (Meditech is telling us that we need to create order strings for each of the meds for this to work – we disagree as there are way too many variations in drugs and it would be a manual process)
- REG: finding that some providers are being flagged as “no admitting privileges.” (Since all of our active staff have been set to admit priv. We are looking at adding more “specialties” to some )
- ORM: Charges not on patients – (Some because the charges aren’t “in” yet. Some because the process wasn’t followed through completely – charts need to be completed)
- MIS – E-signing. Biggest issue currently is the printed name not displaying after entering pin and filing reports. Working with Meditech on this – there are multiple fields (in different dictionaries) that need to be completed. Also requires multiple filing within UNV when enabling a provider (don’t read physician – Meditech now considers anyone who documents, dictates, etc a provider)
- Hardware: Additional WOW’s and work stations requested. Some hardware that was initially requested is not meeting business or space needs and requires exchange or replacement
Other challenges impacting the time we have left are around the human element of things. For instance, Meditech has assigned us an inordinate number of specialists for the PHA module since we started. We are now on the 5th one. These support changes have created loss of continuity and delay problem resolution. Internally, we have staff that is strung too thin and on too many projects while trying to do their regular work. This has impacted both testing and parallel runs. Culturally it can be challenging to get staff to view the parallel runs as not just a validation process but also as an opportunity to streamline workflow and create efficiencies.
You will also find the closer to go-live the more meetings and conference calls are required. We have daily calls on some of the interfaces and a Project Manager along with me (CIO) is in almost daily teleconferences with some vendor or another on the 6.0 conversion, interfaces, or other issue. You will probably not be surprised as how important good communication is to keep the entire task list moving at the pace required. It can also be another huge resource drain if analysts or staff are required to be on these calls too. As the CIO, you may find yourself feeling like you are herding cats.
It can also take resource cycles if you are using the parallel runs as an opportunity to test your downtime procedures and define new downtime challenges and workflows. While at CHIME, CIOs up on 6.x validated that we can expect much greater downtime than in the Magic world. With point-of-care documentation, CPOE, and beside medication administration being new to the user community, defining downtime processes becomes very critical. You will also likely find they become more reliant on the applications and less understanding of downtimes. Testing these procedures takes both time and resources.
If you are not seeing a pattern here, let me help. We have three months in the Meditech project plan for parallel runs and testing. You will need every minute of these. We are on our third parallel run in four weeks and I am sure we will require several more. Interfaces, hardware, and user availability all are extreme challenges to bring this project in on time. Do not overestimate the availability of your third-party vendors and, if you’re early in the project, may want to do contract addendums to ensure their availability (including penalties) to bring you in on time.
In next month’s article, I will comment on:
- the experience with our continuing parallel runs and how the 6.x environment is playing with non-Meditech application
- what have missed or forgotten
- what our go-live command and incident structure will look like
- what we are doing to manage lead time required on G-day by the third-party vendors
Until then, good luck in your implementations.
Share Your Thoughts
You must be logged in to post a comment.