Every year, benefits leaders make the same bet. They pick a new carrier, negotiate a better rate, and assume the transition will be smooth. Then January 1st hits. Employees call, frantic, because their prescriptions are rejected. Infusion appointments get canceled. HR spends weeks on the phone sorting out claim denials.
The common explanation is bad communication or poor plan design. But I've spent enough time inside these systems to know the switch itself is what fails. And nobody talks about it because it's invisible, happening inside servers and data feeds that never touch a human hand.
What Happens When You Change Carriers
Follow the enrollment data. Your HCM system (Workday, ADP, UKG, whatever you use) sends a file to the new carrier. That file contains employee names, dates of birth, and enrollment choices. It's called an 834 transaction, and it's the standard way carriers get their member lists.
But that file contains zero clinical history. No prior authorizations, no ongoing treatment records, no pharmacy claims history. Every employee arrives at the new carrier as a blank slate, a newborn from a data perspective.
When someone shows up for their next dialysis session on January 2nd, the new carrier's system has no record of them and no pre-approval on file. The claim is denied.
The Four Invisible Failures
Through years of watching these transitions, I've identified four specific breakdowns that almost always happen. They're technical, but the impact lands on employees who miss treatments and fight denied claims.
1. The Prior Authorization Blackout
An employee with rheumatoid arthritis has a prior authorization for a biologic infusion approved through March under the old plan. When the new carrier takes over, that authorization is missing from their system, because no one sent it over.
The clinic submits a claim for the January infusion. Denied. The employee calls the carrier, who explains the authorization belonged to the previous plan and a new one must be submitted. That process can take weeks. Meanwhile, the patient either goes without treatment or pays out of pocket.
Nobody at the carrier set out to harm this patient. The breakdown is a data handshake failure between two systems that don't want to talk to each other.
2. The Pharmacy Washout
Specialty drugs are where this hurts most. Your PBM (pharmacy benefit manager) changes with the carrier. The old PBM immediately deactivates all member IDs. The new PBM has zero history on the employee's existing medications.
On January 1st, someone with diabetes walks into their pharmacy to refill a GLP-1 agonist. The system rejects it: new member, no prior therapy documented. The pharmacist can't override it without a manual authorization. The employee is told to call the insurance company, waits on hold, and is told to have their doctor send a continuity of care request.
That medication lists at $936 to $1,349 a month before insurance. The employee goes without for a week. Their blood sugar spikes. That is an infrastructure failure.
3. The COBRA Handoff Gap
Seasoned HR leaders get this one wrong. COBRA continuation coverage must match what active employees have; that is a legal requirement. When the plan switches carriers, COBRA participants are generally entitled to the new plan on the same terms as active employees.
The handoff rarely runs that cleanly. Your benefits administration platform (bswift, Ease, Benefitfocus) has to move COBRA records alongside active ones, and that data flow often splits or lags. A COBRA participant can end up enrolled in the wrong plan, or stranded in a gap where the old carrier thinks they moved and the new carrier has no record of them. If a claim gets paid under the wrong plan, untangling it takes months.
Most employers don't catch this until an audit or a COBRA participant calls about an ID card for a plan they never elected.
4. The File Date Paradox
Carriers load new members into their systems weeks before the effective date. They need time to print ID cards and set up portals. But what happens when an employee has a baby on December 28th?
They update their dependent in the HCM on December 29th. That update gets bundled into the 834 file sent on December 30th. The new carrier loads the baby on December 31st. On January 1st, the employee tries to file a claim for the birth. The new carrier denies it because the date of birth is before the effective date. The old carrier denies it because the dependent was never loaded in their system.
The family is in a no-man's-land. Neither carrier will pay. The employee is stuck, and HR has no easy way to fix it because both systems claim the dependent isn't theirs.
Why This Keeps Happening
The root cause is simple: carriers and benefits platforms have no incentive to build a bridge. They assume employees will call customer service and eventually get things sorted. That call center costs them money, but not as much as building a new data transfer protocol would.
Meanwhile, employers bear the cost in lost productivity, damaged trust, and employees going without critical care. We've normalized this chaos. We shouldn't.
CMS has set a deadline for the data handshake
That incentive gap is starting to close. A 2024 CMS final rule, CMS-0057-F, requires Medicare Advantage organizations, Medicaid and CHIP plans, and Affordable Care Act marketplace issuers to run FHIR APIs by January 1, 2027. Two of the four APIs target the exact breakdowns: a Prior Authorization API that carries requests, status, and supporting documents electronically, and a Payer-to-Payer API for moving member clinical data between plans.
That payer-to-payer exchange is the missing clinical handshake, now carrying a compliance date. The rule does not cover employer-sponsored group plans yet, and its operational prior-authorization provisions took effect January 1, 2026. But it is building the data rails and the vendor market that commercial plans can adopt, and it gives benefits leaders a concrete specification to name at renewal: ask your carrier whether their prior-authorization and member-data APIs run on FHIR, and when.
What You Can Do About It
I've seen a few organizations break this cycle. It takes work, but it's possible. These four moves make the difference:
- Demand a continuity of care file from your old carrier. Most can export a CSV of all active prior authorizations. Ask for it during contract termination. You have leverage; use it.
- Test special enrollments with retroactive dates. HIPAA gives employees a 30-day window to add a newborn, and coverage is retroactive to the birth. Don't build a freeze around the effective date. Require your new carrier to process those adds with the correct retroactive effective date, and test a newborn dated before January 1 during implementation before you go live.
- Require your new carrier to accept a pre-enrollment clinical dependency file. This is non-standard but possible. Push your broker to make it a contract term. If the carrier resists, ask them to explain how they'll handle day-one claims for ongoing treatments.
- Test your COBRA handoff before go-live. Ask your benefits administration platform to run a simulation. Confirm that no COBRA records drop out or land in the wrong carrier's feed.
The Takeaway
Switching health plans is a data migration project with life-altering consequences. Every year, we treat it as routine because the failures are invisible until they land in an employee's inbox or at their pharmacy counter.
Stop accepting that chaos is normal. Demand a bridge between the old system and the new one. Your employees don't care about the cost savings. They care about whether their medication is ready on January 2nd.
That's the only metric that matters.