7 Change Healthcare Alternatives After Outage 2026

A Change Healthcare alternative is another X12 clearinghouse (or a direct-payer connection) that can take professional and institutional 837 claims, return 277 acknowledgments, and deliver 835 remittances when the incumbent path is dark. This page is a category decision about 837/835 failover, not a FHIR Patient Access project and not a new EHR. It is published from the homepage. No clearinghouse paid for inclusion.

The February 2024 Change Healthcare / Optum clearinghouse disruption forced practices and billing companies to reroute 837 and 835 traffic, according to contemporaneous HHS (2024) notices on the cyberattack. Hospital and health-system operators tracked the same outage in AHA (2024) updates that year. If your 837s still have a single pipe, you are one vendor incident away from the same scramble.

Physician burnout: 53% in 2022 according to AMA (2024), which also reported 48.2% of physicians with at least one burnout symptom in 2023. Claims work that spills onto clinicians is how a clearinghouse outage shows up as documentation load, not just a billing-office ticket.

TL;DR: Keep Change Healthcare only if it is already dual-homed and you can prove 277/835 delivery on a named backup. Shortlist Availity, Waystar, or Stedi when you need a production 837 path with payer coverage you can test. Use Office Ally, Claim.MD, or Ability when volume is smaller and you will accept more portal work. Do not treat CMS-0057-F FHIR clocks as the failover. Orchestrate only after two clearinghouses share a claim control number and a human owns exceptions.

Why 837 failover is not a FHIR project

CMS-0057-F is a later interoperability rule for Patient Access, Provider Access, Payer-to-Payer, and Prior Authorization APIs. Expedited prior auth: 72 hours according to CMS (2024), with seven calendar days for standard requests and API compliance generally beginning January 1, 2027. That clock does not move an 837 sitting in a dead SFTP folder. API compliance clock: January 1, 2027 according to CMS (2024) for the FHIR API build, which is still not an 837 dual-run.

A clearinghouse is the store-and-forward layer that wraps X12, applies payer edits, and returns 277CA and 835 files. Availity, Waystar, Stedi, TriZetto, Claim.MD, Office Ally, and Ability appear as incumbent alternatives in the G2 (2026) clearinghouse neighborhood, with Availity and Stedi listed on their own G2 product pages. None of those products is your practice-management system. None of them is TEFCA.

Dual-run means you submit the same 837 to two trading partners for a defined window, match on the claim control number, and ignore the second 835 if the first already posted. If you cannot name the field you match on, you do not have failover. You have hope.

Adjacent revenue-cycle work still sits on the appointment and follow-up side: healthcare automation benchmarks, patient follow-up automation, appointment-prep checklists, and insurance-claim inquiry reduction. Those pages do not replace an 837 pipe.

Key Takeaways

• Failover is an X12 dual-run problem: 837 in, 277CA and 835 out, matched on a control number.

• Availity, Waystar, and Stedi are the usual production shortlist; Office Ally, Claim.MD, Ability, and TriZetto remain valid for specific payer mixes.

• CMS-0057-F FHIR APIs are a different clock; do not staff them as clearinghouse recovery.

• Public clearinghouse prices are often volume-quoted; put dual-run days and 277 latency in the same email as the per-claim fee.

• Orchestrate exceptions only after two trading partners and a named biller exist; do not add a third brain that resubmits the same 837.

Who should switch clearinghouses

This page is for billing managers, RCM directors, and practice administrators whose 837/835 path still depends on one clearinghouse, including Change Healthcare, and who can export claims from the PM or billing system. Stack: practice management or billing platform, SFTP or API, ERA posting. Pain: a dark pipe, a 277 that never arrives, or an 835 that posts to the wrong encounter.

Red flags: you already dual-run Availity and Waystar with a daily 277 recon; you are a solo cash-pay clinic with no 837 volume; you will not sign a BAA or name a person who can halt a duplicate submit.

Weighted buy criteria after an outage

Weights assume a professional or mixed 837 shop that must keep ERA posting intact. A pure eligibility-only buyer should raise payer-list coverage and drop 835 weight.

Burnout system cost: $4.6 billion/year according to JAMA Health Forum (as cited in the AMA 2024 well-being roundup). A 15-day dual-run is cheaper than a month of clinicians reworking claims in the EHR inbox.

Normalized clearinghouse matrix

