Meditech 6.0 Diary Part 8 — Dictionary Dilemmas

Well, we are knee deep in dictionary build, so this month’s article will focus a lot on Billing/Accounts Receivable (BAR) and Patient Care Services (PCS). As previously stated, we are taking this opportunity to reevaluate all our processes and existing dictionary structure. I will also discuss how the changes we are looking at impact the implementation process.

So to start, let’s discuss the BAR build. Like most hospitals having implemented Magic over 15 years ago, we have changed a lot. We now have more facilities and some have changed names. Room numbers and how rooms are used have also changed. Patient account types and CMS charge master changes have grown our charge master to over 12,000 lines, but not really addressed the ground-up structural change needed by them. User and access has changed from both how access is decided to the complexity of access. The above are just a sample of some areas where we have changed as a company, and from a Magic and process perspective. Once we started to drill into these, we realized the huge impact it would have to change some or all of them as part of the 6.0 build.

For instance, let us look at the facilities dictionary. The first thing I will state is that any facility mnemonic changes will require cross-organizational meetings (and lots of them). The facility naming conventions will have impact not just non-BAR 6.0 users but other systems like, in our case, eCW (the practice management system) in terms of aligning charge and billing data. E-signing and other processes that move providers around will also rely on the facility dictionary data. Another consideration includes: do the mnemonics in the dictionary have to match the real names of buildings or services provided.

Remember, when you set up 6.0 you only really have once chance to set up facilities properly. It is exceeding difficult to go back and change those mnemonics later. If you decide to look at any facility dictionary changes, I would recommend you give yourself lots of time to work through those naming conventions and how they might effect workflow, other systems, and end users. I would also recommend some form of a signoff process to ensure everyone in the organization is in agreement with the end structure.

It also bears mentioning that other non-IT systems like Johnson Controls or Nurse call may rely on the same nomenclature you decide on. In other words, will you be making changes to other systems to keep naming conventions or room number aligned? There may also be legislative impacts to consider, especially in regard to swing beds, ICU usage, and designated med-surge rooms. Also you should consider your reports and where they print, as some reports rely on physician locations or room number, like with lab reports as an example. This is also important since one of the new and positive features of 6.0 is that it can be set-up to color code patients by room or status, such as if they are an observation patient.

The charge-master was another challenge for us. With the CMS changes since 1994, we have grown to over 12,000 line items. It is no wonder that healthcare billing is so complicated … but I digress. Looking strategically at that issue, we had to make a decision to either invest a lot of time in charge-master clean up or in trying to come back and address it later. Ultimately we decided to wait and address later. The biggest reason being the amount of other dictionary tasks already on the finance team’s plate. One interesting thing is that, unlike other industries, IT is one of the few where if you throw money at a problem, it can go away. If a charge-master rebuild is required, you do have the option of saving the time and paying a consultant or service provider like Applied Revenue Analytics to build a new charge-master which can then quickly be uploaded into the dictionary structure.

Another fun endeavor was how to structure each role’s dictionary. To start with, we ran into a “glitch” with the user/provider entry. Under 6.0, all care “providers” are now considered to be a “provider,” which used to be reserved for advanced levels — CRNA, NP, PA as well as MDs. Now, in order for the “type” to display within other modules, RNs, LPNs, WC, Techs, etc must be identified as a provider, but none/few of the linking screens for facility, address, etc. have any connection to the person if not actually a Medical Provider. Once we get the flow of the profiles set up, adding new users will be much easier in 6.0 than in Magic, but the challenge is working through the initial build.

The MIS team is still working on review/redesign of customer defined dictionary fields (CDSs) which need to be done in order to complete the migration. Since all clinical migration has taken place (at least for those dictionaries which support the applications), the users/providers are now ready to be migrated. However, we discovered a discrepancy in what we were told about the mnemonic use in 6.0 which related to how we were using the emp# as the “unique” identifier, since it was perceived from our training session that this would not actually display as a standalone identifier for a user. The lookups would contain the identifier, as well as the name, but we had been told this would otherwise be of no importance. However we found that when we run audit logs in the applications, only the unique identifier is displaying. If anyone is searching for “who done it,” the number will not help. Before we go any further in the build, we need to determine if we should instead use an alpha-type identifier such as first initial, last name or the same setup we currently use for Physicians (the first 3 of last name and first 2 of first name) so that it would be easier to track.

