From CentralReach to Paid: A Single Claim's Journey Through Camber
Five points where a routine ABA claim would have been denied or created downstream liability – and how Camber caught every one before submission.
10 min read
What is this Document
Every ABA clinic running CentralReach faces the same structural problem: CentralReach is built for clinical operations – scheduling, session notes, authorizations – not for payer compliance. The data it produces is clinically accurate, but between that data and a clean claim reaching a payer, there are gaps that cost clinics money, time, and audit exposure.
This document follows a hypothetical client's claim on a single date of service – from session to payment – and walks through five specific points where that claim could have been denied or created downstream liability if submitted as CentralReach produced it.
None of these issues arise from a CentralReach bug. All are predictable consequences of submitting clinical data to payers without an intermediate layer that understands both systems. Camber has built its claims management systems from the ground up to overcome these data challenges – resulting in 94%+ of all claims paid on first submission.
The Story of a Common Claim
Evergreen Behavioral Health is a hypothetical ABA company, operating six locations in the Southeast. Like most ABA organizations their size and bigger, CentralReach is the system of record: scheduling, clinical documentation, authorization tracking, provider credentialing, and the billing records that eventually become claims.
On January 15, 2026, a 7-year-old client named Marcus attends his regular session. His RBT, Jordan, delivers a 97153 direct therapy session from 10 AM to 2 PM – four hours, 10 units. His BCBA, Sarah Chen, runs a concurrent 97155 supervision session from 1 PM to 2 PM. Marcus has active authorization from Anthem Blue Cross.
Both sessions happen without incident. Both are clinically appropriate, documented, and supervised. What happens next – between the clinic and Anthem – is where the claim either arrives clean or doesn't.
How Camber Reads CentralReach – and Why It Matters
The average biller connects to one data stream: the billing records queue. When a clinician completes a session note and converts it, CentralReach produces a billing record. That record enters the queue. The biller picks it up. The claim gets built.
Camber reads that queue too. But it also reads three other data streams that, taken together, are what make it possible to catch problems before they become denials.
Scheduling & Appointment Feed
CR tracks every scheduled session. Camber reads this feed continuously, meaning it knows about a session days before the clinician ever converts the note.
Billing Records Queue
The standard feed most billers read – procedure code, units, date of service, place of service, diagnosis codes, and modifiers.
Authorization Records
For each client: the authorization number, authorized service codes, date range, unit limits, and critically, the provider named on the authorization.
Provider Master
Every provider at the clinic: their NPI, taxonomy code, and credential type – enabling cross-referencing at the claim level.
This four-layer view is what makes everything that follows possible. A biller reading only billing records could have missed four of the five issues on Marcus's claim.
The Session Happens, the Note Doesn't
By 10 AM on January 15, Camber already knows Marcus has a scheduled 97153 session with Jordan. It sees the appointment in the scheduling feed: session type, provider, client, time, date of service, facility location.
Jordan runs the session. Sarah completes her concurrent 97155 supervision. But neither session is a billing record yet – both notes are waiting to be completed and converted.
Jordan doesn't finish her note that day. A busy week follows. The note sits unsigned through the entire week and into the weekend.
The average biller reading only the converted billing queue has no idea this session exists. If the note converts outside their sync window, the session falls through entirely. No claim is built. No one notices until someone runs a reconciliation report – potentially weeks later.
Because Camber ingested Marcus's January 15 appointment from the scheduling feed four days ago, it already has a record of this session. The system automatically detects the missing note and creates a Task alerting the RCM team – a full 4 days before Jordan would ultimately complete her documentation.
On Sunday evening, January 19, Jordan finally submits the note. CentralReach converts it into a billing record. When Jordan's converted note appears in the billing records queue, Camber matches it back to the known appointment by appointment ID.
The BCBA 97155 note follows the same path. Both billing records are now matched to their scheduled appointments. The claim build begins.
The Wrong Provider on the Right Session
Here is where the first substantive problem surfaces – and it's the kind that doesn't necessarily trigger an immediate denial, but may later trigger an audit.
CentralReach is configured at Evergreen with "Provider Assigned to Appointment" enabled. This is a common setting – it tells CentralReach to dynamically populate the billing record's provider field using whoever is assigned to the appointment in the schedule. For Marcus's January 15 session, that's Jordan. The billing record names Jordan as the rendering provider.
Jordan is an RBT with a 106S00000X taxonomy code. However, Anthem's authorization for Marcus names Sarah Chen as the treating provider, with a BCBA taxonomy (103K00000X). If this claim goes to Anthem with Jordan's NPI and RBT taxonomy on a 97153, Anthem may actually pay it – but at the wrong rate.
The claim looks closed. Then, six to twelve months later, a retroactive audit surfaces the taxonomy mismatch, and Evergreen is facing a corrected claim resubmission across every session under that authorization. Months of revenue, reopened.
When Camber builds the claim, it joins the billing record to Marcus's linked authorization. The authorization carries Sarah's NPI. The billing record carries Jordan's. For the procedure code 97153, Camber's logic evaluates the combination – an RBT taxonomy on a 97153, against an authorization naming a BCBA – and substitutes Sarah's NPI and taxonomy from the authorization record, so that the claim is built with Sarah as the rendering provider.
A note on scope: this works cleanly when the authorization names a specific BCBA. When an authorization is issued to the clinic organization rather than an individual provider, there's no single source of truth in the auth record. Camber flags that scenario for human review and generates a task for the clinic to assign the rendering provider in CentralReach.
The Concurrent Billing Overlap
Sarah's 97155 (1–2 PM) and Jordan's 97153 (10 AM–2 PM) are scheduled to go out in the same submission batch for Marcus on January 15. Camber's pre-submission check compares session time windows across all service lines for a client in a single batch. The 97155 and the 97153 share a one-hour overlap window.
Concurrent 97153 and 97155 billing for the same client is very common in ABA, but certain payers don't allow for concurrent billing.
Both claims go to Anthem, Anthem denies one or both, and the billing team spends weeks pulling clinical records, writing a medical necessity justification, and filing an appeal – on a session that was perfectly fine from day one.
The system detects the overlap, references the clinic's EHR fee schedule to determine the higher-value code, and splits the 97153 – submitting the non-overlapping portion as billable and holding the overlap.
Since 97155 pays more, the system splits the 97153 into two service lines: 97153 (10 AM–1 PM) is marked as billable and submitted, while 97153 (1 PM–2 PM) is marked as unbillable and not submitted. The 97155 (1 PM–2 PM) is marked as billable and submitted.
Because the submitted claims contain no overlapping time windows, Anthem adjudicates each service line independently. The concurrent billing denial never arises – not because it was appealed, but because the claim structure eliminated the trigger.
The Placeholder Authorization Number
Marcus's Anthem authorization was approved verbally before January 15, but the official authorization number hadn't come through the payer portal yet. Evergreen's billing coordinator entered "PENDING" in the authorization number field in CentralReach – a standard placeholder workflow when waiting on formal documentation.
If this claim reaches Anthem with "PENDING" in box 23, Anthem looks it up, finds no matching authorization, and denies it – prior authorization required. The authorization itself is valid. The sessions are covered. But the claim is denied because of a data entry artifact that no one remembered to update.
How Camber Works
Camber checks every authorization number against a known list of placeholder values at claim build:
Marcus's auth number matches a placeholder value, so the system routes the claim to CLINIC_FIX status – it will not go to the clearinghouse. A task is generated for Evergreen's billing team with the specific session and authorization record so the coordinator knows exactly what to fix.
On January 22, the real number comes through. The coordinator updates CentralReach. She doesn't need to come back into Camber and mark anything complete. Camber monitors the linked authorization record – when it detects that the auth number no longer matches the placeholder list, it automatically deactivates the validation error and advances the claim to READY_FOR_SUBMISSION. The resolution is tied to the data change itself – not to a human remembering a follow-up step.
The MUE Unit Limit
Jordan ran 10 units of 97153 with Marcus on January 15 – a four-hour direct therapy session, clinically documented, supervised, and consistent with Marcus's treatment plan. CentralReach has no rule against it: the billing record reflects 10 units so the claim is built for 10 units.
Anthem has a Medically Unlikely Edit (MUE) limit of 8 units per day for procedure code 97153. This is a payer-specific rule – it doesn't apply universally, and the threshold varies by payer. CentralReach has no payer-specific rules preventing this.
In a manual system, billers commonly miss these payer-specific rules, and are reminded only after the clearinghouse or payer rejects the claim.
Camber runs payer-specific MUE validation rules as part of its pre-submission check. For a claim going to Anthem, the rule for 97153 carries an 8-unit daily cap. The claim has 10. Camber flags it before the claim reaches the clearinghouse.
Evergreen's billing team sees the flag and makes an informed decision: correct the units to 8 on the primary claim, or document medical necessity and route the claim with appropriate supporting documentation. Either way, the decision happens before submission – not in the middle of an active denial.
Submission and Payment
All validation issues are resolved. Sarah Chen is the rendering provider. The concurrent billing overlap is documented and confirmed. The real Anthem authorization number is in CentralReach. The 97153 units are corrected to 8.
Marcus's January 15 claims move to READY_FOR_SUBMISSION.
Camber automatically batches them with the day's other ready claims, generates the EDI 837P file, and transmits to the clearinghouse. Anthem processes the claims on their standard adjudication cycle. An Electronic Remittance Advice comes back. Both the 97153 and the 97155 are paid. The service lines balance. The claims move to FINALIZED.
Five Problems, All Caught Before Submission. Zero Denials.
This is a routine example of how denials can result when there is a gap between data generated and a payer – and that gap is where claims get denied, revenue stalls, and billing teams spend their weeks on rework instead of throughput.
With Camber, Marcus's claim was paid on first submission.
Faster, more predictable cash flow. Less administrative work. A healthier bottom-line.