What changed
FACT (source text): Final rules published 2026-06-04 under the No Surprises Act finalize Federal IDR operations. They require group health plans and issuers to (a) register in the Federal IDR portal, (b) disclose specified information alongside the initial payment or notice of denial, and (c) communicate using claim adjustment reason codes (CARCs) and remittance advice remark codes (RARCs), as specified in guidance, on ANY paper or electronic remittance advice sent to an entity with no contractual relationship with the plan. The rules also amend the open-negotiation period, IDR initiation, dispute-eligibility review, batching, bundled payments, and administrative fees.
Why now
The CARC/RARC mandate is the actual unlock, and it is under-appreciated. Until now, determining whether a given out-of-network claim was IDR-eligible required a human to read unstructured, payer-idiosyncratic remittance text. FACT (source text): plans must now encode that information in standardized CARC/RARC codes on every remittance to a non-contracted entity. INFERENCE (hypothesis): that converts an unstructured judgment task into a deterministic, machine-readable rules engine — which is exactly the kind of thing a solo AI-assisted founder can build and a large RCM incumbent is slow to rebuild. The window is the gap between the rule's applicability date and incumbents re-tooling their eligibility logic to consume the new codes.
Converging signals
Three things meet at one point: (1) a federal rule compelling plans to register in a government portal and emit standardized codes; (2) a defined counterparty class — out-of-network physician groups, emergency/anesthesia/radiology staffing companies, facilities, and air-ambulance operators — who initiate open negotiation and IDR; (3) a per-dispute administrative fee and certified-IDR-entity fee structure that already prices the transaction. HYPOTHESIS: the newly standardized codes plus the amended batching and eligibility-review rules mean eligibility can be computed rather than argued.
Customer pain
HYPOTHESIS (not established by the provided source text): out-of-network provider groups lose recoverable money in two ways — they fail to initiate open negotiation inside the statutory window on claims that were eligible, and they file disputes that get thrown out at eligibility review, forfeiting time and administrative fees. FACT (source text): the rules amend the dispute-eligibility review process and the batching rules, which means eligibility and batching are non-trivial and get adjudicated. The pain is a deadline-driven, high-volume triage problem across thousands of remittance lines.
Who pays
The buyer is the out-of-network filer, not the plan. Realistic first customers: independent emergency-medicine, anesthesia, radiology, and pathology groups (roughly 5–50 clinicians) with material OON volume; freestanding emergency facilities; air-ambulance operators (a small, concentrated, high-dollar-per-claim class). A second, arguably better buyer: the billing companies and contingency IDR firms themselves, who would license the eligibility engine as infrastructure rather than build it.
Solved today
HYPOTHESIS: today this is done by (a) in-house billing staff eyeballing remittances, (b) contingency-fee IDR filing firms that take a percentage of recovered amounts, and (c) revenue-cycle vendors bolting IDR onto existing denial-management workflows. The existence of a per-dispute administrative fee and certified IDR entities (FACT, source text) confirms money already changes hands per dispute.
Why current solutions are bad
HYPOTHESIS: contingency firms priced at a percentage of recovery are expensive on high-dollar claims and uneconomic on low-dollar ones, so small-dollar eligible claims are simply abandoned. Manual triage cannot keep up with remittance volume against a statutory clock. Neither approach has yet been rebuilt around the newly mandated CARC/RARC codes.
Proposed product
An eligibility-and-deadline engine, sold first as a data product and only later as a filing service. Ingest 835/ERA files, decode the mandated CARC/RARC combinations, apply a rules engine for Federal-IDR eligibility (federal vs. state jurisdiction, item/service type, open-negotiation clock, batching and bundled-payment constraints per the amended rules), and emit a ranked, deadline-stamped worklist of disputable claims with the batching plan and the justification text. Phase two adds portal submission and fee handling.
MVP version
A single-tenant, BAA-covered ingestion of a provider group's 835 files (SFTP or clearinghouse export — no live PM-system integration in v1), an eligibility rules engine expressed as versioned, auditable rules mapped directly to the final-rule text, and a worklist UI showing: claim, eligibility verdict with cited rule basis, days remaining on the open-negotiation window, and the suggested batch. Do NOT build portal submission first. Prove the eligibility verdicts are right against the customer's own historical outcomes before touching the portal.
30-day build
Buy the rule. Read the full final rule and the referenced CARC/RARC guidance end to end; extract the eligibility, batching, bundled-payment, and timing conditions into a written decision table. Obtain 10–20 real anonymized 835 samples (buy them, or trade a free retro-analysis for them). Interview 15 OON group billing managers and 3 contingency IDR firms. Falsification test: if the contingency firms say eligibility is not their bottleneck, the thesis is dead — pivot to the batching/bundling optimizer, or kill.
60-day build
Stand up HIPAA-grade infrastructure (BAA-capable hosting, encryption, access logging, a signed BAA template reviewed by healthcare counsel — budget for the lawyer, do not self-serve this). Build the 835 parser and the rules engine. Run it retrospectively against each design partner's last 12 months of remittances and produce a 'money you left on the table' report. That report is the sales asset — it is demonstrated value, not relationship sales.
90-day revenue plan
Convert 3–5 retro reports into paid pilots at a flat monthly platform fee plus a per-eligible-claim fee. Simultaneously pitch the engine as an OEM/API layer to 2–3 billing companies, which is the higher-leverage channel. First revenue realistically lands nearer day 120–150 than day 90, because the BAA and the retro-proof cycle cannot be compressed. The founder has runway for this; plan for it rather than pretending otherwise.
Distribution path
Retro-analysis reports as the wedge (send a group its own leaked-revenue number). Then: state and specialty society channels for emergency medicine and anesthesia; the air-ambulance operator list is small enough to enumerate and contact individually; and OEM deals with billing companies that already hold the 835 feeds. Explicitly not: content marketing, ads, or conference booths.
Pricing hypothesis
Recommended: $500–$2,000/month platform fee by claim volume, plus $75–$150 per claim advanced to filing. Reject pure contingency — it is what incumbents already do, it invites a price war on the one axis they can win, and it makes the founder a services business. A software price is the differentiation. For air-ambulance operators, where per-claim dollars are large, a higher per-filing fee ($500+) is defensible.
Technical difficulty
Moderate. 835/ERA parsing is a solved, well-documented problem with mature open-source libraries. The rules engine is the real work and it is legal-reading work, not algorithmic work — which is the founder's demonstrated strength. The genuinely hard parts are data access (getting the 835s) and PHI handling, not the logic.
Legal / regulatory risk
Meaningful and specific. The product touches protected health information, so the founder must operate under HIPAA Business Associate Agreements with every customer, with real breach-notification exposure. This is not licensure, but it is a genuine cost and liability the founder does not carry in his ELDT business. Additionally: filing disputes on a provider's behalf is arguably an agency/representation role and should be structured carefully. Retain healthcare counsel before the first BAA. Do not treat this as a formality.
Platform dependency
Low on the platform-risk axis — the counterparty is a federal portal and there is no platform owner who can deplatform the product. But there IS a hard dependency on getting 835 files out of clearinghouses and practice-management systems, which are commercial gatekeepers with their own incentives. That dependency is the one to worry about, and it is why v1 should accept flat-file exports rather than depend on any single integration partner.
Founder fit
Strong on shape, weak on domain. The shape is exactly the founder's proven ELDT pattern: read a federal mandate, find who must file, build the submission layer, charge per filing. But the ELDT precedent has a critical structural difference (see kill arguments) and healthcare RCM is a domain where entrenched vendors, PHI, and payer relationships all raise the floor. He can fund the ramp; the question is whether he can win against people who have lived in 835s for a decade.
Breakout potential
Real. The eligibility engine generalizes: state IDR/arbitration regimes exist alongside the federal one, with near-identical filer classes and different forms — that is the 50-market replication pattern the founder's thesis explicitly favors. And the same CARC/RARC decoding layer underpins broader denial-management products. If the engine works, the wedge widens on its own.
Final recommendation
CONDITIONAL PURSUE, NARROWED — and NOT as a forced-filer play. The input's FORCED BUYER evidence is real but it points at plans and issuers, while the proposed product sells to providers, who are discretionary filers. Do not let the public-money thesis inflate this into something it isn't. What survives scrutiny is narrower and still good: the newly mandated CARC/RARC coding makes IDR eligibility computable for the first time, and nobody's engine is yet built on those codes. Build the eligibility-and-deadline engine, prove it retrospectively against a design partner's own history, price it as software rather than contingency, and sell it as infrastructure to the billing companies and contingency firms who already own the 835 feeds — that channel converts the biggest competitor into the customer and neutralizes the data-access problem. Do not build portal submission until eligibility verdicts are proven. Two conditions kill it: if the retro analysis on real 835s shows eligibility is not where providers lose money, or if the contingency firms say eligibility is not their bottleneck, walk away. A parallel and possibly better idea sits in the same rule and should be evaluated separately: small third-party administrators and self-funded plan issuers ARE genuinely compelled to register and to emit compliant CARC/RARC remittances, with no choice and a deadline — that is the true forced-filer class in this document, and a compliance-checking tool for them has the ELDT shape that this provider-side product only superficially resembles.
Next action
Read the full text of the final rule at federalregister.gov/documents/2026/06/04/2026-11140 — specifically the applicability dates (not stated in the provided excerpt) and the referenced CARC/RARC guidance — and extract the eligibility conditions into a written decision table. In parallel, call three contingency IDR filing firms this week and ask one question: 'what fraction of the disputes you file get rejected at eligibility review, and what does that cost you?' Their answer validates or kills the entire thesis in under two weeks and before any capital is committed.