CMS Open Payments API - Physician x Manufacturer Roll-up (Sunshine Act)

A CMS Open Payments (Sunshine Act) API: look up physician or manufacturer general payments by name, NPI, profile ID or manufacturer, and roll them up per recipient x manufacturer - total USD, payment count, date range, product mix and payment-type mix. Turn millions of disclosure rows into a compliance-ready summary. Keyless, official CMS source.

Every row states its own completeness. CMS returns an exact match count for your query; this Actor reports it as matching_rows_total alongside rows_fetched, rows_coverage_pct and a totals_are_partial flag, so a capped pull can never be mistaken for a relationship total.

Who it's for

• Pharma / medtech compliance teams auditing physician payment exposure.
• Investigative and policy researchers analysing industry-to-physician money.
• Healthcare due-diligence teams and journalists profiling a physician, teaching hospital or manufacturer.
• AI agents needing a "look up Open Payments" tool.

What it does

Resolves the correct CMS General Payment detailed dataset from the live CMS catalogue (program years 2019-2025 as of 2026-08-01), runs four live drift assertions, queries the datastore, and aggregates each recipient x manufacturer pair into one row: total dollars, payment count, first/last payment dates, natures of payment, products and NDC codes, and CMS compliance indicators (dispute status, third-party payment, physician ownership, delayed publication). Optional NPPES specialty enrichment.

Example input

{
  "lastName": "smith",
  "firstName": "john",
  "programYear": "2025",
  "includeSpecialty": true,
  "maxResults": 500
}

Look up one physician precisely (the recommended mode):

{ "npi": "1659344299" }

Profile a manufacturer:

{ "manufacturer": "Genentech", "maxResults": 500 }

Inputs

At least one filter is required. An unfiltered run fails immediately - nothing is emitted and nothing is billed.

Output fields

One row per (recipient x manufacturer) relationship. 70 declared fields.

Recipient

Payer

Money

Payment character

Compliance indicators

Completeness, provenance and per-source status

Reliability - what this Actor asserts live, on every run

An offline test cannot see a silently degraded upstream. Before any billable row is emitted, this Actor fails the run if any of these regress. Every measured value is logged.

1. Column presence - all 91 CMS columns it reads must still exist. A CMS rename returns HTTP 400 Column not found., which previously became zero rows.
2. Dataset size - the national file must be in a plausible band (measured 2026-08-01: 2025 = 16,131,856 rows; 2024 = 15,498,687).
3. Negative control - an impossible NPI must match exactly 0 rows. If CMS ever starts dropping unsatisfied filters, every roll-up would silently become a slice of the whole national file.
4. Positive canary - last_name LIKE %SMITH% must match a plausible band (measured 2026-08-01: 89,441).

If the CMS datastore never answers, the run fails with an explicit message - it never emits "no payments found", which is not the same fact.

Limits you should know

• CMS pages via SQL OFFSET, which is O(n). Deep pulls are slow; a wall-clock budget stops very deep paging and flags the result partial.
• The datastore rejects limit > 500 (HTTP 400), so pages are 500 rows.
• A name search is a substring sweep. Use npi or profileId for a single-physician answer.
• These are CMS general payments. Research payments and ownership/investment interest are separate CMS files and are not included.

Use as an MCP tool

Available to AI agents through Apify's MCP server. Field-level descriptions are written for tool selection: an agent can read result_completeness and matching_rows_total to decide whether to re-query with a narrower filter.

Pricing

Pay per result: one event per emitted (recipient x manufacturer) relationship row. A run that fails a drift assertion or never reaches CMS emits nothing and bills nothing.

FAQ

Why did my NPI lookup return nothing before? Until v1.1 the input schema carried a server-side default of lastName: "Smith", which Apify injected into every run - so an NPI-only lookup executed as

npi = X AND last_name LIKE %SMITH%

Are these totals complete? Only when result_completeness is complete. Check totals_are_partial before quoting a figure.

Is a payment here evidence of wrongdoing? No. Open Payments is a transparency disclosure. This is a screening and research tool, not a determination about any individual.

Related actors

• CMS Part D Prescriber Delta - year-over-year Medicare Part D drug spending.
• License Verifier - multi-state clinician licence and OIG-exclusion checks.
• CMS NADAC Price Movers - drug acquisition-cost movement.