Precision practice management

Precision provides medical billing services and ONC certified electronic medical records software to doctors and hospitals in 14 different states. The company uses four different 3rd party Physician Practice Management software platforms to perform billing services on behalf of their physician practice and hospital clients. This includes validation of billing information prior to claim submission as well as follow-up and/or rebill of claims that are rejected or not acknowledged.

The company's performance is judged based on the successful collection of medical claims. Over time, the company has developed an internal process to minimize collection time and maximize collection percentage while increasing the volume of claims that they handle.

This process was developed outside of the billing software as

• billing software does not provide built-in tools for follow-up compatible with the company process,
• the company desires to offer billing services to customers that use different billing platforms and
• developing built-in tools for multiple, legacy and/or proprietary billing programs is not feasible.

The company's process was developed around

• a system for classifying and documenting standard insurance carrier responses known as "rejection codes",
• a system for allocating claims follow up among its staff based on these rejection codes or other claim-related data,
• a system for defining and refining specific actions corresponding to each rejection code, and
• the platform-independent ability to obtain a comma-separated value snapshot report that includes descriptive data of every unpaid claim, including rejection codes.

The company had created scripts to automatically generate these snapshot reports weekly, for each practice. Each report was then filtered, cut, and distributed to different teams inside the organization. This was done manually and with the use of simple macros.

Following the company's process, claims were first filtered out if they were recently billed or for other specific and changing criteria. Next, claims of sufficient age but lacking a rejection code were cut and submitted to the call team. The remaining claims would be filtered by "date last touched" and sufficient age claims would be divided between specialist teams in the company based on the rejection code.

Each team would then work their claim list over the course of the week, documenting the results of their work in both the billing software and the spreadsheet. This duplicate work requirement was an early incentive to improve the system. In addition, over the course of the week, the sheets would grow stale as individual claims may have been paid or rejected since the report was generated.

The time wasted by working stale claims was another incentive to improve the system. As the number of practices and supported billing programs grew, the AR manager was spending more and more time manipulating files and had less time to oversee and improve the process. The time spent by the AR manager and the dependence of the process on a single person was another incentive to improve the system.

Finally, the company desired to add new rejection codes, optimize corresponding actions, and create new filters and specialist teams, but the existing solution was unable to handle these changes. The inability of the existing solution to accommodate the increasing complexity of the process became an enormous incentive to improve the system. The CEO of Precision realized that this process could be drastically improved by commissioning custom workflow software. The goal was to increase employee productivity and improve company performance metrics.

Having previously collaborated on document imaging software development, Precision did not hesitate to retain Mercury Development to develop a custom workflow automation solution that would address their business needs. After conducting several interviews with subject matter experts, Mercury first documented the existing process and workflow, as summarized in the preceding Business Need section. Mercury then met with Precision's CEO and CIO to confirm their vision and capture the remaining requirements.

Mercury's architects and business analysts carefully processed the documentation, vision and additional requirements and created a specification for the AR Interactive (ARI), a client-server solution based on MS SQL and C#.NET. In addition to the ARI client and database, the solution also included an administrative application for managing the workflows and an interface manager for adding new practices. The solution would be 100% HIPAA compliant. It would store data in highly secure data centers with an advanced virtualization infrastructure allowing for fault tolerance, data persistence and consistency. It would use a secure communication channel to ensure that patients' confidential information is never stored on the user side.

The specification was approved and Mercury selected the optimal team from our pool of qualified and experienced project managers, developers and QA engineers.

The solution was a huge success and is an integral part of the company's value proposition. Since 2006, Mercury has continued to optimize and augment the system, which is now on its fourth major release.

Additional releases

• added new functionality like patient statements
• expanded the system to new areas of the business such as pre-collection calls, and
• updated the architecture to take advantage of new database, cloud and SaaS technologies.

Mercury's development and use of automated testing of all business logic has contributed to the high level of quality in an environment of constant development.

The following description of a typical claim life cycle should help illustrate the utility of the software. Prior to the company's involvement with a claim, the physician practice has entered patient demographic and insurance information into their billing software. A patient sees the doctor who records a diagnosis and services. This is entered into the billing software and submitted to an insurance company for payment as a claim.

At this point, the claim is exported into ARI. The ARI gives the insurance company time to pay or reject the claim. If the claim is not paid or rejected for practice- or carrier-specific number of days, the ARI assigns this claim to the Call Staff to ascertain the status from the patient's insurance company. The insurance company rejects the claim.

The caller notes the rejection code in the ARI and is presented with only one option for this specific code: assign to a client representative. The claim immediately appears on the client rep's work screen with the caller's comment, "This claim was rejected because of an incorrect date of birth." The client rep calls the practice or the patient to obtain the correct date of birth, makes the correction and resubmits the claim. The claim is then reassigned to the call staff after the insurance company has had enough time to pay or reject the resubmission. This time, the insurance company indicates that they have made partial payment and have noted the date of this payment.

The call staff notes the payment in the ARI using a different code and selects a workflow option which assigns the claim to the client rep if the payment is posted in due time and back to the call staff if the payment is not received. In this case, the payment posting team processes a lockbox deposit two days later which includes the partial payment. This information flows through to the ARI which immediately moves the claim to the Client Rep work list.

The corresponding Client Rep for this practice determines that this patient is entitled to Medicare benefits, but has not used them and returns the claim to the Explanation of Benefits staff. The EoB team determines that the claim is not eligible for Medicare, and transfers the claim to patient responsibility. This flows through to the ARI which immediately inserts this patient in the statement process.

Subject to rules that are unique to every practice, the patient receives a set number of statements over time. If the patient doesn't pay and the practice has selected this option, the ARI sends the patient custom delinquency letters. If the patient doesn't pay and the practice has selected this option, the claim will be transferred to the pre-collect call team who will call the patient to obtain payment.

The patient picks up the phone and says that they misplaced their statements. The call team notes this in the ARI and queues the patient to receive another statement. After the patient does not pay the bill, the ARI exports this claim along with many others to a collection agency. The ARI continues to track the current status of all claims that are being processed by collection agencies.

The ARI solved the following immediate needs:

• The solution was 100% compatible with the pre-existing "rejection code" process. Although users needed to acclimate to new software, the actions they took to attempt to accelerate claim collection were the same or less complex.
• The solution greatly reduced the complexity of the existing process management. The AR Manager no longer had to spend several days per week working with spreadsheets and was able to use that time on strategic management of the process. Furthermore, the corrected process operation ceased to be dependent on a single person.
• The solution reduced duplicate and unnecessary work. Mercury optimized the workflow rules such that processing of snapshot files took minutes instead of hours. This enabled daily imports of these files eliminating the possibility that a claim was paid but not removed from a work list.
• The solution accommodated customization and added new flexibility. Mercury designed a management interface by which the AR Manager would be easily able to:
  • Add new rejection codes and workflows.
  • Change claim processing rules by practice, insurance carrier and more. This improvement gave the AR Manager new tools to modify the process for the entire organization.
  • Limit rejection codes by user class. This improvement over the existing process dramatically improved the accuracy of the rejection codes while simplifying the workflow of the users.
  • Limit workflows by rejection code. This improvement over the existing process also improved the performance of the system while improving the user experience.