2  Eligibility and Enrollment

Claims tell us about people who used healthcare. Enrollment tells us about the population that could have used it. We need both to answer even a basic question like, “How much did healthcare cost per member this month?”

Imagine two health plans that each paid $1 million in claims in January. One covered 1,000 members; the other covered 10,000. Their total spending is the same, but their cost per member is very different. If we build our population from claims alone, we also leave out everyone who had coverage and no claims. The denominator is wrong before the analysis begins.

In this chapter, we’ll work through how coverage is represented, how it changes, and how to turn that history into a useful population for analytics.

2.1 What the data represents

Eligibility describes whether someone meets the requirements for a benefit or program. Enrollment records their participation in a plan. Coverage describes the benefits in force for a period of time. These concepts are related, but being eligible to enroll does not necessarily mean someone enrolled or has active coverage.

Data suppliers often use these words interchangeably in file names. An “eligibility” file may contain coverage history and demographics; an “enrollment” file may contain only current members. Read the source definition instead of inferring the contents from the name.

For claims analytics, the central question is usually: Which people had which benefits, during which dates, in the population represented by our claims? Medical, pharmacy, dental, and vision coverage can have different histories. A member with medical coverage does not necessarily have pharmacy coverage in the same dataset. Coverage under another insurer does not guarantee that we receive those claims.

Program participation adds another distinction. A person might have health plan coverage for a full year but participate in a care management program for only three months. Keep those periods separate so that a program enrollment date does not accidentally become a health insurance coverage date.

2.2 How coverage information arrives

There are two common jobs for coverage data: checking benefits for a particular person and maintaining a population over time.

An eligibility inquiry serves the first job. For example, CMS’s HETS system accepts X12 270 requests and returns 271 eligibility responses. APIs and other interfaces may also provide coverage information for requested dates. The historical range and detail depend on the service. A successful check for one patient does not establish a complete roster of everyone covered by the plan.

Enrollment feeds serve the second job. They may arrive as X12 834 transactions, delimited files, or warehouse extracts. The 834 enrollment transaction supports enrollment changes as well as periodic full updates. The transport format and the update rules are separate questions: a CSV can contain a snapshot or a set of changes, and an API can deliver either.

Before loading a feed, establish its population, historical window, delivery schedule, record key, and correction rules. Those details determine how to maintain history correctly.

2.3 Spans and monthly records

A coverage span represents an interval during which a set of coverage attributes applies. Consider this illustrative member:

Member	Benefit	Plan	Start date	End date
A	Medical	Plan North	January 1	March 31
A	Medical	Plan South	April 1	December 31

Across the two plans, this is one member with continuous medical coverage. Enrollment in Plan North ends and enrollment in Plan South begins, but those plan-level changes do not represent a gap in the person’s coverage. Counting spans as people would count the member twice.

Spans can also split when an address, group number, selected primary care provider, or another attribute changes. Preserve the detail needed for those analyses while recognizing continuous coverage across adjacent spans. Confirm whether an end date is inclusive. An open end date might mean coverage is ongoing, or it might mean the date is missing; the source contract must tell you which.

A member-month file summarizes coverage by calendar month. Its grain may be member, month, and benefit; it may also include plan or group. “One row per member per month” is therefore something to verify. Monthly files may contain partial-month coverage, so the presence of a row does not by itself establish a full month of exposure.

Overlapping spans require similar care. Two identical medical spans may be duplicates. Two spans from different insurers may represent valid overlapping coverage. Two conflicting versions of the same enrollment may reflect a correction. Resolve these cases using source identifiers and update rules before counting covered days. For a person-level medical denominator, count the union of relevant covered days so that one person cannot contribute the same day twice.

2.4 Snapshots, changes, and retroactivity

Coverage history changes after the fact. A newborn may be added with coverage effective at birth. A termination may arrive after the termination date. An earlier end date may be corrected. These are retroactive changes: we learn something today that changes our understanding of an earlier period.

The way a feed communicates those changes determines how we should process it.

Delivery pattern	What it means	What the receiving system needs to do
Full snapshot	All records within a defined population and time window	Replace or reconcile that scope, including records removed from it
Change feed	Adds, updates, and possibly deletes since a prior delivery	Apply each operation to the correct existing record
Rolling replacement	A recent historical window is restated	Replace that window and preserve history outside it

A change feed can handle retroactivity perfectly well if it includes the necessary historical corrections. Conversely, a monthly snapshot of currently active members cannot reconstruct past coverage by itself. Neither “incremental” nor “full replacement” tells you enough without knowing the scope.

Keep the effective coverage dates distinct from the date the record was received. Suppose a March delivery changes a member’s coverage end date from March 31 to January 31. A current view should remove February and March coverage. A report reproducing what was known in February should use the earlier information. Retaining source deliveries or equivalent version history lets you answer both questions.

When coverage changes, rebuild affected member months and dependent measures. A revised denominator can change PMPM even when the claims numerator stays the same. Agree on whether published reports are restated and which data cutoff governs a contractual calculation.

2.5 Member identity and changing attributes

Enrollment data usually carries more than coverage dates. Several fields deserve attention because a plausible join can still produce the wrong population.

Member and subscriber identifiers. A subscriber is the policyholder; a member is an individual covered under the policy. Several members may share a subscriber identifier. Use a person-level identifier for person-level analysis, preserve the source that issued it, and account for identifier changes. A subscriber ID alone is not a patient key.

Demographics. Calculate age at the date relevant to the analysis using date of birth when available. A current age copied onto historical records will misclassify earlier periods. Address and other attributes may describe the coverage period or the latest known state. Make that distinction explicit when analyzing historical populations.

Plan and benefit attributes. Preserve the product, benefit, employer group, and other dimensions needed to define the population. A benefit administered outside the supplied claims feed needs its own treatment; it should not silently enter a denominator for spending we cannot observe.

Provider relationships. A member-selected primary care provider, a plan-assigned provider, and a provider attributed from claims are different relationships. Keep their effective dates and methods. They answer different questions about responsibility for a patient’s care.

An EHR may contain insurance information collected for registration and billing. That information can help explain a visit, but it may be a current snapshot or a history of recorded updates rather than a complete payer enrollment history. Determine what the extract preserves before using it to define covered time.

2.6 From coverage to exposure

For monthly cost and utilization analyses, we commonly transform coverage into member months, a unit of population exposure. There is more than one defensible counting convention, and they produce different answers.

Suppose Member A is covered throughout a 30-day month and Member B is covered only on the last day:

Convention	Member A	Member B	Total member months
Any covered day	1	1	2
Covered on the 15th	1	0	1
Full month of coverage	1	0	1
Covered days divided by days in month	1	1/30	1.0333

With $1,000 of claims attributable to these members’ covered days, PMPM is $500 under the any-day convention and approximately $967.74 under the fractional convention. Neither denominator can be interpreted without its definition. The point-in-time and full-month conventions may also require different numerator inclusion rules; do not switch denominators while leaving the population implicit.

Choose the convention that fits the measure or agreement, and use it consistently across periods and comparison groups. Reconcile covered people, covered days, and member months to the source before interpreting cost trends. Then check that claims link to the intended members and coverage dates, and investigate unmatched claims instead of dropping them silently.

The Member Months chapter develops the denominator further. The essential work here is establishing a coverage history that includes members with no claims, handles corrections, and represents the benefits we can actually observe.