Secondary & tertiary COB

Outcome

A primary payer's adjudication automatically (or with a click) generates a secondary claim, and the secondary's adjudication generates a tertiary where applicable. The COB ladder respects MSP rules and Medicaid's payer-of-last-resort posture.

Prerequisites

Scope	What it lets you do
billing.claim.read / .write	View and submit secondary claims
billing.cob.read	See the COB waterfall preview
billing.receivable.write	Trigger COB during posting

A member with two or more active coverages on the DOS, ordered correctly (see 2.4 — Confirm eligibility).

The COB picture

The waterfall pushes the unpaid balance (after primary adjustments) down to the next payer. The 837 to the secondary carries the primary's CAS adjustments and AMTF2 amount in 2320/2330, plus 2430 line-level SVD/CAS/DTP573.

How the platform builds a secondary

When a primary 835 posts:

1. The waterfall computes the secondary's claim shape. It snapshots the primary's adjustments (remittance_adjustment rows) onto the claim, computes the residual liability, and identifies the next payer per the member's COB ladder.

2. The secondary 837 auto-builds. Visible on the original claim's Relationships tab as a SECONDARY child. Status CREATED.

3. The scrubber runs, applying any payer-specific rules for the secondary. See 3.1 — Build & submit.

4. You submit it like any claim. Submission carries the primary's CAS history so the secondary payer can reconcile.

Pending secondary cases

Sometimes the primary returns DENIED or PENDED and the waterfall pauses pending more info:

Primary status	Waterfall action
PAID	Build secondary now.
PARTIAL	Build secondary now.
DENIED	Pause; add to cob_waterfall_pending.
PENDED	Pause; track follow-up date.

When the primary's situation resolves (e.g. the denial is appealed and paid, or the pend clears), resumePendingWaterfalls runs and builds the secondary then.

MSP and Medicaid (the priority rules)

The platform encodes the CMS Medicare Secondary Payer (MSP) matrix and Medicaid's payer-of-last-resort posture:

Rule	Effect
MSP working-aged	Group coverage primary, Medicare secondary.
MSP disability + ESRD	Specific reordering during 30-month period.
Medicaid never primary	Ladder is auto-reordered; if Medicaid is recorded first, it's pushed last.
Tertiary auto-trigger	A secondary PAID/PARTIAL triggers a tertiary if a third coverage exists.

The Member detail's COB tab shows the resolved order with the rule that fired. If you disagree, file an issue with your supervisor; admin can configure overrides where the rules fall short.

Submitting a secondary by hand

If the auto-build skipped (rare — usually a missing config), you can build a secondary manually:

1. On the primary claim's Relationships tab, click Build secondary.

2. Pick the secondary payer from the member's COB ladder.

3. The platform applies the primary's CAS history and runs the scrubber.

4. Submit per the standard flow.

Validation

Check	Expected
Posting a primary 835 auto-builds the secondary	Yes — visible on Relationships.
Secondary 837 carries primary CAS / AMT*F2	Yes; visible in the Submission tab inspect.
Tertiary auto-triggers after a secondary PAID/PARTIAL	Yes.
cob_waterfall_pending clears when primary resolves	Yes.
MSP / Medicaid order is respected	Yes; verify on the COB tab.

Troubleshooting

Symptom	Cause	Fix
Secondary didn't auto-build	Member's secondary coverage missing or expired	Check Coverage tab; refresh eligibility.
Secondary built but with wrong payer	COB ladder ordering is wrong	Refer to MSP rules; ask admin if a manual override is needed.
Secondary 837 lacks AMT*F2	Primary 835 had no CAS rows or zero net	Re-check the primary's adjustments; AMT*F2 is the net allowed minus paid.
Tertiary built when primary was DENIED	Edge case — possibly bug	Don't submit; ping support; the waterfall should have paused.

Where to next

• 3.6 — Institutional vs professional — filing-type-specific COB nuances.
• 4.1 — ERA inbox — where the COB waterfall actually fires.