Meditech 6.0 Diary Part 9 – Chickens And Eggs

It is said that timing is everything. This is just as true in our 6.x implementation as elsewhere in life. Also in terms of timing, one can ask what came first: the chicken or the egg. The 6.x version of that same question is what comes first: dictionary build or dictionary team training.

As stated in past articles and agreed to by other CIOs, one of the huge challenges in a Meditech implementation is their lack of a true project management model, along with the fact that they expect the user to know how they want to set the system up without first having been trained on the application or dictionary build. We are running into that dilemma. We either have the option of building dictionaries from scratch or bringing some over from Magic to start the build in 6.x. We are expected to define a dictionary structure even before training, which leads to significant changes post-training. In others words: duplication of effort and people activities in an already tight timeline.

For us, this became a real issue in the BAR deployment. We knew we wanted to change many of the financial dictionaries, since they were first built in 1994, but had not undergone the dictionary training. Per the trainers, we just needed to get key data in to be able to train on, then given time after the training to edit the dictionaries and make them more appropriate to the environment. The problem is that we were already behind in the BAR phase of the deployment and many of the other modules, like PCS and Pharmacy, required the dictionaries to be in place to test their builds and workflows.

Additionally, the Charge Description Master or CDM is a key dictionary component to test orders and charges. We currently have numerous CDMs, having in some cases mirrored them to align with various outpatient practices we own. This model does not work well with how other applications like eCW bill and use the CDM. Additionally, your design needs to be forward focused on ICD-10 and realize that, with 150,000 plus codes, multiple CDMs will be a significant challenge to maintain and keep aligned.

In Roger Neal’s article “Meditech’s Strikeforce Hits a Home Run,” he points out how the dictionary builds all have downstream effects, especially in CPOE. This linkage has really started to become apparent well before CPOE as we enter test patient data in just the core applications. Neal’s observation that Meditech staff has no total overview of the whole product and may not be able to advise you on downstream effects is definitely on track. I will also note that even many Meditech consultants are siloed in their skill sets and don’t have that overall cause and effect understanding. This can mean build, test, rebuild, retest; more rebuild, retest, and so on … you get the idea.

In our timeline, we are scheduled to go into a parallel run at the end of August. Imagine my surprise to find we still have dictionary build training scheduled for the middle of that month. Again, not having a true Project Management Institute-based planning methodology will lead to those kinds of challenges. I used to always gripe about the cost of project managers assigned to application deployments in the best-of-breed environment. I will never again do so, as working with Meditech and their implementation model has just hit home how critical having that resource really is and how it improves the overall success factors in an implementation.

Shifting gears, we finally got through most of our printing challenges. I have feedback from Pennsylvania hospital that printing was one the biggest problems they had in their post go-live environment and how critical it is to test printing for all applications. I can understand this, since printing is very different in 6.x, and we struggled finding Meditech resources that really could help us with our printer set up.

Additionally, we had to redefine all the printer names. They also stated that printing is not the least bit reduced even though one of the drivers is to try to go paperless in clinical areas. With the EHR initiatives driving paperless records and electronic exchanges of data, it is interesting to note how much people still love paper and often print, even when it could be done digitally. I am just as guilty of that, as I like to print contracts and red-line them on paper prior to editing them in Word as track changes. While I am not sure if it is having something tangible in my hand that helps me focus or if I am too used to paper to do without it, I do know I edit better on paper than without it. It’s not surprising then that in the 6.x world printing will continue to be a major factor of workflow.

As you go through your dictionary training and post-build testing, it is important for your team leads to start thinking about user training. While Meditech gives you some base guidelines, ultimately the customer is the one determining how much training is needed, who needs to get training, and how best to structure it. One unplanned cost for us was setting up an additional three IT classrooms with PCs and other equipment just to accommodate user training. That meant 30 PCs and (if your organization is like most) where do you even find three unused rooms large enough to accommodate training. Again, Meditech will not provide defined guidance on how to maximize the user training experience. It is left to the customer who may or may not clearly understand all the training implications and effects.

