CMS Procedure Reimbursement — HCPCS by Locality, Per Record

Turn CMS's Physician/Supplier Procedure Summary into clean, per-record reimbursement benchmarks - one row per HCPCS procedure code x specialty x carrier x pricing locality x place-of-service, with submitted, allowed and denied service counts and charge/payment amounts, ready for provider-network analysts to benchmark allowed payments.

Each row from the CMS data API becomes one clean, flat record with numeric fields coerced to real numbers, CMS's *-suppressed cells delivered as null (not zero), a stable record_id, and provenance stamped on every row: source, dataset UUID, the public-domain notice, attribution, a UTC retrieval timestamp and an interpretation caveat.

What one record represents

The source is the U.S. Centers for Medicare & Medicaid Services (CMS) open data API — dataset 164fc736-4179-4100-9f79-592b69e41975, Medicare Physician/Supplier Procedure Summary (PSPS). Each record is one procedure summary cell: a HCPCS/CPT code (with modifiers) for a specialty code, carrier, pricing locality, type-of-service and place-of-service, carrying submitted/allowed/denied service counts and charge amounts and the NCH payment amount. specialty_code is a specialty code, not a provider - there is no NPI or provider name anywhere in the dataset.

For each record you get the analytic columns listed below (reproduced verbatim, numbers as numbers) plus a composite record_id and the provenance block. Columns include hcpcs_code (+ initial/second modifiers), specialty_code, carrier_number, pricing_locality_code, type_of_service_code, place_of_service_code, submitted_service_count, submitted_charge_amount, allowed_charge_amount, denied_services_count, nch_payment_amount and betos_code.

Coverage and volume

The full dataset holds 14,474,585 procedure-summary rows across every HCPCS code, specialty, locality and place-of-service. Because that is far too large to return whole, this Actor pulls one HCPCS code at a time via a required input (a single common code such as 99213 already yields ~180,000 rows).

Live full-dataset count is 14,474,585 records - matches the Wave-3 index figure exactly; that whole-dataset figure is the capacity line, retrieved one HCPCS code per run.

The Actor filters the CMS data API to your chosen HCPCS code (filter[HCPCS_CD]) and pages within it (size/offset), stopping at your Maximum records cap.

Licence and attribution

CMS open data is a public-domain U.S. Government work (17 U.S.C. §105) — free to use, redistribute and build on. The developer FAQ that governs the API is published by CMS; the full notice travels on every record:

U.S. CMS (Centers for Medicare & Medicaid Services). Public-domain U.S. Government work (17 U.S.C. 105). Reproduced verbatim; no third-party content. Aggregate procedure-summary rows only - no provider, NPI, or beneficiary data.

The required attribution — U.S. Centers for Medicare & Medicaid Services (CMS) — is present on every record.

Interpretation caveat

Aggregate Medicare procedure summary (PSPS). Charge and payment amounts are Medicare-allowed and NCH-paid figures, not provider list prices. specialty_code is a specialty code, not a provider; there is no NPI or provider name.

Values are reproduced verbatim from the API. CMS suppresses small cells with an asterisk (*) for privacy; those are delivered as null so you can tell "suppressed" apart from a real zero. The indicator fields (asc_indicator, error_indicator) are reproduced verbatim as codes.

Person-data policy

There is no provider, NPI, or beneficiary data in this dataset - specialty_code is a coded specialty, and every other column is a code, count or amount. The field list this Actor emits is a fixed allow-list, and a per-record assertion rejects any row that would introduce an NPI, provider-name, or contact field (verified with a planted- field test). This is aggregate benchmark data about drugs, procedures, manufacturers and localities — never about individual patients or providers.

Data quality and freshness

Numeric fields are coerced to real numbers and booleans to real booleans; suppressed cells become null. Every run re-reads the live API, so the data is as fresh as CMS publishes, and each record's observed_at stamp records when it was retrieved. Delivery is in the API's order and keyed on the source-native composite, so the dataset is safe to diff, deduplicate or upsert. The run's RUN_RECEIPT records the API's reported total row count alongside how many records were delivered and charged.

Provenance and compliance

Every run reads data.cms.gov/robots.txt at runtime; the gate result (URL, status, byte length, SHA-256 of the policy) is written to the run's RUN_RECEIPT. The API is keyless. The Actor never bypasses a block or fetches through a mirror.

Inputs

• HCPCS code (hcpcsCode, required) - the procedure code to pull (e.g. 99213 office visit, 99233 hospital care). The dataset is too large to pull whole, so it is retrieved one code at a time.
• Maximum records (maxRecords) — hard cap on records delivered and billed.

Output

Records land in the Actor's default dataset and export as JSON, CSV, Excel or via the Apify API. A tabular overview view surfaces the most useful columns for quick inspection.

Fields in detail

The record leads with the HCPCS code and its dimension codes (specialty, carrier, locality, type- and place-of-service), then the service counts and charge/payment amounts. The provenance block — source, source_dataset, licence, attribution, caveat, observed_at — closes every record, so a single row is self-describing and audit-ready.

Working with CMS suppression

CMS suppresses small cells with an asterisk (*) to protect privacy. This Actor maps every suppressed numeric cell to null rather than to zero or the literal string *, so your downstream aggregations do not silently treat a suppressed value as a real number. A null in a count or amount column therefore means "CMS suppressed this cell", not "reported zero" — an important distinction when you sum or average across rows. Text and code columns are always passed through verbatim, so codes such as HCPCS, BETOS, carrier and locality remain exactly as CMS publishes them and join cleanly against CMS reference tables.

Scaling and limits

Set Maximum records low to sample cheaply or high to pull the full set (or, for the partitioned dataset, the full slice for your chosen code). The Actor pages the API server-side and delivers incrementally, so memory stays flat regardless of how many records you request, and you are billed only for what is delivered. Because CMS refreshes these datasets on its own publication calendar, re-running the Actor picks up new periods automatically, and each record's observed_at stamp dates the snapshot — schedule a run to keep a downstream benchmark table current.

Sibling Actors

This Actor benchmarks procedure reimbursement at the aggregate (specialty x locality) level. It complements the fleet-1 Medicare Provider Intelligence cell (provider-level intelligence) - aggregate reimbursement benchmarks versus provider-level detail are two different jobs. This Actor also shares its engineering — the runtime robots gate, push-then-charge billing and verbatim-value discipline — with the fleet's other public-data records Actors.

Pricing

This Actor uses Apify's pay-per-event model: a flat $0.05 per record actually delivered to the dataset, and nothing else — no monthly rental, no per-run base fee, no compute charge. Deliver 40 records and you pay $2.00; deliver 10,000 and you pay $500.00. Billing is wired after delivery — each record is pushed first and only then does the per-record event fire — so a mid-run failure can only ever under-charge you, never over-charge. Use Maximum records to cap spend precisely.

Typical uses

Benchmark Medicare allowed payments by procedure, specialty and locality; compare submitted versus allowed versus paid amounts; screen denial rates by code; build a fee-schedule reference; or feed a provider-network, contracting or revenue-cycle model with clean reimbursement records.

What this Actor does not do

It does not deliver provider-level, NPI-level, or beneficiary-level data — it is an aggregate benchmark table; it does not forecast or model; and it does not alter any published value beyond coercing types and mapping CMS's * suppression to null. It gives you faithful, public-domain, analysis-ready records with a provenance trail you can audit on every run.