What is a Medicare Beneficiary Identifier, and how is it different from a HICN?

The Medicare Beneficiary Identifier, MBI, is an 11-character identifier made of numbers and uppercase letters that replaced the Health Insurance Claim Number, HICN, which had been based on a beneficiary's Social Security number. CMS reissued Medicare cards with the new MBI and required claims for dates of service on or after January 1, 2020 to use it, with a small set of named exceptions such as appeals.

Why might a practice's insurance module show the wrong Medicare number?

A number entered into the plan record years ago does not update itself when CMS reissues a card. In one de-identified practice audit, a patient's insurance plan record held a pre-2020 HICN, a number that predates the MBI transition, while the patient's current MBI existed elsewhere in the same practice management system, on a scanned image of their card.

If the current Medicare number is not in the insurance module, is it actually missing?

Not necessarily. In the case audited, the number had been collected, it was simply stored as a scanned document image rather than as data in the structured plan-record field that billing reports read from. A report built to check only the plan record will show the patient as missing current Medicare coverage information even when the number exists in the chart.

Can old HICNs still be used to bill Medicare claims?

For claims with dates of service on or after January 1, 2020, CMS requires the MBI, with a limited set of named exceptions, including certain appeals, adjustments processed through specific legacy systems, and some historical reporting. A retired HICN sitting in a plan record from before that transition is not a substitute for the patient's current MBI on a claim filed today.

What should a practice check if its Medicare claims are stalling on eligibility?

Compare what the insurance module's plan record shows against any scanned card images or intake documents on file for the same patient before assuming the number was never collected. A structured field and a scanned document are stored differently in most practice management systems, and a report built to read only one of them will miss information that genuinely exists in the other.

Your Patients' Medicare Numbers Are in the Chart, Not in the Insurance Module

A practice pulls up a patient’s insurance plan record to confirm Medicare coverage before filing a claim, and the Medicare number field is either blank or holds a number that no longer works. The conclusion most billers reach is that the number was never collected. In one de-identified practice audit, that conclusion was wrong. The number existed. It was just stored somewhere the billing report never looked.

What actually happened in the audit?

What the audit found, de-identified

In one practice's records, a patient's current Medicare Beneficiary Identifier was legible on a scanned image of their Medicare card, stored under the practice management system's document imaging. The same patient's insurance plan record, the structured field billing reports actually read from, held a different number: a pre-2020 Health Insurance Claim Number, retired since CMS's transition to the MBI. The current number was never missing. It was in the chart, not in the plan record.

Source: one practice, de-identified, audit conducted 2026

That distinction, chart versus plan record, is the whole finding. A practice management system can hold a patient’s current Medicare number as a legible scanned document while its own structured insurance data still points to a number retired years earlier. Nothing in the software forces those two places to agree.

What is the difference between an MBI and a HICN?

The Medicare Beneficiary Identifier, MBI, is an 11-character identifier made of numbers and uppercase letters that CMS assigned to every Medicare beneficiary as part of its New Medicare Card initiative. It replaced the Health Insurance Claim Number, HICN, which had been derived from the beneficiary’s own Social Security number. CMS reissued cards carrying the new MBI, and required its use on claims for dates of service on or after January 1, 2020, with a limited, named set of exceptions such as certain appeals and specific legacy reporting systems.

A HICN is not simply an older-format version of the same number. It is tied to the Social Security number the MBI was created specifically to move away from. A HICN sitting in a plan record today did not update itself when the patient’s card was reissued; it is whatever was entered at the time, and if that entry predates 2020, it predates the identifier a current claim needs.

Why does a plan record go stale while the chart stays current?

Because the two are usually populated by different workflows, at different times, by different staff. Card information often gets collected once, at initial intake, and only revisited when something forces a second look, a bounced claim, a coverage change the patient reports, or a scheduled re-verification. A scanned copy of the card, if the front desk photographs or photocopies it, tends to get filed under documents or imaging as part of routine intake, independent of whether anyone re-keys the number into the structured plan field.

In the audited case, the scanned card was current. The typed field was not. Nothing about that gap required negligence. It is the predictable result of two different data stores, one designed for documents and one designed for structured billing fields, that a practice’s own reporting never cross-checks against each other.

How does this stay invisible to a practice’s own reports?

Billing and eligibility reports are typically built to read the structured plan record, because that is the field format a claim submission actually pulls from. A report checking whether a patient has current Medicare information on file will look at that field, see a retired HICN or a blank, and flag the patient as missing current coverage data. It has no reason to also open the imaging folder and read a scanned card, because that is not where the report was built to look.

The result is a report that looks accurate and is not. It correctly describes what the plan record contains. It does not describe what the practice actually has on file for that patient, because the chart and the plan record are not the same source, and only one of them is what the report checks.

Are there cases where the old HICN is still acceptable?

A narrow set, and it is worth a practice knowing the boundary rather than assuming every old number is automatically useless. CMS’s own MBI guidance names specific carve-outs: appeals and related forms can use either the HICN or the MBI, some adjustment processing through specific legacy systems can continue to reference the HICN, and certain historical reports still display the HICN rather than the MBI. Claims themselves are the narrow case, not the broad one. For a claim with a date of service on or after January 1, 2020, the exceptions do not apply, and the current MBI is what the claim needs.

That distinction matters because a biller who sees a HICN accepted somewhere in the system, on an old remittance report, for instance, can reasonably but wrongly conclude the number still works everywhere. It does not. The same patient’s plan record holding a pre-2020 HICN is not evidence the number is fine for billing. It is evidence the record has not been updated since before the transition CMS completed years ago.

What should a practice actually check?

Where the data lives	What it typically shows	What a report reads
Insurance plan record (structured field)	Whatever was last typed in, possibly a retired HICN or blank	Yes, this is what billing reports check
Scanned card image (document/imaging)	The number as it appears on the card the patient last presented	No, not by default
Patient intake forms	Whatever the patient wrote by hand, subject to transcription error	Rarely, unless specifically pulled

For any patient whose Medicare claims are stalling on an eligibility mismatch, the check that actually resolves it is comparing the plan record against any scanned card images or intake documents already on file for that same patient, before assuming the number was never collected. In the case audited, that comparison recovered numbers that had been sitting in the system the entire time.

Where this comes from

The de-identified finding described here comes from one practice audit conducted as part of our own compliance and billing-data review process. No patient, provider, or practice identity is disclosed, and no counts beyond the single practice are represented as broader claims. The MBI transition dates and the requirement to use the MBI on claims for dates of service on or after January 1, 2020 come from CMS’s own New Medicare Card guidance. If you want to know whether your own insurance module and chart data agree on your patients’ current Medicare numbers, ClaimRail runs a free audit against your own data. No fee, no pitch.