Meditech 6.0 Diary Part 10 – Prioritization And Resource Management

Decisions and conflicting priorities seem to be the norm as our dictionary building gets closer to consolidated testing. We now find ourselves with lots of decisions to make, lessons learned from ancillary system go-lives, and other issues.

Let’s start with lessons learned. We just went live on our ED application. From previous posts you may remember that we chose to go with Medhost instead of Meditech. While that implementation and go-live went very well, there were some key lessons learned that we can apply to the 6.X upgrade.

Perhaps the most notable was how we test interfaces. Most non-Meditech shops are best of breed and very used to dealing with interface testing and support. They often have in-house programmers and may have well over 300-400 interfaces. One of the cost efficiencies of Meditech is that it is an integrated platform that needs few such interfaces. Many Meditech customers do not even have an interface engine and just go point to point for their few interface requirements. Depending on your “Meaningful Use” strategy, that may be changing.

For instance, our site requires numerous interfaces to our practice management system, both to and from Meditech. We also had to program and roll out numerous interfaces to support the data interaction with Medhost. These included but were not limited to ADT, Orders, Results, Billing, and a host of others. While interfacing is common in best of breed shops, this was unique for us and we discovered there were some opportunities with our testing practices and procedures.

Having come from best of breed environments, the usual practice was to do individual interface tests validating flow and basic resulting. In other words, ensuring the formats look right and you are getting what you expected. Then you move to departmental testing, which usually involves only the host and a receiving department. An example of that might be Lab to ED orders and results. Finally you do consolidated testing, where the test group expands to include all departments, usually all in the same room (to improve communication) focusing on all the process components and validating that the interfaces are properly moving patient data. To do this, you take several 100 patient scenarios and electronically move them from registration through discharge (and billing) with various treatment and ancillary orders being played out.

Not having internal interface programmers, we relied more on the vendor side of the house to build and test for us. While they were quite helpful, we did not do the level of Consolidated testing or even individual order testing that would have been done in a best of breed shop, thus we ended up experiencing lots of little problems with individual things like some lab or rad orders or billing not having modifiers. The lesson learned for us is that when we upgrade the interfaces to 6.x, we need to TEST, TEST, TEST before any go-live. The military has a saying, “The more you bleed in training the less you bleed on combat.” Getting things corrected prior to go-live is critical to ensuring a smooth user experience.

Another lesson learned is around resources. We needed to make lots of decisions about what comes first, what we put off, and how much change the organization can absorb at one time, especially in relation to available resources. As a small hospital, we only have 4 Meditech analysts (2 clinical and 2 financial). With one clinical assigned to the Medhost implementation, it really put a strain on the clinical build. Also, the eCW roll out and other projects caused conflicting resource challenges on the financial analysts plus the finance department overall.

If you decide to bring in additional staff or consultants to help, not only do you have that cost to contend with but you may have timing issues as people need to get up to speed on your environment. Looking back, it would have been great to have additional consultants on board, but that is a cost issue and, like smaller hospitals, a luxury we could not afford. So you need to look at your strategy and try to align work and limit interruptions by locking in a no-change period and minimizing routine non-build work.

Also valuable is getting a real project plan with micro tasks (remember that you will have to get this from a consultant, as Meditech does not use PMI tools) for each project you have going and overlay them to see a true picture of the impact on your staff.

If you are using external interface developers, you also need to think about their availability. They often may be working for several clients at one time and it is not unusual for them not to be able to start on a project until 6-8 weeks after contract signing. Additionally, there may be interaction required between them and a third party for such things as obtaining interface specifications or interfacing needing to be jointly completed. An example is that we were working on behalf of a private physician practice to provide an orders results interface (for LAB and Rad) from our end to e-MDs (their practice management system), it took since February to get that work done with e-MDs usually unresponsive or slow in working with us and our interface vendor. Depending on what interfaces you need for your 6.x upgrade, that availability/response can delay your go-live.

You also need to look at organizational impacts. For instance, we are reviewing our go-live strategy around PCI, EMR, and BMV going live at the same time in a big bang method. We are in discussion with Meditech on resource availability — should we split those up and do a slower, more segmented go-live, perhaps by clinical area? Not doing BMV and EMR at the same time would make it easier on the nursing staff, as they could ease into the technology instead of possibly being overwhelmed by needing to use functionality of several new modules at one time. Also, from a support perspective, it would ease some load on both IT and the super-user community.

