Notes on payer behavior
CO-16 means read the remark code
CO-16 — "claim/service lacks information which is needed for adjudication" — tells you almost nothing. That is by design: the code is a wrapper, and the actual reason travels next to it.
Why the code is empty on purpose
The X12 standard requires CARC 16 to be paired with a remark code (RARC) that names the missing or invalid element — a missing modifier, an invalid identifier, an absent attachment. The CARC is the envelope; the RARC is the message. A CO-16 worked without reading its remark code is a denial worked blind, and the same rule holds for a family of other codes that carry mandated remarks: CARC 96, 97, 234, and the records-request codes. On 97, the remark code even picks which of two entirely different plays applies — the CO-97 note shows how.
The play: fix, don't argue
A CO-16 is a data problem, and the cure is a data fix:
- Read the remark code on the electronic remittance (and the front-end acknowledgment, if the claim was rejected before adjudication).
- Populate the named element.
- Resubmit through the right door. An adjudicated claim goes back as a corrected claim — a replacement (frequency code 7) that references the original claim number. A claim rejected at the front end was never adjudicated, so it goes back as a new original claim. Sending a replacement for a claim the payer never adjudicated bounces; sending a new original for an adjudicated claim creates a duplicate denial.
What a CO-16 is not: an appeal. There is nothing to argue — the payer asked for a data element. A letter burns weeks of the clock without fixing the claim. The only escalation worth writing is the case where the "missing" information was verifiably present on the original claim.
The rejected-versus-denied distinction matters beyond mechanics. A front-end rejection never entered adjudication, which means it produces no remittance and can be invisible to reports built on payment data — rejected claims quietly age toward the filing deadline while looking like work in progress. Reconcile submission acknowledgments against remittances so nothing sits in that gap.
What goes missing, by specialty
The named element differs by what you bill: anatomical modifiers (digit modifiers in hand surgery, right/left in ophthalmology and ENT), drug identifiers on medication lines (dermatology biologics, pain management injectables), ordering- or referring-provider identifiers on pathology and diagnostics (GI, urology), accident and injury details on trauma claims (orthopedics — often a patient-side questionnaire the payer is waiting on rather than a claim defect). The remark code says which; the fix is the same shape every time.
The records-request cousins
Two codes in the same read-the-remark family deserve a mention because they are the easiest recoveries on the board when handled correctly: the attachment-required and attachment-deficient codes (CARC 252 and 251). These are development requests, not judgments — the payer is asking for the chart, or telling you what it received failed quality control (wrong pages, missing signature, illegible copy, wrong date range). The play is to send exactly what the remark code names, through the payer's records channel, referencing the claim, inside the deadline printed on the request — Medicare's record requests run on a 45-day clock, and commercial deadlines vary, so read them off the letter each time. Answered completely and on time, these claims simply pay; answered late, a clean claim converts into a denial.
Watch the clock while you fix
Corrected-claim windows are often shorter than appeal windows, payer-specific, and weakly documented — verify per contract rather than assuming the appeal clock applies. The appeal windows themselves are mapped in the working deadlines table. And a claim that cycles through repeated CO-16s while the filing window runs is how a fixable denial becomes a timely-filing denial — a much worse problem.
The broader habit this code teaches is the cheapest upgrade available to any billing operation, in any specialty: route every denial by its remark code, not its reason code. The practices that do rework denials once; the practices that don't work the same denial three times.