# CMS Opt Out Affidavit Delta (`titan_coder/cms-opt-out-affidavit-delta`) Actor

Monitors named NPIs in the official CMS Opt Out Affidavits registry and reports only real changes: a new opt-out affidavit, a status change, or confirmed removal from the registry. For payer compliance, credentialing and billing teams. Free when nothing changes.

- **URL**: https://apify.com/titan\_coder/cms-opt-out-affidavit-delta.md
- **Developed by:** [Radu Furtuna](https://apify.com/titan_coder) (community)
- **Categories:** Business, Automation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$10.00 / 1,000 opt-out status changeds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.

Learn more: https://docs.apify.com/actors/running/actors-in-store.md#pay-per-event

## What's an Apify Actor?

An Actor is a serverless cloud program that runs on the Apify platform. It has two run modes.
In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours,
and optionally produces a well-defined JSON output, datasets with results, or files in key-value store.
In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server.

Apify vocabulary and the platform model are defined once, in the agent quickstart at https://apify.com/agents.md.

## How to integrate an Actor?

If asked about integration, you help developers integrate Actors into their projects.
You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready.

Do not guess an integration path. Every one of them is in the agent quickstart at https://apify.com/agents.md: the Apify MCP server, Agent Skills with the Apify CLI, the JavaScript and Python clients, the REST API, and the account-free path for an agent with no human to sign in. It also carries the rule on stating cost before the first paid run.

For examples already wired to this Actor's own input schema, see the [API](#api) section below.

Each client library has reference documentation the quickstart does not restate: [JavaScript/TypeScript](https://docs.apify.com/api/client/js/docs.md) (`npm install apify-client`) and [Python](https://docs.apify.com/api/client/python/docs.md) (`pip install apify-client`).

# README

## CMS Opt Out Affidavit Delta

Monitors named NPIs (National Provider Identifiers) in the official, free, public CMS **Opt Out
Affidavits** registry (`data.cms.gov`) and reports only genuine changes since your last check:

- **added** — a new opt-out affidavit is published for an NPI you watch (the provider has opted out of
  Medicare participation);
- **status\_changed** — an already-known opt-out record changes its actual status: `Eligible to Order and
  Refer` flips, or the `Optout End Date` moves (a renewal or a shortened window);
- **removed** — the NPI is confirmed gone from the registry (rejoined Medicare, or the opt-out lapsed
  without renewal). Confirmed only after **two consecutive** monthly checks find it missing — a single
  miss is reported as an unpaid `removal_candidate` signal, never billed;
- name, specialty, or address edits alone are **not** billed — only the two status fields above matter.

You are billed **once per real change**, not per row returned and not per run. A run that finds nothing
new is free.

### Why this exists

The source dataset (`Opt Out Affidavits`, described by `describedBy:
https://data.cms.gov/resources/opt-out-affidavits-data-dictionary`) is refreshed roughly monthly
(`accrualPeriodicity: R/P1M`). Every published API distribution gets a **brand-new UUID on every
release** — there is no `latest` alias — so this Actor re-resolves the current dataset UUID from
`https://data.cms.gov/data.json` on every run, then does one point lookup per NPI
(`?filter[NPI]=<npi>`), and remembers your last-known state per NPI in durable Apify storage so it can
tell you what actually changed.

Two competing tools were checked before building this (both confirmed live, via their own published
descriptions): one bills per delivered record on every run regardless of whether anything changed, the
other is an explicit snapshot/export tool that detects which datasets were updated, not which individual
records changed. Neither offers a durable per-NPI delta with pay-per-real-event billing.

### Input

- `monitorId` — a stable name for this monitor's durable history (`^[a-z0-9-]{1,40}$`).
- `watches` — 1 to 25 objects `{"watchId": "dr-smith", "npi": "1720444581"}`. `npi` must be exactly 10
  ASCII digits and is matched byte-for-byte against CMS's own `NPI` field — no normalization, no
  whitespace trimming, no leading-zero handling. You can add new watches under the same `monitorId`
  later; each `watchId` is permanently bound to the `npi` it was first used with.
- `notifyOn` — `new_alerts` (default, webhook only when something billable was delivered), `always`, or
  `never`.
- `webhookUrl` — optional HTTPS endpoint that receives a JSON digest of delivered (billed) changes.

### Output

- **Dataset** — one row per delivered change, plus a `run_summary` row every run. Key fields: `watchId`,
  `npi`, `status` (`added`|`status_changed`|`removed`|`removal_candidate`), `lastName`/`firstName`/
  `specialty`, `optoutEffectiveDate`/`optoutEndDate`, `eligibleToOrderAndRefer` (current or last-known),
  `previousOptoutEndDate`/`previousEligibleToOrderAndRefer`. `removal_candidate` rows carry `billed:
  false` — an early, unpaid signal that a second check will either confirm or retract.
- **Key-value store** — `coverage` (per-watch status/reason, requested/attempted/succeeded/failed counts,
  records delivered/billed, exactly what was charged for) and `digest` (a short human-readable summary).

### Guarantees and honest limits

- **At-most-once delivery and billing**, not exactly-once: an atomic claim (`RequestQueue.addRequest`) is
  the only thing that can authorize a Dataset write and a paid event. If the run crashes after claiming
  but before finishing, the event can be **lost** (never delivered) but is **never billed twice**.
- This is an **informational monitor of a published, monthly-refreshed registry** — it does not confirm a
  provider's real-time opt-out status, and it is not a substitute for verifying directly with CMS before
  making a billing or credentialing decision based on it.
- If the source structurally changes its response shape mid-registry, affected watches are marked
  `source_access_limited` rather than silently producing wrong data — this is surfaced in `coverage`, the
  digest, and (if configured) the webhook payload.

# Actor input Schema

## `monitorId` (type: `string`):

Name of this monitor's durable history (a-z, 0-9, dash; up to 40 chars).

## `watches` (type: `array`):

1-25 objects: {"watchId": "dr-smith", "npi": "1720444581"}. npi is a 10-digit National Provider Identifier, matched as an exact string against CMS's own field (no normalization — a leading zero or stray space will not match). New watches can be added later under the same monitorId.

## `notifyOn` (type: `string`):

new\_alerts — post the webhook only when new billed changes were delivered; always — post it every run; never — do not call webhookUrl at all.

## `webhookUrl` (type: `string`):

Optional. Receives a digest of delivered (billed) opt-out status changes as JSON. HTTPS only.

## Actor input object example

```json
{
  "monitorId": "example-monitor",
  "watches": [
    {
      "watchId": "dr-smith",
      "npi": "1720444581"
    }
  ],
  "notifyOn": "new_alerts"
}
```

# Actor output Schema

## `results` (type: `string`):

Every row this run produced. Key fields: watchId, npi, status (added|status\_changed|removed|removal\_candidate), lastName/firstName/specialty, optoutEffectiveDate/optoutEndDate, eligibleToOrderAndRefer (current or last-known), previousOptoutEndDate/previousEligibleToOrderAndRefer. removal\_candidate rows carry billed:false (unpaid early signal). If nothing new was found, a single run\_summary row explains why the dataset is otherwise empty. Informational only — not a real-time opt-out status check.

## `coverage` (type: `string`):

What this run actually covered and what it charged for: per-watch status/reason, records delivered and records billed, requested/attempted/succeeded/failed watch counts, removal-candidate counts. Enough to reconcile every charge against every row.

## `digest` (type: `string`):

A short human-readable summary of what this run found, written every run.

# API

You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup.

## JavaScript example

```javascript
import { ApifyClient } from 'apify-client';

// Initialize the ApifyClient with your Apify API token
// Replace the '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "monitorId": "example-monitor",
    "watches": [
        {
            "watchId": "dr-smith",
            "npi": "1720444581"
        }
    ],
    "notifyOn": "new_alerts"
};

// Run the Actor and wait for it to finish
const run = await client.actor("titan_coder/cms-opt-out-affidavit-delta").call(input);

// Fetch and print Actor results from the run's dataset (if any)
console.log('Results from dataset');
console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`);
const { items } = await client.dataset(run.defaultDatasetId).listItems();
items.forEach((item) => {
    console.dir(item);
});

// 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs

```

## Python example

```python
from apify_client import ApifyClient

# Initialize the ApifyClient with your Apify API token
# Replace '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "monitorId": "example-monitor",
    "watches": [{
            "watchId": "dr-smith",
            "npi": "1720444581",
        }],
    "notifyOn": "new_alerts",
}

# Run the Actor and wait for it to finish
run = client.actor("titan_coder/cms-opt-out-affidavit-delta").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "monitorId": "example-monitor",
  "watches": [
    {
      "watchId": "dr-smith",
      "npi": "1720444581"
    }
  ],
  "notifyOn": "new_alerts"
}' |
apify call titan_coder/cms-opt-out-affidavit-delta --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,titan_coder/cms-opt-out-affidavit-delta"
        }
    }
}
```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/tmtmpCfCpdmYS4IJc/builds/JpbcJPIWiU1gPd49E/openapi.json