Dataset

Payer Coverage Requirements

Every hurdle an insurer puts between a prescription and a payment — prior authorization, step therapy, site limits, renewals.

What does the insurer require before it will pay at all?

Coverage rules as structured data — prior authorization, step therapy, site-of-care limits and renewal intervals, quoted from each insurer’s own published policy.

What you getOne row per rule, per insurer, per code, per policy version

What it coversCommercial medical policy across the insurers we cover

What it is joined toPolicy on its own, or joined to rates

Buy the slice you need

You do not have to take the whole grid. Every slice is the same columns, the same quality gates and the same quarterly refresh over less of it — and slices stack, so nothing is ever bought twice.

One drug, one insurer

A single pair. The floor price, for settling one argument.

$6,000a year

Get this

One drug, every insurer

How all 30 insurers treat a single drug — a launch team’s first question, answered as a table.

$15,000a year

Get this

One insurer, every drug

Everything that insurer requires across all 104 drugs. A median of 86 pairs per insurer.

$25,000a year

Get this

One therapeutic area

Every drug in a class, across all 30 insurers.

$55,000a year

Get this

Everything

All 2,423 pairs, refreshed quarterly.

$150,000a year

Get this

What is in it

Prior authorization, step therapy, site-of-care limits, quantity limits and renewal intervals
Every rule quoted word for word, with a link to the insurer’s own document and the page it came from
Each rule stamped with the policy version and the dates it was in force
Commercial, Medicare Advantage, Medicaid and exchange kept in separate, labelled rows
Parsed fields you can filter on — rule type, how many drugs must fail first, which ones

Questions it answers

Which insurers require two other drugs to fail before ours, and which two?
What did this insurer’s policy actually say in March, when the claim was denied?
Which insurers will not let this infusion be given in a hospital outpatient department?

What it does not do

It contains no prices.

Not one. If you need the rules and the rates in the same row, that is Rates + Requirements.

It does not cover policies published behind a login.

Only what an insurer publishes openly on its provider site.

Who buys this

Market access and patient access teams
Prior authorization and billing software vendors
Anyone modelling how long it takes a patient to start therapy

Why it is worth the money

Quoted, not summarized

Every rule ships with the exact sentence from the insurer’s policy, a link to the document and the page it came from. Any row can be checked against the source document directly.

You can ask what applied last March

Policies get reissued constantly. Rows carry the version and its dates, so you can look at what was in force when a claim was filed, not just what is true today.

Commercial rules stay separate from Medicaid

Line of business is its own column and is never guessed. A Medicaid-only rule presented as commercial would be a real error, so we keep them apart.

Filterable, not a wall of text

Rule type, number of required prior drugs, preferred alternatives and renewal interval are parsed into their own columns.

The columns

Published in full, before you talk to anyone. Whether this fits your model is a technical question and you should be able to answer it yourself.

`coverage_cell`

One row per drug and insurer: whether prior authorization applies, what has to be tried first, which diagnoses are covered, and where the drug may be given.

Key payer_slug × drug × lob

Column	Type	What it is
`payer_slug` key	TEXT	The insurer. Joins to the rate tables.
`drug` key	TEXT	Active ingredient. Coverage rules are written at this level, not at code level.
`lob` key	TEXT	Line of business, taken from the policy and never inferred. Every row in the current build is commercial; Medicare Advantage, Medicaid and exchange are the same column and are not yet populated.
`prior_auth_required`	BOOLEAN	Whether approval is needed before the drug is given. True on 81% of rows.
`preferred_products`	TEXT[]	What the insurer wants tried first.
`products`	JSONB	Product-level detail where the policy distinguishes brands or biosimilars.
`covered_dx`	JSONB	Covered diagnoses with their ICD-10 codes and any dose ceiling, keyed by indication.
`site_of_care`	JSONB	Whether a site-of-care program applies and what it says.
`citations`	JSONB	The quote behind each field, so any value can be traced to a sentence.
`source_url`	TEXT	Direct link to the insurer’s own document.
`effective_date`	DATE	The insurer’s policy date. Present on 85% of rows.
`veracity`	TEXT	How the row was established: verified on 1,625 rows, corroborated on 798.
`confidence`	TEXT	Confidence in the extraction, high or medium. Nothing lower is shipped.
`signals`	JSONB	Supporting evidence found while reading the policy.
`attested_absent`	TEXT[]	Requirements we looked for in the policy and confirmed are not there — a step-therapy rule, a TB screen, a site-of-care program. A verified absence, not a gap. Non-empty on 1,577 of 2,423 rows.

