The patient registration errors that lead to denials are usually small: a wrong member ID, a misspelled name, the policyholder's birth date in the patient's field, an ended plan still on file or two plans in the wrong order. Each one sends the payer data it cannot match, so the claim is denied weeks after intake.
Patient registration errors ranked by denial cost
Patient registration errors can be ranked by what they cost when they reach a claim. The costliest stop payment entirely and need the claim corrected and resent, sometimes to a different payer. Cheaper ones delay payment while someone fixes one field. The ranking below is an editorial judgment about rework, not a measured study.
The table is the core of this post. Each row names a registration error, the claim adjustment reason code (CARC) a payer commonly uses when it denies for that reason, and the intake check that catches the error first. CARC descriptions are quoted from the X12 Claim Adjustment Reason Codes list. Payers choose their own codes, so a given error can arrive under a different code.
| Rank | Registration error | Denial it commonly causes | Intake check that catches it |
|---|---|---|---|
| 1 | Claim sent to the wrong payer, such as an old plan | CARC 109: "Claim/service not covered by this payer/contractor. You must send the claim/service to the correct payer/contractor." | Eligibility check on every visit; ask about new coverage |
| 2 | Coverage ended or not yet started on the date of service | CARC 27: "Expenses incurred after coverage terminated." or CARC 26: "Expenses incurred prior to coverage." | Eligibility check against the date of service |
| 3 | Other coverage missing or in the wrong order | CARC 22: "This care may be covered by another payer per coordination of benefits." | Ask about other insurance at every visit; record which plan pays first |
| 4 | Member ID wrong, or patient not found | CARC 31: "Patient cannot be identified as our insured." | Compare the ID with the card image; run eligibility |
| 5 | Name and member ID do not match | CARC 140: "Patient/Insured health identification number and name do not match." | Enter the name exactly as on the card |
| 6 | Missing or malformed field, such as a blank birth date | CARC 16: "Claim/service lacks information or has submission/billing error(s)." | Required-field and format checks at intake |
Rows 1 to 3 rank highest because the claim has to go to a different payer or wait for another payer's decision. Rows 4 to 6 usually need one field fixed and the claim resent to the same payer. Each fix still costs staff time, and a fix that comes late can run into a filing deadline.
Two errors in the table come from the insurance card itself. Where to find the member ID and group number, and what their prefixes mean, is explained in member ID and group number on insurance cards. The birth date mix-up between policyholder and patient has its own section in subscriber date of birth mix-ups that deny claims.
Intake form data entry errors and where they start
Intake form data entry errors start in three places: retyping a patient's answers into the practice management system, misreading handwriting or a card image, and recording insurance plans in the wrong coverage order. Each error looks harmless on the registration screen. It only shows up when a payer compares the claim with its own records.
Retyping
Every answer that is written once and typed again can change on the way. Digits get transposed in member IDs and dates. A middle initial becomes part of the first name. A field is skipped because the staff member's screen order differs from the form's order. The fix is to type less, either by having patients type their own answers or by having software read the form and send unsure fields to a person.
Misreads
Handwriting and card images cause their own errors. A 0 and an O, a 1 and an I, or a 5 and an S can look alike in a member ID. Software that reads cards makes some of the same mistakes, and the guide to which insurance card OCR misreads cause denials lists them. Whatever does the reading, a member ID that cannot be confirmed should go to a person.
Wrong coverage order
When a patient has two plans, registration must record which one pays first. Getting the order wrong sends the claim to the secondary payer first. The CMS page on Medicare Secondary Payer billing responsibilities tells providers to gather billing information, preferably with the CMS questionnaire or a similar one, to determine the primary payer, and says that failing to keep a system for identifying other payers is viewed as a violation of the provider agreement with Medicare.
Knowing what each part of the form asks helps staff spot an answer in the wrong place. The section-by-section guide to what a patient intake form collects covers that.
How do duplicate patient records come from intake?
Duplicate patient records come from intake when staff create a new chart instead of finding the existing one. The usual causes are name variants such as a nickname or a married name, typos in the name or date of birth, and skipping the search step on a busy morning. The duplicate splits insurance and history across two charts.
Name variants
A patient registered as "Katherine Example" on one visit and "Kate Example" on the next can become two patients if the search uses the full first name. Hyphenated and changed last names cause the same split. Each chart may then carry different insurance, and a claim can go out under the chart with the old plan.
Typos
A date of birth typed as 07/12 instead of 12/07, or a last name missing one letter, makes the existing chart invisible to an exact search. The new chart looks complete, so nobody notices until two sets of records disagree.
Skipped searches
The most direct cause is not searching at all. A 2014 report prepared for the Office of the National Coordinator, the ONC Patient Identification and Matching Final Report, names data quality at the point of registration and duplicate records within a system among the causes of unmatched records. It describes requiring registrars to search for an existing record before creating a new one as a best practice, and one health system searching with a few letters of the first or last name to find records filed under a nickname or misspelling.
How a duplicate becomes a denial
Here is a fictional example. Sam Example has a chart with a current plan, member ID ZXR900112. At a later visit, staff create a second chart under "Samuel Example" and copy an old card on file. The claim goes out under the second chart with an ended plan and comes back with CARC 27, coverage terminated. Merging the charts and rebilling fixes it, but only after the denial.
Which denial reasons trace back to registration?
The denial reasons that trace back to registration are the ones about who the patient is and what coverage they have. On the X12 reason code list, they cover a patient the payer cannot identify, a name and ID that do not match, inactive coverage, another payer that pays first and a claim sent to the wrong payer.
Identity codes
CARC 31, "Patient cannot be identified as our insured", and CARC 140, "Patient/Insured health identification number and name do not match", point at the member ID, the name or the date of birth. Check those three fields against the card before anything else.
Coverage date codes
CARC 26, "Expenses incurred prior to coverage", CARC 27, "Expenses incurred after coverage terminated", and CARC 200, "Expenses incurred during lapse in coverage", point at effective dates. They usually mean the plan on file was not active on the date of service.
Payer and order codes
CARC 109 says the claim must be sent to the correct payer, and CARC 22 says the care may be covered by another payer per coordination of benefits. Both point at the coverage list in registration: which plans are on file and in what order.
Missing information
CARC 16, "Claim/service lacks information or has submission/billing error(s)", is broad. It can mean a registration field is blank or badly formatted, but it can also come from coding or billing. Read the remark codes that come with it before deciding the error started at intake.
How to work these denials once they arrive, including appeals, belongs to denial management, which the revenue cycle automation category covers.
Catching registration errors before the claim goes out
Catching registration errors before the claim goes out takes two passes. At intake, check identity and coverage while the patient is still present. Before billing, check that the claim's patient and insurance fields still match what was confirmed. The first pass stops most errors; the second catches what changed in between.
At intake
Confirm the name, date of birth and member ID against the insurance card as well as the form. Run an eligibility check for the date of service. Under the HIPAA transaction standards at 45 CFR 162.1202, the adopted standard for professional, institutional and dental eligibility inquiries and responses is the ASC X12 270/271. Ask every patient whether they have any other insurance, and record which plan pays first. Search for an existing chart before creating one.
Before billing
Compare the claim's patient fields with the registration record. On a CMS-1500, the NUCC 1500 Claim Form Reference Instruction Manual, version 13.0 (7/25) asks for the insured's ID number as shown on the ID card in item 1a, the patient's name in item 2 and the birth date in item 3. Recheck eligibility when the visit is far from the original check, or when the patient reported new insurance.
Where software helps
Software helps most with reading and comparing: turning a form or card into fields and flagging values that do not match the record. Schema Care reads intake forms, including demographics, insurance and consent checkboxes, scores each field and routes the unsure ones to a reviewer who sees the value highlighted on the page, as the Schema Care homepage describes. A person still decides what to do about a mismatch.
Registration fixes that create new denials
Registration fixes create new denials when staff correct the coverage on file but do not rebill the claims that already went out under the old data. The record now looks right, yet the denied claims stay denied, and claims sent between the error and the fix may go to the wrong payer twice or miss a filing deadline.
Correct the record, then find the claims
When you change a member ID, plan or coverage order, list every claim for that patient since the date the wrong data was entered. Each one may need to be corrected and resent, or sent to a different payer. Fixing only the claim that drew the denial leaves the others waiting to fail.
Watch the filing deadline
Late fixes can run out of time. For Medicare claims, the rule at 42 CFR 424.44 says a claim for services furnished on or after January 1, 2010 must be filed no later than one calendar year after the date of service, with listed exceptions. Commercial plans set their own limits in their contracts. A claim that misses its limit can come back with CARC 29, "The time limit for filing has expired."
Do not overwrite the old coverage
If the fix replaces the old plan instead of ending it, staff lose the record of what was billed to whom. Keep the old coverage with an end date so the history explains the claims already sent.
Merge duplicates carefully
Merging two charts fixes a duplicate, but a careless merge can carry the wrong plan into the surviving chart. Confirm the current coverage after every merge, then rebill the affected claims. A fictional example: after merging two charts for Lee Example, staff confirm the current plan, member ID QMT332190, end the old one and resend the three affected claims to the current payer.