CMS Revoked Medicare Provider Delta

Watches the official CMS Revoked Medicare Providers and Suppliers registry (42 CFR 424.535) by state and reports only genuine changes since your last check: a new revocation, an updated reenrollment-bar date, or a confirmed reinstatement. Free when nothing changes — you pay only for delivered events.

Built for billing companies, payers, compliance teams and HR/credentialing departments that need to know when a provider in their book of business gets revoked from Medicare — or comes back.

Honest limits — read this before you rely on the cadence

• The source itself updates quarterly (accrualPeriodicity: R/P3M). Historical volume measured directly from CMS extracts: roughly 180–230 revocations a month nationwide, delivered in 4 windows a year of about 550 events each — not a steady daily/weekly drip. If you need a continuously-updated feed, this is not it; if you need to know "did anything change in my state since the last quarterly release," this is exactly it.
• This is an informational monitor of a public federal registry, not a real-time verification of a provider's current Medicare status. Always confirm directly with CMS/NPPES before making a business decision.
• stateCd is matched exactly, server-side, against CMS's own field (including DC). A typo gives zero matches, not an error.
• providerTypeContains is an optional, case-insensitive substring match against PROVIDER_TYPE_DESC, applied on the client on top of the state slice — it does not query the source a second time.
• Reinstatement (removed) detection needs two consecutive complete state snapshots without the ENRLMT_ID (two-strike, see below) — a single missing run only produces an unpaid removal_candidate row. Every successful fetch is a complete, verified snapshot of the state slice (one HTTP request, cross-checked against an independent row count taken immediately before it — see ROADMAP.md); a run where that cross-check fails is reported as source_access_limited rather than silently truncated, so reinstatement detection is never guessed from partial data.

How it works

1. First run per watch (monitorId + watchId) records a private baseline of every currently-revoked ENRLMT_ID matching your stateCd/providerTypeContains — no rows, no charge.
2. Every later run re-fetches the state slice from CMS and classifies each ENRLMT_ID:
   • added — a new revocation appeared;
   • changed — a previously-seen ENRLMT_ID's content changed (typically REENROLLMENT_BAR_EXPRTN_DT was extended or shortened);
   • removal_candidate — an ENRLMT_ID you'd seen before is missing from this run's snapshot for the first time in a row. Delivered as an informational row with billed: false — not charged, and not proof of anything (a single missing point is indistinguishable from a transient source hiccup);
   • removed — the same ENRLMT_ID is missing for the second consecutive complete run. Billed: the provider's registration was very likely reinstated.
3. Only added/changed/removed are billed, one PPE event each (revoked-provider-status-changed).

Input

• monitorId — name of this monitor's durable history (a-z0-9-, up to 40 chars). Re-run with the same monitorId to continue the same history; a new value starts a fresh baseline.
• watches — 1-20 objects {"watchId", "stateCd", "providerTypeContains"?}. stateCd is the 2-letter code CMS publishes for the row (53 distinct values seen, including DC). Once a watchId is used, its stateCd/providerTypeContains are locked — reusing the id with a different filter fails the run instead of silently mixing histories. Add new watchIds any time under the same monitorId.
• notifyOn / webhookUrl — optional HTTPS webhook receiving a JSON digest of billed changes.

Output

• Dataset — every row this run produced (watchId, enrlmtId, status, subjectType, name/org fields, npi, stateCd, providerTypeDesc, revocationRsn, revocationEfctvDt, reenrollmentBarExprtnDt, previousContentHash, eventId, billed). A durable named dataset holds the append-only history of everything ever delivered under this monitorId; the default (run) dataset mirrors what this run delivered plus a run_summary row.
  • billed on a removal_candidate row is always false — never charged, by design.
  • billed on an added/changed/removed row is written as null. The row is saved to the dataset before its charge is attempted (we never charge before delivery is confirmed — see "Guarantee" below), so the final charge outcome isn't known yet at write time. To find out whether one specific row was actually charged, match its eventId against this run's Pay-Per-Event charged-events ledger in the Apify Console. For the run-level total, use recordsDelivered/ recordsBilled in coverage and the unbilled count in digest.
• Key-value store — coverage (per-watch status/reason/matchedCount/windowFull, requested/ attempted/succeeded/failed, records delivered/billed; a non-fatal partial run — some watches failed, others succeeded — sets partialReason: "partial_watch_failures" and lists failedWatchReasons) and digest (a short human-readable summary, which also carries this partial-coverage warning even when no billable change occurred).

Guarantee

At-most-once delivery and billing, not exactly-once. A crash right after a right-to-bill is granted can lose that one event (it will not be redelivered), but you will never be charged twice for the same underlying change. See ROADMAP.md for the full claim protocol and its boundaries.

Durable dataset vs. default dataset

The durable named dataset is a journal of delivery attempts across every run of this monitorId — it is not itself proof of payment (a row can in rare crash scenarios be written without a confirmed charge). The default (per-run) dataset mirrors this run's rows plus one run_summary record and is what you see in the Apify Console run view. Reconcile billing against coverage, not row count alone.