> For the complete documentation index, see [llms.txt](https://wiki.medicaiddatalearningnetwork.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://wiki.medicaiddatalearningnetwork.org/basics/bene_id.md). # BENE\_ID {% hint style="info" icon="pen-to-square" %} Contributed by Konstantin Kunze (), Daniel Guth (), and Elaine Hill () {% endhint %} ## Overview `BENE_ID` is the federally assigned beneficiary identifier that links Medicaid records to individuals over time, across states, and to Medicare. It is generated by the **Chronic Conditions Warehouse (CCW)** from state-submitted demographic information (name, date of birth, Social Security number, sex) and is intended to be a single, stable person-level key across all Medicare and Medicaid files. For most research uses — cohort construction, longitudinal follow-up, Medicare–Medicaid linkage — `BENE_ID` is the correct variable to index individuals by. However, it is not universally populated, not always unique to one person, and not always stable across years. Researchers who treat `BENE_ID` as a clean primary key without preprocessing will silently lose person-years, split single individuals into multiple IDs, or collapse distinct individuals into one. This entry summarizes what is known about `BENE_ID` quality in the **T-MSIS Analytic Files (TAF)** and the older **Medicaid Analytic eXtract (MAX)**, the distinct failure modes researchers encounter, and recommended handling. Following CMS guidance, we suggest researchers do all initial claims linkages using `MSIS_ID` and state code instead of linking directly on `BENE_ID`, and then we suggest several preprocessing steps before aggregating to `BENE_ID` when available. ## Data Sources `BENE_ID` appears in every Medicaid research file CMS distributes through the Chronic Conditions Warehouse **Virtual Research Data Center (VRDC)** or as Research Identifiable Files (RIFs). The most relevant files for identifier work are the annual enrollment files: | File | Years | Identifier variables | | ------------------------------------------- | ------------ | --------------------------------------------------- | | **MAX Person Summary (PS)** | 1999–2015 | `BENE_ID`, `MSIS_ID`, `STATE_CD` | | **TAF Demographic & Eligibility (DE) Base** | 2014–present | `BENE_ID`, `MSIS_ID`, `SUBMTG_STATE_CD`, `STATE_CD` | Supporting identifiers: * **`MSIS_ID`** — state-assigned Medicaid ID. Unique *within* a submitting state but not across states. * **`SUBMTG_STATE_CD`** — two-digit number (FIPS code) for the state that submitted the record to T-MSIS. Used as the state partition for `MSIS_ID` in TAF, and several states (Wyoming, Montana, Pennsylvania) have two different `SUBMTG_STATE_CD`s. * **`STATE_CD`** — beneficiary's state of residence (two-letter abbreviation). MAX files use `STATE_CD` as the state partition and do not include `SUBMTG_STATE_CD`; TAF files include both but CMS suggests using `SUBMTG_STATE_CD` with `MSIS_ID`. This distinction matters when building a unified ID that works across both eras, which requires `STATE_CD`. ## Methods / Approach Three distinct quality problems affect `BENE_ID` in Medicaid enrollment data. CMS has documented or previously described the first two issues. Understanding discordant `BENE_ID`s and fixing these issues has been the focus of recent research from our lab (Kunze et al., forthcoming). ### 1. Missing `BENE_ID` (CMS-documented) Approximately **6% of Medicaid enrollment records nationally lack a `BENE_ID`** over 1999–2022, with annual rates ranging roughly 3–8% and declining over time. State variation is significant: **California is missing a `BENE_ID` on `~26%` of records**, New Jersey `~5%`, Minnesota `3%`, while most other states are `2.5%` or less. Missingness is highest among working-age adults (`ages 21–50`, roughly `10%`) and lowest in Medicare-aged beneficiaries (`~1%` at `65+`), consistent with the CCW generating IDs more reliably for individuals already in the Medicare system. When `BENE_ID` is missing, researchers typically fall back to `MSIS_ID` plus `SUBMTG_STATE_CD` as the person key. This is state-specific, so it breaks cross-state longitudinal analyses and makes Medicare linkage impossible for those records, but individuals without a `BENE_ID` are generally not in Medicare. One additional complication is that `BENE_ID` may be missing in some years and not others for the same `BENE_ID` and `MSIS_ID` pair, and even within the same year there are individuals who have a `BENE_ID` in the demographic file and who have claims records where `BENE_ID` is missing. Kunze et al. (forthcoming) provides SAS code to recover missing `BENE_ID` variables when possible. ### 2. `BENE_ID` Clusters (CMS-documented, 2020+) A `BENE_ID` can be connected to multiple `MSIS_ID` variables when an individual on Medicaid moves states or is reenrolled/redetermined within a state. Starting with the 2020 claims files, CCW changed how they created `BENE_ID` variables which had the effect of mapping individuals with an invalid Social Security number (SSN) to the same `BENE_ID`, in some cases tens or hundreds of individuals, a pattern CMS refers to as *`BENE_ID` clusters*. Approximately **1% of federal identifiers appear as clusters in recent years**, up from near-zero before 2020. Cluster sizes vary, and within clusters, core demographics like date of birth, sex, and death status are usually consistent, but **race differs in roughly 26% of clusters of four and in 46–48% of larger clusters**, suggesting that clusters collapse multiple individuals to one `BENE_ID` rather than simply re-grouping the same person. Likely causes include: * CMS identifier-reassignment processes introduced in 2020 that map distinct individuals with invalid SSNs to the same `BENE_ID` * Newborns assigned temporary IDs at birth that overlap with existing `BENE_ID` variables or are reused across states Kunze et al. (forthcoming) provides SAS code to identify `BENE_ID` clusters by counting the number of distinct `MSIS_ID`s per `BENE_ID` within a year, as well as tracking demographics that might be discordant. These clusters are described in the [CCW T-MSIS TAF RIF User Guide footnote 31](https://www2.ccwdata.org/documents/10280/19002246/ccw-taf-rif-user-guide.pdf) which suggests researchers treat clustered `BENE_ID` variables as unusable and fall back to state-specific identifiers for those records. The general recommendation from Kunze et al. is to use the cutoff of 4 or more `MSIS_ID` variables within a year for one `BENE_ID` to treat it as a cluster, but other researchers may want to use a different cutoff or directly incorporate demographic information. > **Note on the 2020 bridge file.** Separately from clustering, CMS reassigned a subset of `BENE_ID` values in 2020. The `TAFRIF_BENE_ID_BRIDGE_FILE` maps pre-2020 `BENE_ID` values to post-2020 values. Researchers combining data across 2019 and 2020+ should apply the bridge before person-level aggregation. The bridge addresses a *different* problem than clustering and should be applied regardless of cluster handling. ### 3. Discordant State and Federal Identifiers A single `MSIS_ID + state` combination can be linked to **two or more distinct `BENE_ID` variables across years**, even after excluding clustered `BENE_ID` variables and using the 2020 bridge file. Approximately **3% of state identifiers (≈8.6 million) are discordant in this sense** over 1999–2022. Discordance is not benign administrative renaming. Within the discordant group, the associated `BENE_ID` variables show non-trivial demographic differences — on average, `~11%` differ in birthdate, `~8%` in race, and `~24%` in sex — suggesting that in a meaningful share of cases, the same `MSIS_ID` has been used for genuinely different people at different times (e.g., ID reassignment, data-entry errors, or newborns sharing a mother's `MSIS_ID`). Most discordant cases involve only two `BENE_ID` variables, but up to six have been observed. Most discrepancies first appear within one to five years of the state identifier's initial appearance. State-level rates range from `0.22%` to `2.52%`. **Implication:** Indexing longitudinal analyses by `BENE_ID` alone without accounting for this will split some true individuals into multiple IDs. ## Recommended Correction Workflow Our recommended pipeline applies corrections to enrollment records in the following order: 1. **Apply the 2020 `BENE_ID` bridge file** to any data spanning 2020, so that pre- and post-2020 identifiers can be compared. 2. **Recover missing `BENE_ID` variables via a crosswalk.** Build a lookup from `MSIS_ID + state` to `BENE_ID` using every year in which the pair appears with a non-missing, non-clustered, non-discordant `BENE_ID`. Apply the lookup to records where `BENE_ID` is missing. 3. **Null out `BENE_ID` variables on discordant state-ID pairs.** For `MSIS_ID + state` combinations that map to multiple `BENE_ID` variables across years, treat `BENE_ID` as missing and fall back to the state key. 4. **Null out clustered `BENE_ID` variables.** For `BENE_ID` variables appearing in 4 or more `MSIS_ID + state` combinations in a given year, treat `BENE_ID` as missing on those records. 5. **Construct a unified person identifier** that uses `BENE_ID` when it is present and valid, and `MSIS_ID + state` otherwise. A conservative implementation of this workflow recovers approximately **10% of records with missing `BENE_ID`**, with recovery varying from `<1%` in South Dakota to `~19%` in Mississippi. Recovered records resemble the full beneficiary population more closely than the broader group of records with missing `BENE_ID`, which reduces the selection bias introduced by simply excluding records without a federal identifier. Full methodology, tables of recovery rates by state, and sensitivity analyses using alternative cluster thresholds are reported in Kunze et al. (forthcoming). SAS implementation code will be released with the paper. ## Key Considerations / Limitations * **Missingness is not random.** Records with a missing `BENE_ID` differ from those with a present `BENE_ID` in age distribution, race, and sex missingness. Simply dropping records with no `BENE_ID` can bias analyses, with highest missingness in California and among working-age adults. * **NDI linkages require similar steps.** Researchers inside the VRDC can link to National Death Index (NDI) mortality records, which aren't affected by the 2020-bridge file change but have clusters and discordant `BENE_ID`s. For that linkage, we suggest researchers do a three-step merge: first on `BENE_ID`+`MSIS_ID`+`STATE_CD`, second on `BENE_ID`, third on `MSIS_ID`+`STATE_CD`. * **State heterogeneity is the dominant source of variation.** California's `BENE_ID` missingness is an order of magnitude higher than most states. Several states (Montana, Nevada, Tennessee, and Wyoming) have high crude duplicate rates for `BENE_ID`. * **`BENE_ID` encryption is DUA-specific.** The same physical beneficiary receives a **different** encrypted `BENE_ID` under different Data Use Agreements (DUAs). `BENE_ID` cannot be compared across studies using different DUAs. * **Child–mother shared `MSIS_ID`.** In many states, mothers and newborns can share the same `MSIS_ID` for a period around birth (Natzke et al., 2020). This compounds the identifier-discordance problem for maternal and pediatric research. * **No external gold standard.** None of the identifier-quality assessments can validate against a ground-truth identity source. Patterns of missingness, duplication, and discordance are strong evidence of linkage error but cannot be proven in individual cases. ## Practical Tips / Best Practices **Before you analyze anything:** 1. **Profile identifier quality in your analytic sample.** Compute, by year and state, the share of records missing `BENE_ID`, with clustered `BENE_ID`, and with discordant state and federal mappings. For studies involving newborn infants, look at shared maternal-infant `MSIS_ID`s. 2. **Decide on a unified person key.** The recommended construction is `BENE_ID` when present and valid, `MSIS_ID + SUBMTG_STATE_CD` otherwise. Document the construction rule and apply it consistently across every file you merge. **While building the cohort:** 3. **Apply corrections in order: bridge, recover missing, null discordant, null clustered, construct unified key.** Skipping any step can silently corrupt downstream results; the bridge must come first so that pre- and post-2020 IDs are on the same scale. 4. **Use `SUBMTG_STATE_CD` for TAF unified IDs and `STATE_CD` for MAX.** Combining individuals across MAX and TAF when they are missing a `BENE_ID` requires using `STATE_CD` in the TAF or mapping from `SUBMTG_STATE_CD` to the equivalent 2-letter state abbreviation. **When reporting results:** 5. **State your identifier-handling rules explicitly in methods.** At minimum: how you handled missing `BENE_ID`, whether you excluded clustered or discordant records, and whether you used any recovery crosswalk. 6. **Report sensitivity analyses.** Consider rerunning key estimates excluding the corrected records (those with recovered, discordant, or clustered `BENE_ID` variables). If the substantive conclusion changes materially, identifier handling is a first-order concern for your question. **Kunze et al. Crosswalk Steps Outline:** Using the demographic files available to the researcher, create three `BENE_ID` lookup tables by collecting all unique (`BENE_ID`, `MSIS_ID`, `SUBMTG_STATE_CD`) tuples: 1. Create a `BENE_ID` cluster list by counting the number of associated `MSIS_ID` and state code pairs in each year and remove the `BENE_ID` for clustered individuals. 2. Create a `BENE_ID` discordancy list when an `MSIS_ID` and `SUBMTG_STATE_CD` pair is associated with more than 1 `BENE_ID` and remove those `BENE_ID` variables. 3. Create a `BENE_ID` lookup table for all the non-missing `BENE_ID` variables and their associated `MSIS_ID` and `SUBMTG_STATE_CD` variables. ### Quick checklist * [ ] Profile `BENE_ID` missingness by state/year in your sample. * [ ] Apply the 2020 `BENE_ID` bridge file before combining pre- and post-2020 data. * [ ] Recover missing `BENE_ID` variables via cross-year crosswalk where feasible. * [ ] Null out discordant and clustered `BENE_ID` variables; if missing, fall back to `MSIS_ID` plus state (`STATE_CD` in MAX and `SUBMTG_STATE_CD` in TAF). * [ ] Build one unified person key and use it to aggregate across `MSIS_ID` variables, but do all initial Medicaid claim linkages with `MSIS_ID` plus state. * [ ] Report all identifier-handling decisions in methods; run sensitivity analyses. ## References / Resources ### CMS and CCW documentation * [CCW T-MSIS TAF RIF User Guide](https://www2.ccwdata.org/documents/10280/19002246/ccw-taf-rif-user-guide.pdf). This document describes the `BENE_ID_BRIDGE_FILE` in footnote 30 and has the `BENE_ID` cluster information in footnote 31. * [TAF Technical Documentation: Claims Files](https://resdac.org/sites/datadocumentation.resdac.org/files/2022-06/TAF-TechGuide-Claims-Files.pdf). * [Unique Beneficiary Identifiers in the TAF in 2016.](https://www.medicaid.gov/dq-atlas/downloads/supplemental/3031-BENE-ID-2016.pdf) Whitney, M., Singer, E., Barrett, A., Proctor, K., & Parker, J. (2020). CMS / TAF data quality brief. * [Use of the Same Medicaid Identification Number for Mother and Newborn Services in 2016.](https://www.medicaid.gov/dq-atlas/downloads/supplemental/7011-Shared-Medicaid-ID-in-TAF.pdf) Natzke, B., Christensen, A., Proctor, K., & Parker, J. (2020). CMS / TAF research brief. ### Working paper (forthcoming) * Kunze, K., Adams, M. C. B., Hurley, R. W., Guth, D., Denham, A., Pargman, S., Patil, A., & Hill, E. L. (forthcoming). *Quality and Stability of Medicaid Beneficiary Identifiers, 1999–2022, and a Crosswalk to Improve Longitudinal Linkage.* Quantifies missingness, duplication, clustering, and discordance in `BENE_ID` across MAX and TAF, and develops a conservative state-to-federal crosswalk that recovers roughly 10% of missing `BENE_ID` variables. SAS implementation code to be released upon publication. *** *Acronyms used: `BENE_ID` = CCW-assigned federal beneficiary identifier; `CCW` = Chronic Conditions Warehouse; `CMS` = Centers for Medicare & Medicaid Services; `DQ Atlas` = Medicaid & CHIP Data Quality Atlas; `DUA` = Data Use Agreement; `MAX` = Medicaid Analytic eXtract; `MSIS_ID` = state-assigned Medicaid identifier; `NDI` = National Death Index; `ResDAC` = Research Data Assistance Center; `RIF` = Research Identifiable File; `T-MSIS` = Transformed Medicaid Statistical Information System; `TAF` = T-MSIS Analytic Files; `VRDC` = Virtual Research Data Center.* --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://wiki.medicaiddatalearningnetwork.org/basics/bene_id.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.