Headway bills insurance on behalf of therapists. That’s a critical part of our value proposition to providers and patients: we deal with insurance so they don’t have to. Having a claim denied is a stressful experience for the patient, and in situations where we cover the cost of unpaid claims, it’s a drain on Headway’s resources.
Sometimes, claims are denied for reasons that are out of our control, but often there’s something we can fix: a problem at the clearinghouse that routes claims to insurers, for example, or an invalid field.
Initially, we built a classifier that maps every unpaid claim to a bucket based on signals that describe why it failed. Each bucket then turned into a workflow for fixing the root cause, if it was under our control, and we prioritized the biggest buckets.
But we found ourselves with unmapped claims that we could not easily capture with our existing signals. With the volume of unmapped claims, and the subsequent collections loss, growing in step with our patient population, we needed a better solution for identifying and addressing the root causes of claims that were either denied (adjudicated and then denied) or rejected (rejected upfront by the payer before being adjudicated).
In this article, we’ll explain how we built a human-in-the-loop AI flow that enabled us to reduce collections loss due to claims that were rejected or denied for reasons we could not identify by approximately two percentage points. This represents more accurate payments for Headway, but more importantly, it helps us ensure patients can focus their time and energy on what matters most: their mental health.
Nearly all unmapped claims were due to problems where AI could help
We started by analyzing unmapped claims to better understand the reasons they were denied. We were surprised to discover that in fact, 95% of our unmapped claims were actually denied for reasons that should have put them into our existing buckets.
Often, it was just a small nuance that made our classifier believe the claim had been denied for a reason other than one we knew about already. Ultimately, we identified four main issues that led to claims being unmapped:
- No signal arrived. Some claims failed before they reached the payer with no information recorded about the nature of the failure.
- Our classifier didn’t identify the signal. For example, we tracked provider eligibility in two places. In some cases, our systems would check one place but not the other, leading to claims processing delays.
- Our classifier couldn’t identify the signal. Payers can respond to claims in multiple ways, but our classifier didn’t understand all of them.
- We hadn’t encoded the signal. In some cases, claims arrived with signals that we knew but hadn’t encoded.
The obvious response was to take these claims we’d just manually mapped and route them into the buckets where established workflows would pick them up. But this wasn’t a realistic long-term strategy: even as we worked through our backlog of unmapped claims, we were watching it regenerate in real time.
We needed a scalable solution for analyzing denied claims that could better identify signals within claims and learn new signals over time as it encountered more claims. It was an obvious use case for AI.
We’re reducing the long tail with a human-in-the-loop agentic classifier that gets smarter over time
Our goal was to build an agentic workflow that, on a recurring basis, analyzed and mapped as many of the unmapped denied claims as possible. We created it using Eddy, the healthcare-safe AI platform we built in-house at Headway.
The workflow is built as a multi-stage loop: a monitor, a diagnosis skill, a human triage gate, an automated build step, and a memory stage. Each stage runs independently and hands off to the next, rather than one agent session doing everything at once.
Critically, key points within the workflow pull in humans: specifically, our claims systems operations team, which has years of experience diagnosing and fixing technical claims issues and has the judgment and context to determine whether a rule makes sense. A too-narrow rule leaves loss on the table, while a too-broad rule captures claims it shouldn’t.
The loop, step by step
Here’s how the loop works:
A dashboard and an automated monitor watch for claims landing in the ‘Unmapped’ bucket.
An agent diagnoses and clusters claims using a skill we built that groups claims according to their root cause and resolution action.
The skill queries multiple tables to enrich claims with data that helps us more accurately identify root causes and resolution actions (so we don’t mistakenly group claims that shouldn’t be grouped together). All claims in a group must share the same resolution action, and groups must clear a size and confidence bar to pass through to the next stage.
An agent triages groups of claims and decides whether the pattern is common enough to justify a permanent rule or is a one-off. It then creates tickets that set up the next action to be taken. Each ticket explains what happened (e.g., we received specific response codes that should map to a bucket) and why. The triage step involves querying additional data to determine what is required to implement a fix.
First human gate. The claims systems operations team accepts, rejects, or adjusts the proposed root cause. They leave a brief note on the triage ticket to inform future agent runs. We rely on Linear tickets that serve as the agent’s context and memory on previous unmapped fixes.
The worker agent builds a fix for each group of claims that share the same solution (and is large enough to merit a fix—some patterns are too narrow to generalize). Specifically, the agent adjusts the logic for placing claims in a bucket so they can be addressed properly.
Meanwhile, the ops team implements an override so in-flight claims stop piling up. In parallel, the agent drafts the rule change to fix the claims and a test to verify, then opens a pull request.
Second human gate. Engineering reviews the pull request, which includes human-readable information on the group of claims and the suggested fix, and runs the test before merging.
Learn, remember, repeat. This is where the workflow turns into a loop: it automatically documents what happened during the run. Patterns that make it through become reference examples, and adjustments made during the human gate become learnings that inform the next run.
Prune. Rules engines tend to grow—you add rules for new patterns and almost never remove rules that no longer matter—and create unnecessary delays and complexity. So each week, the workflow tests rules against recent claims. If a rule produces no matches for a certain period of time, an agent files a ticket to retire it. This change is also picked up by our worker agent to implement the code change.
Improving the patient experience and strengthening our business
Every denied or underpaid claim puts stress on a patient. When a patient has done the hard work of committing to their mental health, the last thing they need is to wonder if the next appointment is worth the trouble. And when we can’t fix a denied claim, we put friction between a person and the care they need to thrive.
So far, we’ve reduced collections loss due to unmapped claims by approximately two percentage points, a new baseline that has held steady over the last few months. Ultimately, our goal is to reduce loss due to unmapped claims to effectively zero. And we view this only as a proof of concept for a broader effort to weave agentic AI throughout our efforts to reduce collections loss.
We’re building a world where claims just work and patients can book with confidence and focus on getting the care they need. If you want to build the systems that make healthcare work better for patients and providers, join us.