Along with physical space and hardware, there is also staffing to consider. One California hospital noted that the cost of training staff, OT, up-staffing, and unproductive hours was their largest part of the implementation costs. This needs to be discussed in advance on an executive level as it will impact budget, capital outlay, operational expenses, and even other system functions. (For example: Will you be using a special time & attendance code to capture those 6.x related hours?)

Also, if you do not have cart or hardware standards, you will want to add into that lost productivity figure the costs of having clinical staff attend a hardware fair. Ours happens early in June, with the idea being that clinic staff will be given a voice or vote in selecting their hardware (wireless carts, monitor sizes, bar code scanners, and other point-of-care devices). If you have not deployed medication administration checking the bar coding component of that implementation could effect the employee badges and patient wristbands as well. From a project management perspective, Meditech will not provide much information and assistance on that, so it will behoove you to build that into your internal project plan early on.

Naming conventions and mnemonic changes in dictionaries will also draw out the tasks and testing needing to be done and needs to be backed into your timelines to ensure proper set-up and testing can be accomplished. Again, the chicken before the egg routine in terms of which dictionaries you may need to change mnemonics in. Unfortunately, you may not even realize the necessary changes until after dictionary build has happened and you are in testing phase of the build. Dictionary conversion not coming into 6.x cleanly will also drag out your timelines and increase your level of effort. An example of this is that in our build the language dictionary did not have Spanish in it. MIS came across without vendors and other missing parameters. In NPR, when you pressed the “?” (help key), the pop would crash the application or go into debugger mode. While this was a known problem, it took valuable build time for Meditech to apply the appropriate patches and for us to retest.

Another decision point is whether to use the workload dictionary and cost accounting which apparently is used only in Canada.  It will take time for you to fully understand the functionality of the module and if or how you wish to use it, then how it will merge into existing workflow.

Medical necessity was another challenge for us. Taking a few minutes to view the tutorial online for medical necessity, and then looking at our 6.0 system build, we found that the reason the ITS group is currently not prompted for medical necessity is that the dictionary which drives this functionality is not set up. The dictionary is “MIS > DICTIONARY > FINANCIAL >  BILLING REQUIREMENTS”. Within the billing requirements dictionaries, you will find all of the routines which allow upload of the medical necessity information and designations of account types and financial classes which require medical necessity screening. Once these dictionaries are completed, the user will be prompted — when placing an order — to complete the medical necessity screening for the patient.

In pharmacy, we had definite problems with the drug dictionary upload. We use First Data Bank and it took a few tries to get uploaded correctly. Also, PCS orders for interventions will require close review to ensure such items as oxygen gasses in pulmonary cardiac rehab orders are correctly defined. PCS requires any inpatient intervention order to be built, which can add to the implementation timeline, especially in terms of testing.

We are also implementing a new Quality and Risk module. In terms of project timing, this meant several repeat demos, even post-contract, as staff cycled and to bring up to speed build staff that missed the first demo. Once the application training and dictionary training happens, discussion will be needed between the owner of this application and nursing on how to even use it and build it into workflow.

Another big challenge for us is in the interface world. By moving away from a single vendor approach to a core vendor approach (remember, we have apps like Medhost and eCW) it increased the number of interfaces we have to maintain and test dramatically. Iatric is our interface partner of choice and we use their Easy Connect Plus engine. Iatric, like many vendors, are stretched thin due to all the ARRA work, and there is not only a 4-6 week wait to get a resource assigned, but that resource may be working several projects. Additionally, like Meditech, none of our current Iatric resources seem to have a total overview of what others on their team are working on and we see some duplication of effort. Also, there are challenges associated with coordinating testing in both the Magic environment for today and the 6.x environment as it starts taking shape.

In short, the month has revolved around managing timelines and rework. Dictionary build and training continues to be a chicken and egg approach and I, for one, have concerns about the downstream impacts of the decisions we are making today, especially on the Phase 2 projects like HR, CPOE, and other future modules. While I suppose time will tell, it would be nice to have a resource who fully understands the applications start to finish and could provide definitive guidance on how to ensure that what we are doing today won’t cause us regret tomorrow.