During any implementation of an EHR there are various phases of testing which require participation from all of the teams. These would include Functional Design Testing, Application Testing and Integration Testing. For the Revenue Cycle Teams there are additional testing phases that need to be successfully completed prior to a successful go-live. These include Unit Testing (Mapped Record Testing), Cost Center Assignment Testing, Claims Testing, General Ledger Testing and Remittance and Denial Posting Testing. Additionally, The Revenue Cycle Teams need to coordinate with the clinical applications teams to insure that any changes to the clinical workflows or navigators need to be retested by the Revenue Cycle Teams to insure that the system is performing correctly.
Planning
The testing process is often left to the end of the implementation cycle and as a result the needed time to thoroughly test the system often is compromised. The Revenue Cycle PM can begin planning for the testing at the onset of the project. They can also instill into the team, that an item cannot be marked as completed until the testing of that item is successfully completed.
The planning can start with meeting with the appropriate operational leaders and asking the questions around their current charging strategy and any changes or improvements that they have identified. . A hospital that I worked with had been charging individually for all of the floor stacks items for inpatients in their legacy system. They decided to eliminate the individual floor stock item charging in the new system and adjust the room rates to offset the cost. This strategy, had it not been defined early in the process, would have caused a burden on the teams and the implementation. When these types of changes are taking place, please note that it will change the baselines that are used to track revenue.
The Revenue Cycle PM should create a Charge Master Team that will be tasked with creating and testing the new charge master and fee schedules. The creation of the Charge Master is a long process. In addition, there will be many modifications needed to the file during the course of the project. New items will be added, fees may be changed and revenue may be assigned to different departments. For these reasons, implementation teams often wait to create the Charge Master until as late in the cycle as possible. My recommendation is to begin the creation of the Charge Master at the onset of the project. Create a change process that notifies the team of any changes in the legacy charge master and assign responsibility to the team members for keeping the charge master current. By following this process, during the life cycle of the project, the Charge Master team assumes a direct ownership for the accuracy of the file and this will be a benefit for the post go-live maintenance of the file.
In addition to working with the charge team, the Revenue Cycle PM, along with the Integration PM should work to identify all of the systems that will interface charge records into the billing system. This will allow the planning to begin for the mapped record testing. Meeting should be held with the system administrators of each of the systems to identify the testing expectations that will be required of them. In addition, a preliminary schedule should be created.
Also, at the onset of the project, the Revenue Cycle Team will need to meet with representatives of each of the clinical teams that generate charges and define the testing methodology. The Revenue Cycle Team will start with a base set of navigators and clinical workflows to start the Mapped Record Testing. If they have successfully testing the charge generation of a workflow, they will document it as complete. It may happen that after a workflow has been tested, that a modification to that workflow is made by the clinical teams. Putting a Charging Change Management process in place can provide the needed communication between the teams and the Revenue Cycle Team would know to retest that workflow,
The Revenue Cycle PM should work with the operational Revenue Cycle Director and Billing Managers to obtain test claim scenarios from the legacy systems. These scenarios should be documented to insure that all of the special billing requirements of the organization are thoroughly tested. They should also obtain a suitable number of normal billing scenarios as well. These claims will serve as the backbone for the claims testing.
Functional Testing
Functional Testing is the testing of a single workflow or event in the system. From a billing perspective, I always instruct my teams to take great care in this phase of testing. The billing side of testing quite often does not get the attention or time that it needs during the integration testing process.
The testing is performed by the Analyst responsible for the workflow. This testing must be successfully completed before the workflow can be moved to the Epic Test Environment. Change Management will apply for the movement of the changes from the Build Environment to the Test Environment. Functional testing is iterative and is completed during the build cycle of the project. It is important that the build is completed timely, as any late build will have a negative cascade effect on all future testing. There needs to be a 100% pass rate for all workflows tested before the workflow can be considered as complete. A dashboard should be created to monitor the progress of the Functional Testing by application. The Functional Testing needs to be completed at the end of the Build Phase of the project. For Functional Testing, a sufficient number of scenarios need to be created to thoroughly test the workflow. There should be a positive and negative scenario for each decision point within the workflow.
Unit (Mapped Record Testing) and Cost Center Assignment Testing
Mapped Record Testing is needed to insure that all of the functional data elements in the system are built and functioning correctly. Examples of Mapped Record Testing are creating all of the chargeable records for a specific department from the orderable list or from the navigators. The tester would insure that if Item A was ordered, that the actual charge created was for Item A. They would also verify the automatic Revenue Center Assignment to insure the revenue will get posted to the correct center. The normal guideline for Mapped Record Testing to be completed is that all possible charges for all methods of entry (navigators, flow sheets or interfaces) are tested. This should not be a sampling. This needs to be completed for all orderables and chargeables for all cost centers. As was stated above, spreadsheets are created to track the progress and completion of this testing and change management will help determine what needs to be retested. This testing should begin once the Build Phase is completed. It should take 8-12 weeks to complete depending upon the number of areas going live, it could even take longer. Normally, a small team is created with a Hospital Billing Analyst, a Professional Billing Analyst, a Revenue Integrity Analyst from Finance and an Interface Analyst.
The Cost Center assignment Testing should be a part of the Mapped Record Testing to insure that system is properly crediting the revenue to the correct department. Adding a spreadsheet to the Mapped Record Testing for the verification of the cost center assignment will assist in tracking these transactions.
General Ledger Testing
It is good practice to use the transactions from Mapped Record Testing to test the General Ledger Interface. In addition, transactions relating to all of the payment and adjustment accounts will need to be created and tested.
Often times, this testing is left until just prior to go-live and it is difficult to complete a thorough test cycle. If this process is started when Mapped Record Testing is completing, it should allow adequate time to complete the cycle.
Claims Testing
Claims Testing is done to insure that the claims created using Epic provide the desired results. The testing is performed by the Claims Team. In addition to testing a good cross sample of the day to day claims, all of the special billing scenarios need to be tested. This testing is accomplished by recreating claims from the legacy systems into the Epic Test Environment (removing the PHI) and allowing the Epic system to create the claim and apply any edits. This is an iterative process. This phase starts when System Testing starts and needs to be completed when Integration Testing is completed.
Miscellaneous Testing
The Revenue Cycle Team may be required have the system interface with outside agencies, such as collection agencies and clearinghouses. This testing should be done as a part of the complete application testing to insure that all aspects have been addressed.
Summary
Good planning, adequate time, proper leadership assist in a successful testing process. I always tell my people that any error caught in testing results in at least one less ticket at go-live. In addition, good Mapped Record Testing gives the organization confidence that they are billing compliant.