COB adjustment snapshot ops

Outcome

You understand how primary CAS / AMT data flows into secondary 837s and when (and how) to re-snapshot.

Prerequisites

• Familiarity with the COB waterfall — see Tertiary waterfall and resume.
• Read access to billing.claim_cob_adjustment for inspection.

How the snapshot works

When a secondary claim is generated, the platform snapshots the primary payer's CAS/AMT adjudication data into billing.claim_cob_adjustment. The secondary 837 then rides that snapshot — not the live billing.remittance_adjustment rows.

This decouples the secondary submission from any later changes to the primary's remittance — which is append-only by design.

Snapshot is append-only

claim_cob_adjustment has no updates. If the primary's 835 is reposted (corrected remittance, reversal + re-adjudication), the original snapshot does not change — the secondary claim's 837 will still reference the first adjudication.

Re-snapshot procedure

Use this when the secondary claim has not been submitted yet and the primary re-adjudicated.

1. Confirm the secondary is still BUILT (not yet SUBMITTED):

   SELECT status_current
   FROM billing.claim
   WHERE claim_id = '<secondary-claim-id>';
   -- Must return BUILT to proceed.

2. Delete the snapshot inside a transaction:

   BEGIN;
   DELETE FROM billing.claim_cob_adjustment
    WHERE claim_id = '<secondary-claim-id>';
   COMMIT;

3. Re-call generateSecondaryClaim via a one-off Node script. The snapshot writer picks up the latest billing.remittance_claim row for the primary and repopulates:

   import { generateSecondaryClaim } from '@rcm/core/.../secondary-claim-service';
   
   await generateSecondaryClaim(db, input, coverage, actor);

   A CLI for this isn't shipped — the path is rare enough to accept manual steps. Revisit if incident volume warrants it.

v_member_liability rollup

SELECT *
FROM billing.v_member_liability
WHERE member_id = '<member_id>';

Returns one row per claim in the COB chain with patient-responsibility total sourced from claim_cob_adjustment CAS/PR/* rows. root_claim_id joins sibling rows back to the original submission — useful for "total out-of-pocket for this episode of care" reporting.

Members whose claims predate snapshotting (RM-11 S03) or have only single-payer coverage do not appear in this view. Zero-liability reporting requires a LEFT JOIN from billing.claim.

Validation

Check	Expected
claim_cob_adjustment rows for the secondary	Match latest primary 835 amounts
Secondary 837 (after re-snapshot)	CAS/AMT segments reflect repopulated data
v_member_liability for the member	Patient-responsibility totals look correct

Known limits

• Remittance-poster ghost-column sweep (COB-01). The 835 poster has legacy column-name references that need cleanup. The snapshot reads the correct columns, so once the poster is fixed, end-to-end propagation lights up without further code changes.
• Claim-level RARC storage. Migration 087 adds remit_claim_id to billing.remittance_remark, but claim-level RARCs aren't yet snapshotted into claim_cob_adjustment. Tracked as a follow-up.
• Tertiary waterfall trigger. The snapshot machinery is payer-sequence-agnostic. The auto-trigger that fires tertiary generation after a secondary 835 posts is covered in §3.5 Tertiary waterfall.

Cross-references

• Payer priority & Medicaid-last-resort for MSP classification.
• Tertiary waterfall and resume for the auto-trigger.

Next

3.4 — Payer priority & Medicaid-last-resort ops