Payer Contract Intake Checklist for a Market Share Analysis

Most payer contract exports aren't clean. They're a patchwork of legal entity names, regional licensee variants, and abbreviations that don't match anything in a public enrollment dataset without work. That's normal. It's also the single biggest thing that stalls a market share pilot before it starts: whoever has the contract list isn't sure what to send, so nothing gets sent.

Part of the stall is a misunderstanding about what's actually being asked for. "Contract data" sounds like it means rates and terms, so it gets routed to legal review and sits there. It doesn't mean that here. None of the seven fields below touch reimbursement, fee schedules, or negotiated terms. They're entity-identifying metadata, most of which already lives in a credentialing file or an EDI payer enrollment setup, not the signed agreement itself. Hold the rates back; they're not part of this input.

Here's what actually moves a contract-to-enrollment resolution forward, ranked by how much it matters.

The fields, in priority order

1. Payer ID from your billing/EDI system, if you have one. This is the single most valuable field. If a payer ID is already attached to claims history for a contract, resolution can skip name-matching entirely and go straight to a confirmed identity, with no ambiguity and no manual review.
2. Exact contract/payer name, as written in the contract. Not a shorthand or internal nickname, but the literal legal name on the signature page, even if it looks nothing like the carrier's consumer-facing brand.
3. State(s) the contract covers or is licensed in. A contract can be state-specific or multi-state; flag every state it actually applies to, not just the one it was negotiated in.
4. Line of business: commercial, Medicare Advantage, and/or Medicaid. A single contract frequently covers more than one; flag all that apply rather than picking one.
5. Parent company or plan brand, if different from the contracting entity. Carriers routinely contract under one legal name while operating under a completely different consumer-facing brand in that state.
6. Product/plan name, if the contract is scoped to one product line under a larger parent. Relevant when a contract covers, say, only a specific Medicaid MCO product and not that same parent's commercial or MA line.
7. Contract effective and (if applicable) termination date. Confirms the contract is actually active for the period the analysis covers.

One caution on field 1: a "payer ID" pulled off an 837 claim is sometimes a clearinghouse's routing ID rather than the insurer's own identifier. It'll still match to something in an EDI system, which makes it easy to trust, but a routing ID doesn't correspond one-to-one with a licensed payer entity in enrollment data. If you're not sure which kind of ID you're looking at, flag it as uncertain rather than treat it as a confirmed match; it changes how much weight resolution puts on that field versus name and state.

The trap that brand-name matching falls into

A pattern we see often (illustrative, not a specific engagement): a contract list comes in with every Blue Cross Blue Shield contract simply labeled "BCBS" or "Blue Cross." That's a badge, not an entity: it's licensed to roughly three dozen independently owned and operated companies, each with its own legal name, its own state footprint, and its own enrollment data. Match on brand alone and you'll either double-count coverage across licensees that share a name, or miss it entirely because the enrollment source lists the licensee's actual legal name and your export never gave resolution a legal name to match against. The same failure shows up with Medicaid MCOs that rebrand per state under a shared parent, and with regional plans that also run a separate commercial brand in the same state under a different name.

The fix isn't cleanup after the fact. It's fields 2 and 5 filled in correctly at intake: the literal legal name on the contract, plus the parent or brand if the two differ. Skip that step and no amount of downstream fuzzy matching recovers a market share number you can actually defend in front of a payer relations team.

What a partial export still gets you

A full export with all seven fields produces the cleanest resolution, but it's not the bar for starting. Contract name, state, and a TIN or payer ID, even for just a fraction of your book, is enough to run a real pilot and show whether the approach works before you commit to gathering the rest.

The fields that matter most if you can only pull a few: payer ID, contract name, and state. Everything else refines the match; those three are what make the match possible at all.

Why this differs from a billing/reimbursement audit checklist

If you've searched for "payer contract audit checklist" before, most of what you'll find (including the American Medical Association's own checklist) is built for a different job: verifying fee schedules, tracking denial patterns, and preparing for a payer's own records request. That's a reimbursement-compliance exercise. This is an entity-resolution exercise instead: matching your contract to a real payer identity in enrollment data so your actual market share can be calculated. The inputs barely overlap, which is why handing a generic audit checklist to whoever owns the contract list is often what sends it into legal review in the first place: it reads as "give me your rates," when what a market share pilot actually needs is "give me your entity name."

Start with what you have

Medlyze's Payer Network Coverage & Market Share Analysis runs a single-state pilot first, using exactly the fields above. Even a partial list is enough to kick it off, and the pilot fee is credited in full toward your full rollout if you move forward.

Get a pilot quote →