What process do you have in place to deal with computer processing errors, specifically transactions that appear to process incorrectly or patient data which is not correctly linked? This article discusses how the technology folks deal with problem requests and how the users can better interact with them for an effective business solution.
An example might be a medical insurance payment which did not get the modifier code which was attached to the claim form.
Another example might be patient insurance information which is not linked to the correct insurance company.
In our experience working for medical offices, questions are most often asked about patient and insurance billing, and payments and adjustments.
The question might be "I have two identical transactions for the same patient.
One of them posted correctly and one did not".
What the technical team needs: We begin by clearly identifying the problem, documenting it and defining possible solutions.
This may appear to be one step.
In fact it is not.
Several steps are required which accounts for why you may feel the programmers are being unreasonable in requesting information.
Effective research requires:

• Specific information for several patient records where the known problem(s) exists.
  
• That same information for at least two patients where the same type of transactions were presented and processed with no detectable errors
• If there are no situations where an error condition does not occur, we need to know that.
  Screen shots
• Electronic copies of the transaction files
• Electronic copy of the database.
  

It is important to note in the spirit of good problem solving that if there are three identical transactions, the processing results for each would be identical.
An error on one and not on another indicates there is a difference.
Our job is to find what is different and then deal with it.
The difference may not be easy to identify but there is always something different.
What technical folks look for: If the transactions were provided by an outside service those transactions often vary slightly for a number of reasons.

• One might be the information provided to them differed in a way that appeared to the provider as insignificant or was not noticed.
  
• Another may be the patient record was modified after the information in question was sent to the outside service.
  

In most of these instances the program in question is not at fault.
The problem is usually the data although it could be a different program in the processing cycle which created or modified the data in question.
The resolution is to fix what caused the data to be incorrect.
Another common source of programming problems, simply put is expectations.
The user expects the program to do something it was not designed or programmed to do.
This becomes a business decision.

1. Can the program be modified and if so at what cost?
2. Can the clinic justify that cost based on its effect on the business of the clinic?
3. Is a manual work-around the best option?

Considering this technical view of problem resolution the author hopes you will be better able to manage the reporting and resolution of technical problems relating to patient billing data regardless of where the problem originates.