Lesson 0011
Resubmission Is Not One Thing
The practical product skill: pick the right follow-up action after a claim signal instead of sending every issue through the same resubmit button.
Your Tangible Win
After this lesson, you should be able to choose one action lane: RES, REP, VOI, APL, or STS.
Primary source to read after the lesson: CMS Electronic Health Care Claims.
The Core Idea
CMS says front-end and implementation-guide edits can reject claims for correction and resubmission before later coverage and payment decisioning (CMS Electronic Health Care Claims). That is the narrow meaning of fix and resend.
Once a claim has been accepted, processed, or adjudicated, the safer product rule is different: preserve the submitted claim snapshot, create a follow-up action, and link it to the original claim or payer reference when payer rules require it. CMS MLN treats claim codes and additional claim information as NUCC-designated billing information on the CMS-1500 and 837P (CMS MLN Billing Information), while NUCC maintains the 1500 claim form instruction manual (NUCC 1500 instructions).
Five Follow-Up Actions
| Code | Use When | Product Action |
|---|---|---|
| RES | The claim was rejected before payer adjudication. | Correct claim data and resend as a new transmission attempt. |
| REP | The payer accepted or adjudicated the claim, but submitted facts need correction. | Create a replacement or corrected-claim action under payer rules. |
| VOI | The accepted claim should not exist or should be canceled. | Create a void or cancel action and keep the audit trail. |
| APL | The claim facts are right, but you dispute a coverage or payment decision. | Create an appeal or reconsideration packet, not a data correction. |
| STS | The only signal is current claim processing status. | Update tracking and follow-up timing without changing claim data. |
Decision Rule
First ask whether the payer accepted or adjudicated the claim. If no, fix and resend. If yes, do not silently edit history. Choose replacement, void, appeal, or status tracking.
| Signal | Unsafe Shortcut | Safer Model |
|---|---|---|
| Missing subscriber DOB caused rejection. | claim_failed = true |
action = RES, correction task, resend attempt. |
| Wrong procedure code was accepted and adjudicated. | Overwrite the old claim. | action = REP, preserve old snapshot, link replacement. |
| Duplicate accepted claim should be canceled. | Delete the claim row. | action = VOI, preserve audit trail. |
| Payer denied but documentation supports coverage. | Change claim facts to force payment. | action = APL, collect evidence and appeal. |
Mini Case
A claim for a visit was accepted by the payer. Later, staff discover the place of service was wrong. The product lets them edit the old claim row and press resubmit.
Product diagnosis: this needs a replacement or corrected-claim action, not silent mutation. Keep the original submitted snapshot, create a new action, and store the link to the original claim reference required by the payer or clearinghouse.
Scenario Practice
Choose the follow-up action. Use only the code: RES, REP, VOI, APL, or STS.
What to Ask Me Next
Ask follow-up questions when you want to turn this into a workflow table. Good next questions: "What columns should claim actions have?", "How do I model replacement chains?", or "Where do payer control numbers live?"
For review, keep the claim follow-up action card nearby.