Scores from public product pages checked 2026-09-06: 2 = first-party description of this X12 job; 1 = adjacent, confirm in contract; 0 = not found for 837/835 failover. The USTA column is first-party design numbers for this page (1 named hold, 1 worked recipe), not a clearinghouse score.

Availity, Waystar, and Stedi win as production 837/835 systems of record. Office Ally wins when the buyer already lives in that portal and volume is modest. Change Healthcare remains a keep-if-dual-homed option, not a "do nothing" option. USTA's 1s are a proposed exception hold and the recipe count on this page.

Pricing and TCO for 837/835 reroute

Checked 2026-09-06. Clearinghouses rarely publish a single per-claim list that survives a sales call. Example shop: 12 providers, 4,800 professional 837s/month. Put dual-run days and ERA posting labor in the quote.

A cheaper per-claim line that cannot return a 277 in a file is not cheaper. Ask for the payer list as a file, the 277 turnaround in hours, and whether 835s land as X12 or as a portal download.

Availity, Waystar, Stedi, and other incumbents

Availity — best when payer connectivity is the constraint

Availity is a clearinghouse and payer portal used across professional and institutional billing. Best fit: groups whose top payers already sit on Availity and whose billers already work eligibility there. Limitations: confirm 837 institutional, attachments, and API vs SFTP on the edition you buy; portal muscle memory is not an ERA spec. Implementation: enroll as a trading partner, map payerId values, dual-run 15 days, then cut the dark path. Primary evidence: Availity public product pages and G2 Availity. Disqualifier: you needed a developer-first X12 API and will not live in a portal.

Waystar — best when RCM suite depth matters more than a raw pipe

Waystar is bought as a revenue-cycle suite that includes clearinghouse, eligibility, and patient-financial tools. Best fit: hospitals and large groups that want 837/835 inside a broader RCM contract. Limitations: quote-led pricing; implementation is heavier; confirm you are buying the clearinghouse SKU, not only patient estimates. Implementation: trading-partner setup, ERA mapping, then dual-run. Primary evidence: Waystar public pages and G2 Waystar reviews. Disqualifier: you wanted a thin X12 pipe and a two-week cutover.

Stedi — best when you will own the X12 files

Stedi is a modern clearinghouse/API for claims, eligibility, and ERA files. Best fit: billing companies and tech-forward groups that can map transactionSettingId and keep file-level recon. Limitations: you still own payer onboarding and PM posting; it is not a replacement biller. Implementation: guides, partnerships, then dual-run on a single claim type first. Primary evidence: Stedi public docs and G2 Stedi. Disqualifier: no one on staff can read an ISA envelope.

Office Ally, Claim.MD, Ability, TriZetto

Office Ally and Claim.MD fit smaller professional shops that will accept more portal work. Ability and TriZetto fit payer-mix and enterprise contracts that already mention those names. Best fit: you can name the payers those networks actually clear. Limitations: do not assume 277CA files; test. Implementation: one claim type, 10 payers, 15 days. Disqualifier: your top Medicare Advantage plan is missing from the file they send you.

Keep Change Healthcare — only with a named backup

If Change Healthcare is restored and already dual-homed, ripping it out to "do something" creates a second outage. Best fit: two live trading partners, daily 277 recon, documented 835 posting. Limitations: a single restored pipe is still a single pipe. Disqualifier: the backup is a spreadsheet of payer phone numbers.

When NOT to use US Tech Automations: skip the orchestration layer if Availity or Waystar already owns 837 submit, 277CA, and 835 posting, your PM imports ERAs without a side spreadsheet, and a biller already works exceptions inside that product. Skip it if you have no 837 volume. Skip it if you will not grant SFTP/API access or name a human who can stop a duplicate submit. A proposed US Tech Automations path is for the gap between two clearinghouses and the PM, not a third clearinghouse.

Zapier, Make, or n8n can watch an SFTP drop, retry a failed pull, keep run histories, and store audit evidence when you configure those features. You still own HIPAA BAAs, PHI retention, idempotency of the claim control number, and the escalation when a 277 and an 835 disagree. A proposed US Tech Automations design would require the billing-manager hold before any resubmit and would write the decision back to the claim record instead of firing a second 837 from a personal inbox.

A proposed 277/835 exception path

