.png)
One insurance change, six systems to update
A parent mentions at pickup that they switched jobs in January and the insurance is different now. Someone writes it down. The new card gets scanned. Everyone feels like the thing was handled.
Three months later you're looking at 40 denied claims across one client, and every one of them is correct according to the information the payer had.
An ABA insurance change workflow exists because one piece of information has to land in six places, and human memory reliably lands it in two.
The six places a change has to reach
The EHR. Clinical records and demographics. This is usually the one that gets updated, because it's where the person who heard the news already works.
The billing system. New payer, plan, member ID, subscriber details, and effective date. Claims generated from stale data look fine on your side and get rejected on theirs.
The clearinghouse. Payer ID mappings and enrollment for that payer. If the new payer isn't set up, claims fail before reaching anyone who can tell you why.
The payer. Confirm the client is actually active with the new plan, and confirm the effective date. Families are often wrong about the date by a few weeks, which is exactly the window where sessions were delivered.
Benefits verification. A full re-verification, not a glance at the card. New plan means new deductible, new copay, new visit limits, and possibly a new prior authorization requirement. SparkzABA's ABA Revenue Cycle Management guide covers how benefits verification fits into the larger revenue workflow.
Authorization. The existing authorization almost never transfers. The new payer needs its own request, and the old authorization still showing remaining units is the trap that makes everything look fine. See why ABA authorizations expire and how clinics can catch them earlier.
What should trigger the checklist
The checklist is useless if it only fires when someone remembers to fire it. Define the triggers explicitly.
A new or updated insurance card, from any source
Any plan change reported by a family, including "I think it's the same company"
January 1 and other plan-year boundaries, for everyone
Medicaid redetermination notices
A secondary policy being added or dropped
Address, name, or custody changes, which affect eligibility matching
A rejection that mentions member ID, subscriber, or coverage
The plan-year boundary is the big one. Most clinics handle individual changes reasonably well and get overwhelmed when 30 families change at once.
A checklist with an owner per item
Six systems with a shared owner means no owner. Assign each line to a role, and put the role on the record.
Each item needs three things: who does it, by when, and a confirmation that it's done. "Updated in billing system, confirmed by AM, Jan 14" closes a line. A checkmark doesn't.
Set a completion deadline in days, not "as soon as possible." Most clinics can close the full list in three to five business days if the work is assigned. Left unassigned, it takes as long as the first denial takes to arrive.
Where the workflow breaks
Services continue while the update is in progress
The sessions don't pause because your data does. Every session delivered between the effective date and the completed update is a claim you'll be fixing later.
Decide in advance whether you continue or hold, and make that a documented choice rather than a default.
The effective date gets assumed
Families report plan changes in round numbers. The actual effective date can be mid-month, retroactive, or later than they think.
Confirm it with the payer and record it as a date field. The gap between the reported date and the real date is where the denials cluster.
Nobody checks what already went out
Claims submitted with the old payer information between the effective date and the update need to be identified and corrected, not just stopped going forward.
Pull every claim with a date of service after the effective date and rework them as a batch. Doing this in month one is a task. Doing it in month four is an appeal project against filing deadlines. The ABA Revenue Cycle Management guide also covers denial root causes and how demographic or insurance errors show up downstream.
Secondary coverage gets dropped in the shuffle
When the primary changes, coordination of benefits changes with it. The secondary that was working fine last month may now be primary, or may no longer exist.
Where connected operations help
None of these six steps is difficult. They fail because they live in six systems owned by four people, and no single view shows which ones are done.
SparkzABA tracks the downstream work created by a demographic or insurance change as an owned checklist with due dates, connected to the verification, authorization, and billing operations steps affected by it. The SparkzABA ABA Revenue Cycle Management guide specifically covers demographic update tracking across the EHR, billing system, clearinghouse, payer, VOB recheck, and authorization.
Your EHR and clearinghouse keep doing their jobs. What changes is that nobody has to remember which of the six got done. For the intake side of the workflow, see ABA Patient Intake Software: 9 Features That Protect Billing.
Frequently asked questions
What should ABA clinics do first when a client's insurance changes?
Confirm the effective date with the new payer before anything else, since that date determines which already-delivered sessions are affected. Then run a full benefits re-verification and start a new authorization request, because existing authorizations generally do not transfer between payers even when the clinical need is unchanged.
Does an ABA authorization transfer when a client changes insurance?
Almost never. The new payer issues its own authorization with its own approved codes, units, and date range. Sessions delivered under the old authorization after the new plan's effective date are typically denied, so the new request should start as soon as the change is known rather than after the first denial.
How long should an insurance change take to process internally?
Three to five business days is realistic when each item on the checklist has an owner and a due date. The risk isn't the length of the process, it's the gap between the plan's effective date and the completed update, since services delivered in that window generate claims against information the payer no longer recognizes.
Treat the card as the start of the work, not the end
Next time a new insurance card comes in, don't scan it and move on. Open your ABA insurance change workflow, assign the six items, and set a date.
Comments