Does Crossing Your Fingers Work?

By Tracy Welsh

How to ensure a successful EHR go-live

Some imagine a go-live much like “War of the Worlds” and others picture the Jetsons zipping thru space traffic without a worry.  Both are true.  Challenges will arise; however, our reaction can prevent a “War of the Worlds.”  This article will describe situations and solutions in three main aspects of the go-live process: 1) security; 2) master file integrity including National Provider Identifier (NPI), mapping and payer information, and 3) training.

Together, these examples will help you prepare for go-live challenges so you can zip through like the Jetsons – or at least reduce some common roadblocks.

Security

It is critical to identify all users and their roles. One of the biggest challenges and frustrations in a go-live is when users do not have the access to do their jobs. Another is to be vulnerable to HIPAA security breaches.

Situation: On a recent Epic go-live, users who previously had authorization to write off claims no longer had the authority. The severity of this error is tremendous; the entire system shuts down until the former settings are restored. It also damages adoption of the new system.
Solution: The solution was to review previous security points used, find the appropriate Epic security points, and then update those settings. While this solution is simple, it is crucial to avoid the situation. When you have entire departments who cannot write off, reverse transactions, update demographics, etc., the process stops in its tracks until is resolved.                                                                                                 

Situation: During one go-live, wrist bands were not printing. The users presumed their requests were not processing, so they re-entered their print requests. Unknown to them, these wrist bands were being sent to the Radiology department, which had their own documents that needed to print. However, when the wrist bands started printing, they kept printing for over three hours – they stopped only when the toner ran out of ink! The biggest concern, of course, was the possible HIPAA violations due to the exposure of confidential patient information to areas and staff that do not have authority to view such information.
Solution:  In this example, the printers were not mapped and tested prior to the go-live. Other issues had come up and had taken priority. The resources designated to review the printer settings a final time were deployed to these last-minute issues.  

Master File Integrity

Master file integrity plays a major role in reducing errors, particularly with SER (Provider) and EAP (Procedure Master File) data. These same data integrity issues arise with missing Auth Numbers, NPI data, Procedure Code Mapping issues, etc.  The information you get out of Epic is only as good as what is put in.                       

Situation:  There are always issues with insurance carriers that do not have their demographics updated to the new system. Claims cannot drop because the system shows an invalid mailing address.  Staff attempts to perform a routine process only to find out that the payer they have billed for years is either not listed in the system or has an incomplete or invalid address.
Solution: A report must be run from the new Provider/Payer Master Files (within Epic) and compared, line by line, with a similar report from the previous system. This data can be converted from Epic into an Excel format for easier review.  This solution is also one that works for NPI problems. We used a side-by-side report of every payer that previously required an auth to be entered into the system to verify which plan needed what information.

Situation: Most payments arrive via the EFT (ERA) format, which means the system must be mapped to process the codes as they are listed in that format. The problem is, when these codes are not correctly mapped to perform various write-off functions, it creates issues.  For example, we had a claim come in from a government payer which the system processed correctly (it took a $50,000 write off). The problem occurred when the partial payment was recouped. The code to reverse the contractual discount was not mapped to reverse the transaction. As such, the first write off stayed on the account. When the second, correct payment arrived, the account was already down to the contractual level because the system failed to reverse the previous transactions. These accounts were showing up with negative balances (some into the six figures)! Then, the accounts were sent for overpayment review. The Overpayment Department found that the claims were not mapped correctly. But what a waste of time and resources!
Solution: We first went back and reviewed the most commonly used codes for the largest payers as identified by client. Then we reviewed the remaining codes and recommended that they update their policy to include deactivation (or deletion) of older codes as those are replaced with new codes. We also recommended that they put in place a Stop Bill for these same deactivated codes, to prevent codes from being billed.

Training

Humans are often overlooked during a new system implementation and go-live.  I say “humans” because most of the system’s success depends on human nature. If people do not trust the system, or know how to use it optimally, they will go back to their old ways or create workarounds which defeats the effectiveness of the system. It also affects morale, which in turn affects productivity, patient service – almost everything.

Users need to be involved, and become comfortable with the system before go-live. Involve them in testing: poor test results are often the result of not including enough end users, therefore missing workflows. These shareholders also need to be very heavily involved in both the development of the training platform and with the actual documents themselves. This may seem obvious, but it can be difficult given users’ schedules and obligations.

Situation: During a recent go-live, we found a large number of claims where the Pt class incorrectly changed from IP to OBS; this was done by the system, as IP charges did not post. The root causes of the posting issues were related to front-end Charge Entry errors, such as not closing out the encounter, not completing the coding section, etc. However, either through auto system actions or user actions, the claims were allowed to process through the system.
Solution: The resolution was staff training and a review of security points to ensure staff was no longer able to force these incomplete claims thru the system.

Situation:  The Epic SmartText/SmartPhrase/SmartLists/SmartLlinks verbiage did not match up to what end users were used to and the letters were not constructed as needed.
Solution:  First, a review was performed of each Smart Text Letter, Smart Phrase, etc. to correct the missing/changed data. Then we dove deeper to find the root cause. In this case, the root cause was insufficient end user feedback. The end users (from Reg Clerks to doctors) were asked for feedback, but only on the highest level. This did not include the feedback that would have ensured that a standard collection letter will be the same on the new system as it was on the old. Training was provided, along with highly publicized avenues for end users to ask for assistance.

Training is often too cumbersome for users. Huge binders full of good information are put on shelves; two to four-page “cheat sheets” are more useful. Another way to train end users is to sit with each person for at least 15 minutes or longer to go over any questions or basic functionality. The more involved the end users are with training, the more likely we are to have desirable outcome. 

The bottom line is that the more you anticipate the challenges, the more you’ll feel like George Jetson. And that’s a good thing.