If you are a provider group in a risk-based or value-based contract, you receive a monthly eligibility or attribution file from each health plan. It tells you which members you are responsible for, and it drives capitation, care management and reconciliation.

When you go looking for the data dictionary behind that file, you usually find nothing public. This note explains why, and what you can actually work with.

The problem

The file that defines "who is your patient" under a risk contract has no public specification. Each plan defines its own layout, often per contract, per product (Medicare Advantage, Medicaid, commercial) and per market. The layout document typically arrives once, at contract kickoff, and lives in someone's inbox.

The consequences are operational:

Why plans don't publish it

1. The only public standard points the other way. The X12 834 (Benefit Enrollment and Maintenance) is the HIPAA standard for enrollment data. Plans publish 834 companion guides, but those usually describe what an employer or sponsor sends to the plan, not what the plan sends to a provider.

2. The provider-facing file is contractual, not regulatory. Rosters sent to delegated or capitated groups are deliverables of the delegation agreement. Nothing obliges the plan to standardize or publish them, and they contain PHI.

3. Public companion guides cover standard transactions only. Claims (837), remittance (835) and eligibility inquiry (270/271) have published guides. Contract-specific extracts do not.

4. The cost asymmetry favors the plan. Non-standard files cost the plan support time, but reconciliation errors mostly land on the provider side.

The standard already exists: Da Vinci ATR

HL7's Da Vinci project published the Member Attribution List (ATR) implementation guide to solve exactly this. The guide itself states that no standard is currently in use for exchanging risk-contract member lists between payers and providers, and that the common practice is CSV or text files sent over email or SFTP.

ATR models the roster as a FHIR Group resource: which members are attributed to which clinicians or organizations, under which contract, for which period. It exchanges the list through FHIR Bulk Data.

What ATR does not cover: how the list is created and how discrepancies are reconciled. That gap is where most of the operational pain sits.

What changes in 2027

The CMS Interoperability and Prior Authorization Final Rule (CMS-0057-F) requires Medicare Advantage organizations, Medicaid and CHIP managed care plans, and QHP issuers on the federal exchanges to run a Provider Access API starting January 1, 2027.

That API lets in-network providers retrieve claims, encounter and clinical data for their attributed patients. It depends on the payer maintaining an attribution list and honoring member opt-outs. The Da Vinci PDex guide builds its Provider Access API on the ATR bulk export operation.

At least one large national plan already lists Group/$davinci-data-export among its published FHIR endpoints.

Two caveats:

What a provider group can do today

  1. Request the layout formally. Ask the plan's delegation or network management team for the "file layout" or "eligibility extract specification", and check the contract exhibits.
  2. Use an independent source of truth. For Medicare Advantage, the CMS Monthly Membership Report (MMR) has a publicly documented layout and can validate the plan's roster.
  3. Ask for ATR or Provider Access API in 2027 negotiations. It is the standardized path, and plans are building it anyway.
  4. Treat reconciliation as its own process. Neither the standard nor the mandate solves roster mismatches across plan file, CMS and internal systems. That needs explicit rules, ownership and monitoring.

If those roster pipelines are part of a larger move to the cloud, the Healthcare Data Migration Estimator sizes the effort, monthly cost and HIPAA risks of migrating eligibility, claims and clinical data to Databricks.

References