`coverage_rule`

The individual rules behind each cell, each carrying the sentence it came from.

Key rule_id — one row per rule

Column	Type	What it is
`rule_id` key	TEXT	Primary key. One row per rule. A single drug-and-insurer pair routinely carries many rules of the same type — one policy states twenty separate clinical prerequisites — so the other columns do not form a key and joining on them fans rows out.
`payer_slug`	TEXT	The insurer. Joins to coverage_cell and to the rate tables.
`drug`	TEXT	Active ingredient.
`rule_type`	TEXT	covered_indication, step_therapy, site_of_care, quantity_limit, reauth, exclusion and so on.
`indication`	TEXT	What the rule is about, e.g. rheumatoid_arthritis. Empty where the rule applies to the drug generally rather than to one diagnosis.
`hcpcs`	TEXT	The billing code the rule attaches to, and the join to the rate tables. Present on 43% of rules: the rest are written about the drug rather than about a code, and we do not attach a code the policy did not name. At the cell level 76% carry at least one coded rule.
`value`	JSONB	The parsed rule — ICD-10 list, dose ceilings, required prior drugs, notes.
`citation_quote`	TEXT	The exact sentence from the policy. Never reworded.
`source_url`	TEXT	Link to the document the quote came from.
`effective_date`	DATE	When the policy version took effect.

Traps in this data, and how we handle them

These catch people out whoever they buy from. They are worth knowing before you model anything with rate or coverage data, including ours.

The insurer’s own policy is often not the rule that gets applied

Why it bitesHealth plans routinely delegate clinical review to specialty benefit managers. Imaging, oncology, cardiology and musculoskeletal reviews are commonly handled by third parties on the plan’s behalf, and the criteria that decide the case are the delegate’s, not the plan’s. A team reading only the insurer’s published policy can be reading the wrong document.

How we handle itWhere a plan discloses that review is delegated, we record who actually adjudicates alongside the rule, so you can tell when the published policy is not the operative one.

The same drug has different rules under the medical and pharmacy benefit

Why it bitesA drug given in a clinic runs under the medical benefit. The same molecule dispensed to the patient runs under pharmacy. The criteria, the reviewer and the appeal path can all differ.

How we handle itRules are labelled by the benefit they belong to. We do not merge a medical policy and a formulary rule into one row, because they are not the same rule.

A Medicaid rule presented as a commercial rule is a real error

Why it bitesInsurers publish policies across commercial, Medicare Advantage, Medicaid and exchange lines, often in the same document set, and the restrictions differ sharply between them.

How we handle itLine of business is a first-class column and is never inferred. If a policy does not state it, the row says so rather than guessing. Worth being plain about what that means today: every row in this build is commercial. We would rather ship one line of business you can trust than four you have to audit.

Policies get reissued, and the version that matters is the one in force then

Why it bitesA denial in March was decided under March’s policy. Reading today’s version tells you what would happen now, not what happened.

How we handle itEvery rule carries its policy version, effective date and retirement date, so you can ask what applied on a given day.

National policies get overridden locally

Why it bitesA plan operating in several states can carry a national medical policy and a state-specific variation that contradicts it.

How we handle itRules stay attached to the entity that published them. We do not roll a regional variation up into a national statement.

Some of the criteria are not public at all

Why it bitesPart of a plan’s criteria may sit behind a provider login, or inside a delegate’s proprietary pathway that is never published.

How we handle itOut of scope, and said plainly. The dataset covers what is published openly, and the coverage page tells you which plans that is.

What to know before you buy

Coverage grows insurer by insurer on a published schedule rather than arriving all at once. Current coverage is on the coverage page.
Policies an insurer publishes only behind a provider login are out of scope.

Load it against your own model

Three states, the production columns, real rows, downloaded directly with no form in front of it. It is the fastest way to answer the fit question.

Download the free sample