Examining Workflow Problems and Developing Sustainable Corrections
A denial rate suddenly rises. An automated posting queue starts generating hundreds of exceptions. A payer adjustment keeps reappearing after staff correct it. Each problem creates additional work, but the visible error does not necessarily explain what caused it.
Root-cause analysis (RCA) is a structured way to investigate those failures. Process improvement takes the evidence further by testing changes, assigning responsibility, and checking whether the problem actually stops. For revenue cycle teams, the goal isn't simply to close an exception or improve a dashboard number. It's to understand the transaction, control, or workflow that produced the result.
A repair that clears today's exception isn't necessarily a fix for the condition that created it. Useful root-cause work tests competing explanations, identifies where the process failed, and checks whether a corrective control prevents another occurrence.
Follow the Failure Past Its First Symptom
Root-cause analysis investigates the conditions and mechanisms that allowed an error or undesirable outcome to occur. More than one contributing cause may exist. A conclusion should be supported by evidence, not by the first plausible explanation.
Process improvement changes how work is performed, transferred, checked, or monitored. Improvements can reduce errors, rework, delays, financial risk, and unnecessary manual effort. However, faster processing alone does not prove financial accuracy.
A single cause label such as “staff error” often says too little. Investigators should ask what information, system behavior, workload, training, policy, or safeguard shaped the decision. That does not eliminate individual accountability; it makes corrective action specific enough to evaluate.
When to Open an Investigation and Who Participates
Not every incorrect claim needs a formal investigation. Routine errors can often be resolved within authorized workflows. More structured analysis becomes useful when exceptions repeat, involve multiple departments, carry significant financial or compliance risk, or persist despite ordinary correction.
Investigation leadership and authority vary. Analysts can identify, quantify, and document anomalies within their role. Contract interpretation, policy changes, financial adjustments, code corrections, and system configuration may require designated approval. Escalate suspected patient-safety, privacy, or compliance concerns through the organization’s established channels.
Define the Problem Before Investigating the Cause
A useful problem statement identifies the affected population, date range, observed result, expected result, and reliable data source. It avoids assuming causation. For example, “Denials increased because scheduling failed” is a hypothesis, not a problem statement.
Better: “Among 1,200 outpatient claims submitted during September, 96 received a first-pass authorization-related denial, compared with 36 of 1,200 in August, using the same adjudication status definition.” This establishes the observed rate change from 3% to 8%, without assigning blame.
Before measuring change, confirm the unit of analysis. Are you counting unique claims, service lines, encounters, denial events, or dollars? One claim with three denied lines may appear once in a claim-based metric and three times in a line-based metric. Both approaches can be useful, but they answer different questions.
For recognized revenue cycle KPIs, HFMA publishes MAP Keys with specified definitions, inclusions, exclusions, and sources. Locally defined indicators should be labeled as local rather than described as standardized MAP measures. [4]
Gather Evidence and Reconstruct the Actual Workflow
Begin with the source transactions, not only the dashboard. A dashboard can identify a pattern, but it often removes the transaction details needed to explain it. Trace a representative sample from the initiating event through each relevant handoff and final disposition.
- Front-end evidence: registration history, eligibility responses, authorization records, schedule changes, patient and encounter identifiers.
- Billing evidence: charges, codes, units, edits, claim versions, 837 files, 999/277CA acknowledgments, claim submissions, and payer responses.
- Payment evidence: 835 service lines, claim payment amounts, PLBs, EFT deposits, posting logs, adjustment mappings, and account histories.
- Technical evidence: interface transactions, rule versions, configuration changes, bot logs, exception queues, and access-controlled audit histories.
- Control evidence: procedure versions, documented approvals, escalation notes, prior audit results, and reconciliations.
Keep the timeline intact. Record which event happened first, when data moved between systems, and whether a retry, reversal, corrected claim, or reprocessing event occurred. A processing date and a date of service aren't interchangeable. Likewise, a posted adjustment and actual cash recovery are not the same event.
Check whether the data can support a conclusion
Confirm that joined files have compatible levels of detail. A claim header joined to three service lines may repeat its total three times. Do not delete repeated rows or aggregate amounts until you know whether each row represents a separate service, transaction version, reversal, or duplicate. Reconcile source totals before and after transformation.
Practical Investigation Workflow
Step 1: Preserve the baseline
Save the applicable report definition, period, claim or transaction sample, source totals, and current control settings. Document access restrictions and handle protected information according to policy.
Step 2: Map the transaction path
Identify where information begins, where it's transformed, which team owns each step, and what evidence confirms a successful handoff. Distinguish performed work from ordered work and submitted claims from payer-accepted claims.
Step 3: Develop competing hypotheses
List plausible explanations. For rising authorization denials, these may include missing approvals, mismatched service locations, payer-rule changes, or a broken transmission map. Don't treat the most familiar explanation as proven.
Step 4: Test hypotheses against evidence
Compare affected and unaffected examples. Reproduce the behavior in an approved test environment where possible. Check date boundaries, identifiers, code versions, and system audit logs. Record evidence that contradicts each hypothesis.
Step 5: Establish the supported cause or limits
Document which mechanism was observed, which controls failed to detect it, and any uncertainty. If evidence is insufficient, record the issue as unresolved rather than inventing a root cause.
Step 6: Separate containment from lasting correction
Containment may involve holding transactions, manual verification, or correcting affected accounts. A durable fix may require revised mapping, validation logic, workflow design, or supervisory approval.
Step 7: Test a controlled change
Use defined test cases, including normal and exception cases. Confirm that the change solves the targeted problem without causing unexpected side effects. Obtain sign-off according to organizational policy.
Step 8: Monitor and close with evidence
Compare results against baseline, verify at the transaction level, monitor balancing measures, assign ongoing ownership, and retain documentation. Reopen the investigation if the pattern returns.
Worked Case: Authorization Denials After a Location Change
Illustrative scenario: An outpatient department reports a surge in authorization-related denials after services are moved to a new facility. The team suspects staff stopped obtaining authorizations. The available records tell a more specific story.
The investigators review 30 of the September denials. Eighteen claims have an approved authorization for the correct service and date, but the submitted claim carries an obsolete facility identifier. Six lack evidence of timely approval, four have mismatched service details, and two remain inconclusive. Those findings describe the 30-claim review sample, not necessarily every claim in the 96-denial population.
A trace of several affected transactions confirms that a scheduling change updated the facility in the registration screen while the outbound billing feed retained the former identifier. Control testing shows the claim-edit rule did not compare the two facility values. This evidence supports a specific interface/control weakness; it doesn't explain the six claims with missing approvals.
Correction, control and follow-up
The organization identifies affected claim versions, routes corrections or appeals using payer-specific requirements, and approves a mapping correction. Its test set includes old and new facilities, updated schedules, unchanged encounters, and the correct payer-specific authorization rules. The team adds a pre-release comparison for applicable facility identifiers.
The proposed control appears to reduce transmitted mismatches, but it may have increased the number of unresolved holds. Declaring the project finished from the lower denial rate alone would miss that new operational cost. Longer monitoring and like-for-like cohorts are needed before concluding that the improvement is sustained.
Worked Case: An Automation Rule Makes Balances Disappear
Illustrative scenario: An automated posting process completes 200 accounts and reports a 100% technical success rate. An account-level review finds 12 accounts where $40 of insurer payments or patient responsibility was inappropriately adjusted off.
The observed adjustment problem is 12 × $40 = $480 in incorrectly classified balance changes. This is not automatically $480 in lost cash. Some items may be reversible, some may belong to patient responsibility, and others may require further remittance or contract review.
A reviewer compares source ERA codes, claim history, automation rule decisions, and the approved adjustment matrix. Testing reveals that the automation applied a write-off action whenever a balance met an age threshold, without properly excluding a defined category of open transactions. The investigation confirms the rule logic on the reviewed transactions, but a larger scope review is still needed to determine how many historical accounts are affected.
This case illustrates why a completed automated task is not proof of correct accounting. The same method applies to retraction/reapplication loops, unmatched PLBs, duplicate posting, and erroneous patient write-offs, although each requires its own evidence and control design.
Techniques for Exploring Causes
Several common methods help organize information. They are aids to reasoning, not substitutes for proof. Use the simplest method that exposes an important relationship.
For high-risk or cross-functional investigations, use multiple approaches where warranted. A flow map may identify where information changed, while audit logs and records demonstrate whether the change actually caused the claim error.
From Root Cause to Process Improvement
An investigation becomes improvement work only when the proposed action is implemented, measured, and adjusted. The Institute for Healthcare Improvement describes a Model for Improvement that asks what the team wants to accomplish, how it will know change is an improvement, and what change could produce the result. It uses Plan-Do-Study-Act (PDSA) cycles to test and adapt changes. [1]
Choose controls that match the failure
A new checklist or training reminder may be appropriate, but it doesn't automatically solve a broken mapping or poorly scoped automation rule. Control choice should match the mechanism observed, and implementation should follow relevant organizational authority and change-control procedures.
Measure outcomes, process fidelity, and side effects
IHI distinguishes outcome, process, and balancing measures. An outcome could be the authorization denial rate; a process measure could be the proportion of applicable facility identifiers validated before release; a balancing measure could be claims delayed by the new validation hold. Tracking all three helps avoid improving one number at the expense of another. [2]
In a PDSA test, state the prediction in advance, use a controlled group or limited duration when appropriate, compare actual results, then decide whether to adapt, adopt, or abandon the change. Small tests support local learning, not automatic proof that the result will generalize to every facility or payer. [3]
Financial Impact and Investigation Reporting
Financial conclusions deserve the same scrutiny as operational conclusions. A repeated error may create exposure, delays, rework, overpayments, or inaccurate reporting. Those amounts shouldn't be combined into one unsupported “savings” figure.
An illustrative report could show $9,000 flagged, $3,000 validated, $2,100 potentially recoverable, and $1,400 actually collected. Those are separate stages, not additive amounts. If corrected claims remain open or a recovery is offset by later recoupment, the final result must be updated.
The 2025 GAO Green Book offers a useful internal-control framework for designing risk assessment, control activities, information, communication, and monitoring. It establishes standards for federal agencies; healthcare organizations may draw on its concepts without implying it is universally binding on private revenue cycle operations. [5]
Troubleshooting Investigation Failures
Practical Investigation and Improvement Checklist
- Define the observed problem without assuming its cause; document affected population, period, baseline, and financial basis.
- Confirm the report definition, transaction grain, data completeness, and independent reconciliation controls.
- Trace representative affected and unaffected records across handoffs and system histories.
- Identify competing explanations and retain evidence supporting or contradicting each one.
- Describe the validated failure mechanism and document unresolved uncertainties.
- Contain active risk and correct affected transactions only through authorized procedures.
- Choose preventive, detective, corrective, and monitoring controls appropriate to the mechanism.
- Test boundary cases, obtain relevant approvals, and preserve configuration and version history.
- Monitor outcome, process, and balancing measures over comparable periods.
- Distinguish suspected exposure, validated discrepancies, recovery eligibility, and collected cash before reporting impact.
A successful investigation does more than find someone or something to blame. It creates an evidence trail from the original transaction to the confirmed failure, the approved corrective action, and the measurable result. That discipline gives teams a better chance of fixing the process instead of repeatedly correcting the same accounts.
References and Further Learning
These sources support the improvement methodology, measurement, and internal-control concepts used in this guide. Their scope matters: IHI describes improvement methods, HFMA provides revenue cycle metric definitions, and GAO establishes federal internal-control standards. None prescribes a single operating procedure for every private healthcare organization.
References
Additional Learning
Educational Disclaimer
Revenue Cycle Uncovered is an independent educational resource. Content is provided for general informational purposes and does not represent the policies, practices, or positions of any employer or organization. Workflows, payer requirements, regulations, and operational practices may vary. Information should be independently verified when applied to specific situations.