Regardless of go-live strategy, the implementation and testing will have to be done as planned, and it will not save much in the way of resources until the go-live stage. It is important to note that even if you decide to delay go-live of a module, you will have to work with your Meditech resource to see if that work needs to be completed as outlined in their implementation schedule or if you can delay implementation efforts. For some modules like CPOE, implementation can be moved out, but for others, like BAR, the dictionary build effects other modules and must be done per schedule.

Another organizational impact is that you may find some internal non-IT resources experiencing conflicting priorities. From the Meditech project documentation, it is difficult to identify the true level of effort required from your internal staff by just the task or documentation. Also, that effort might expand or contract from a timeline perspective depending on how knowledgeable the person is who has the assigned task in regard to dictionary build, the information required to do the build, and overall process. Let’s look at an example of this by reviewing what is needed to add the charge description master (CDM) to the dictionary.

To start with, the individual must be knowledgeable about billing practices, organizational billing processes, the existing CDM, and if it needs changes. Many organizations have multiple CDMs which, if you move to an ICD-10 environment, could be challenging. Many argue that with ICD-10 having over 150,000 codes, this could expand existing CDMs to well over that figure if you have facility modifiers or other multiple pricing entries on single codes, and thus a single CDM will be best practice. So a decision point is do you build for today (ICD-9) or tomorrow ICD-10?

Your go-live date might be the deciding factor. Next, your assigned resource must take into consideration if any of the new processes or clinical applications will effect the CDM. For instance, if you only are using three charge codes for ED infusions (I believe Medicare allows 12 different time-based codes) and you are implementing an ED module or ancillary best-of-breed application, will you expand your CDM? If you are implementing office practice management or EMR software at the same time, you may also see changes in the CDM. If you are moving to an ACO model right before or after go-live, that could also require CDM changes.

The end result is that your CDM resource will likely be pulled in several different directions and there may need to be team meetings on such decisions as ACO or ICD-10 impact. Your resource will need to be very knowledgeable on all aspects of billing and billing models as well as the clinical changes (such as adding an ED module) that the 6.x or ancillary implementation will have.

That same resource will also likely be required for implementation tasks in other builds and need to juggle their time or decide what comes first. For us, we had numerous meetings on how to charge and bill in eCW and how that would effect the Magic environment and, later, changes in 6.X. In the end, someone may have to make very difficult decisions on what the priority for that person will be and how that decision might effect the 6.x build, timeline, or other projects.

The decisions made regarding CDM may then effect other vendors or build tasks such as interfaces or dictionary design. Your internal 6.x project manager will need to work with others to ensure that communication is shared and aligned between all the various modules and ancillary applications. While this sounds very easy and intuitive, don’t be fooled into a false sense of security, as it is actually not as easy as one might think. Also, forgetting to share seemingly small or unimportant tidbits of information might cause large delays, especially if the decision crosses multiple applications or interface builds.

In terms of lessons learned, we also completed our hardware selection for nursing and BMV. We had a cart fair and brought in the leading mobile computing and cart vendors to demo their products. We then allowed nursing to vote on which best met their needs and wants. We took the leading two vendors and put their equipment out on the floors for nursing to test and work with.

While this process is time intensive, it yields some excellent results. For instance, it drives nursing buy-in to the hardware they will be using and makes them part of the process. It also points out possible problems and issues in workflow or technology challenges, as was pointed out by our nurses. We thus ended up with different solutions in different clinical areas. We also found some wireless dead spots, which lead to an external wireless survey and additional antenna requirements. While valuable, these processes well exceed the Meditech suggested timeline. Also, you may find numerous delays from the hardware vendors, wireless consultants, or other external resources.

In short, you really need to look not just at your 6.x project but also at your whole Meaningful Use strategy and what you have happening simultaneously. One needs to consider the impact on resources from IT to the end user and how much change can be accepted or driven at one time. One must consider how, if you are implementing more that one application at a time, they interact with each other and effect the resources required to do the build. The bottom line is that there’s a lot to juggle and it could add even greater stress to staff and end users with already full plates.