What “Real-Time Claims Processing” Actually Requires

“Move claims processing to real time” appears in almost every modernization conversation, and it is usually stated as though batch processing were an accident — a habit left over from tape drives that persists because nobody got around to fixing it. That framing is wrong, and it is the reason real-time initiatives stall after the demo. The nightly cycle is not inertia. It is load-bearing.

Batch is a consistency boundary. Inside a cycle you have a stable snapshot of the world, a deterministic processing order, and a clean point at which everything either happened or did not. A great deal of Medicare adjudication logic quietly depends on all three. You cannot remove the cycle without first replacing what it was providing.

What has to be true before a claim can adjudicate

Four things, none of them local to the claim in front of you:

• Authoritative beneficiary state. Entitlement, benefit period, deductible and coinsurance status, utilization to date, Medicare Secondary Payer and managed-care data all live in the Common Working File, not in the claims system. CWF is where a beneficiary’s entitlement and accumulated activity are reconciled across the whole program, and a claim cannot be correctly priced without a trusted answer from it — an answer that is a function of every other claim already applied.
• History-dependent editing. Duplicate detection, medically-unlikely and procedure-to-procedure edits, benefit-period arithmetic, spell-of-illness logic — these are not properties of one claim. They are properties of a claim relative to others, some of which are still in flight.
• Effective-dated pricing. Grouping and pricing are modular and versioned, and the version is selected by the claim, not the calendar. For inpatient claims the Pricer driver calls the GROUPER for the fiscal year of the discharge date. A claim submitted today for a discharge two years ago must group and price as though it were two years ago.
• Cross-system coordination. Institutional claims (FISS — Part A inpatient plus institutional Part B outpatient), professional Part B claims (MCS), and DMEPOS claims (VMS) are adjudicated by three different shared systems that all reconcile against the same beneficiary record in CWF.

Batch makes all four tractable almost for free. Order is assigned rather than observed. Two claims for the same beneficiary process in a known sequence. The snapshot does not shift underneath you mid-cycle.

What real-time actually breaks

Remove the cycle and each of those freebies turns into an engineering problem you now own:

• Concurrency on shared beneficiary state. Two claims touching the same benefit period at the same moment is no longer a hypothetical. Whatever CWF-equivalent holds utilization becomes a contended resource with correctness riding on it.
• Ordering. Real-time means claims arrive in submission order, which is not a useful order. Benefit-period and deductible math is order-dependent, so arrival order and processing order have to be deliberately separated.
• Idempotency. Event-driven systems retry. A retry that re-applies utilization has silently corrupted a beneficiary’s benefit period, and it will not surface for months.
• Partial failure. A batch cycle either completed or it did not. A stream of independent adjudications has no such boundary, so “what state is the system in” stops having a single answer.

And one thing real-time does not touch at all: the statutory payment floor. A clean electronic claim cannot be paid before the fourteenth day after receipt — the twenty-ninth for paper — regardless of how fast it adjudicates. So real-time adjudication does not produce real-time payment, and any business case built on faster cash flow is built on a misunderstanding of the constraint.

The prize is certainty, not speed

Which raises the obvious question: if the money does not move faster, what is the point?

Feedback latency. Today a claim with a correctable problem can spend a day or more in the system before it comes back as an RTP — and because an unprocessable claim is not an initial determination, that round trip buys the provider nothing but delay. In a real-time path the same claim can be returned in seconds, while the person who submitted it is still looking at it. That is a genuinely large operational win, and it has nothing to do with payment velocity.

Stated precisely, the achievable target is real-time determination with batch-cadence disbursement. Decouple adjudication from payment. Tell the submitter what will happen immediately; pay on the schedule the statute allows. This is a much more honest goal than “real-time claims processing,” and it is the one that survives contact with the rules.

What the architecture has to provide

If the cycle is going away, its guarantees have to become explicit:

• Per-beneficiary serialization. Partition by beneficiary, not by claim. Claims for different beneficiaries are embarrassingly parallel; claims for the same beneficiary are a sequence and must be processed as one.
• A durable, ordered event log. The record of what was applied, in what order, so state can be rebuilt rather than trusted.
• Effective-dated rule modules. Pricing and edit logic addressable by date of service, with old versions retained indefinitely. Deleting last year’s rules destroys your ability to adjudicate last year’s claims.
• Replay. The ability to re-run a claim, or a population of claims, and get the same answer. This is what makes the whole thing auditable, and it is also the only practical way to validate a migration.

None of that is exotic. It is standard distributed-systems work. The point is that it is not optional, and it is the actual scope of the project — the part that gets left out of the estimate when real-time is treated as a matter of turning batch off.

The batch window was never the obstacle. It is the specification. Anyone proposing real-time who cannot say how they will serialize per-beneficiary state and preserve effective-dated pricing has not read it.