A 12-provider group submitting 4,800 professional 837s per month at $185 average allowed, dual-running for 15 days, can treat a Stedi transactionSettingId that returns a 277 reject as the trigger to pause, match the claim control number, and only then allow a human to resubmit or park the claim. The 4,800, $185, and 15 figures are a worked scenario; transactionSettingId is a real Stedi configuration identifier.

US Tech Automations could, as a configurable capability, watch the 277 file, join on the control number, open a hold for the named biller, and emit a packet with payer, control number, and reject reason. Prerequisites: BAA, SFTP or API from both clearinghouses, PM claim export, and a human review point that can block a duplicate 837. Not a live customer result.

A second proposed path: when an 835 posts in the PM but the backup clearinghouse still shows the claim as unpaid, hold the patient statement. Output: hold queue, encounter ID, and a yes/no on statement release. The agentic workflow layer is the allowlisted route for that hold, not a new X12 network.

Clearinghouse switch mistakes

Do not cut Change Healthcare on a Friday because a sales deck promised "same payers." Do not dual-run without a match key. Do not confuse eligibility (270/271) success with 837 acceptance. Do not staff CMS-0057-F Patient Access APIs as if they submit claims. Do not let two products both auto-resubmit. Do not skip the 835 posting test on secondary claims.

Write the dual-run in a one-page runbook: claim types, payers, match field, who stops a duplicate, which 835 is allowed to post, and the calendar day you retire the dark path. If that page does not exist, you are not ready to switch.

Dual-run operations the billing office actually staffs

A dual-run is not "send it twice and hope." It is a written window in which both trading partners receive the same 837, only one 835 is allowed to post, and a named biller owns every 277 that does not match. Start with professional claims only. Institutional 837s have different payer edits and will contaminate the first two weeks of evidence. Pick ten payers that represent cash, not vanity: your top Medicare Advantage plan, two large commercials, Medicaid if you take it, and the rest by allowed dollars, not by logo count.

Match on the claim control number the PM already stores. If that field is blank in 8 of 20 test claims, stop the project and fix the PM extract before you pay for a second clearinghouse seat. File-level recon means you can answer, for each control number: did Availity ack, did Waystar or Stedi ack, which 835 posted, and is a patient statement blocked. If the answer lives in a biller's head, you do not have failover. You have a hero.

Run the 15-day window across a month-end on purpose. Clearinghouse outages do not wait for a quiet Tuesday. If ERA posting in the PM lags by a day, the dual-run will look like a duplicate until someone reads the 835 payer claim number. Document that lag. Put it on the runbook next to the SFTP folder names. When the window ends, cut the dark path in one change ticket, not in a hallway conversation.

Eligibility 270/271 success is a different pipe. A payer can answer eligibility and still reject the 837. Attachments are a third pipe. Do not staff all three as one "connectivity" story. Keep CMS-0057-F prior-auth APIs off this runbook. Keep TEFCA off this runbook. This page is X12 claims traffic after the 2024 Change Healthcare disruption, according to HHS (2024) notices dated to that incident year, and according to AHA (2024) hospital updates in the same year.

If you later want appointment and follow-up automation, that is a different queue from 837 submit. The 277/835 exception hold is the only orchestration this article will defend, and only after two trading partners and a human exist.

FAQs

Which Change Healthcare alternative should a typical group pick first?

Availity or Waystar if your top payers already sit there and billers will live in that portal; Stedi if you will own X12 files and APIs. Test 10 payers before you sign a multi-year suite.

Is Optum Change Healthcare still usable as a primary pipe?

Only if it is dual-homed and you can show 277/835 delivery on the backup for the same control numbers. A restored single pipe is still a single incident domain.

Does CMS-0057-F replace 837 clearinghouses?

No. CMS-0057-F sets FHIR API clocks for access and prior authorization, including 72-hour expedited decisions, not X12 claim submit. Keep this page on 837/835 failover.

Can we dual-run Office Ally with Availity?

Yes if both return files you can match. Portal screenshots are not a dual-run. Start with one claim type and 10 payers.

When is a no-code stack enough?

Zapier, Make, or n8n is enough when the only job is moving a file you already understand, with retries and a log you own. It is not enough when PHI, duplicate 837s, and patient statements are in play unless you add a named human hold.

How should US Tech Automations sit relative to Availity?

US Tech Automations should not submit the 837. A proposed path holds exceptions between Availity or Stedi and the PM after a 277 reject, then lets the biller resubmit once. See pricing for how that hold is scoped.