We also had our Patient Care Systems (PCS) training. For the most part, it went well. We are spending a lot of time aligning quality measures to the dictionary build structure. For instance, we are looking at how we deal with the Admission Assessments and how that process translates in a dictionary build. You should also be looking at healthcare regulations specific to your State and involve cross-team membership like from the Quality and Risk module team. All teams should be asking, “Have we missed anything”?

Another good focus is on the standards of care and properly defining the dictionary in both PCS and Q&R for skin monitoring, falls, and proactive reporting or events (wound care section of the build). A lot of time will probably be spent on defining what is mandatory to document on, what you need to document before you can move forward in the user screen, and the use of free text versus drop down menus.

One of the things that become very complex in 6.0 is user access rights. Unlike in Magic where it is easy to make a user access change, remember that in 6.0 those now tie to active directory rights. As the teams continue working on 6.0 dictionaries/access and menus for implementation and dictionary, build team members occasionally find the user access granted for training and use in Magic are not enough for the build. Also menu design is quite different in 6.0 and the “tree” has to be built logically and then attached to a profile which then gets attached to the user. Some staff members are on multiple teams and therefore have jobs defined with yet a different set of access. Getting this right is difficult from the start and has caused some frustration.

In terms of HR and payroll, we received a wrong payroll template to work from. No biggie as we caught it early. I personally was surprised though to find out that HR was actually a two-phase implementation with payroll being the first phase and the actual HR product a second one. While this actually worked out well for us from a timing factor, it was a surprise to find that their timeline in our contract and the ones originally provided to us were “old” versions and wrong. In terms of project management, it was also a surprise that we had data repository tasks due before we had received the web-ex training for that module. Additionally, when something slips from the Meditech side, it is not always effectively communicated to their project coordinator, and task dates do not get realigned for those slippages.

There are two tools which can help you to stay on track for each Meditech 6.0 module. One is located within the 6.0 Meditech program, under the tab of Information Systems — Upgrade Tool (UPT). You should contact your specific application specialist who will walk you through the use of this tool so that you will have a good understanding of what the screen displays, the functionality of the tool and the ability to focus your efforts on the most important tasks in the order they should be addressed.

The second tool is on the Meditech website and it is located under: Customers – Support Tools – CPH 6.0 – Project Tracking. This allows you to run a report for the activity specific to the module which you are leading. This tool outlines the order in which efforts should be focused. Each of these tools is extremely useful. Your applications specialist at Meditech can ensure you have the view that you need in the 6.0 UPT access. Not every module has a UPT developed (PCI, OM and EMR do not; BAR is limited).  If your module doesn’t have the UPT tool, then you’ll need to have a good handle on the Project Tracking process. Along with these tools, we run a weekly report of outstanding tasks and send them to the Meditech project coordinator to discuss during our weekly project call. Yes, I know it seems like we are managing the project, which I guess we are.

Finally I want to discuss Meaningful Use and core vendor, instead of single vendor. I will expound on this a bit more next month, but will leave you with some food for thought. Under the Magic single-vendor approach, we had about 12 point-to-point interfaces. Now with 6.0 — and having made decisions to use other vendors for some specialty services like Medhost for the ED and Mosaiq for Oncology, as well as needing to interface to practice management systems for both clinical and billing data — we will have over 100 interfaces. Since that discussion, as well as registering for Meaningful Use, is rather lengthy, I will address them in the next article or maybe even do a special separate one to provide some things to consider and lessons learned.

Thanks again to all the readers who email or call thanking me for providing these articles, especially those that call to commiserate or share information on their installs. It is always funny to hear, “What you wrote is exactly what we are experiencing here!” So remember, if nothing else, you are not alone in your boat. Your peers doing a 6.0 upgrade are experiencing the same waters. Good luck to all.