# Hospital Ownership Change Radar (`lukehunter/hospital-chow-radar`) Actor

Find hospitals that just changed ownership, filterable by state and date range, with buyer, seller, effective date, and owner details, so vendors have a timely reason to reach the new decision-makers.

- **URL**: https://apify.com/lukehunter/hospital-chow-radar.md
- **Developed by:** [Luke Hunter](https://apify.com/lukehunter) (community)
- **Categories:** Lead generation
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

$100.00 / 1,000 opportunities

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

## Hospital Ownership Change Radar — CHOW & M\&A Leads

**For GPOs, EHR/IT and RCM vendors, equipment leasing companies, staffing agencies, and insurance/benefits brokers who sell into hospitals right after they change hands.** One run returns hospitals that just changed owner, with buyer, seller, effective date and organizational-owner details, straight from official CMS filings.
Pay-per-result: **$0.10 per delivered opportunity — 100 leads = $10.00.**
Try it free with Apify's monthly platform credit.

This Actor reads the official CMS **Hospital Change of Ownership (CHOW)** dataset and its owner-information companion, joins them, and returns one row per ownership-change transaction — buyer, seller, effective date, and organizational owner details — filtered to the states, transaction types, and time window you choose. A hospital that has just changed hands is a natural buying trigger: new owners re-evaluate group purchasing (GPO) agreements, EHR/IT vendors, equipment leasing, staffing contracts, insurance and employee-benefits brokers, and marketing agencies.

### Quick start (2 minutes)

1. Open the **Input** tab (no CMS account or key needed — the source is public).
2. Use this prefill for recent and upcoming Texas/Florida ownership changes:

```json
{
  "states": ["TX", "FL"],
  "lookbackDays": 365,
  "futureDays": 180,
  "transactionTypes": [],
  "maxItems": 250
}
```

3. Click **Start**. Open the dataset's Ownership-change opportunities view, or export as CSV, Excel or JSON.

### Use cases

- **GPOs, EHR/IT and RCM vendors** reaching a new hospital owner while incumbent vendor contracts are actively being re-evaluated.
- **Medical equipment leasing and staffing agencies** pitching new ownership before renewal decisions lock in for another cycle.
- **Insurance and employee-benefits brokers** approaching a newly acquired hospital's HR/benefits team during transition.
- **Healthcare M\&A researchers** tracking institutional or corporate ownership behind hospital transactions by state.

### Run it weekly

1. Set your `states`/`transactionTypes` filters, then click **Schedule** on the run page (or create one under **Schedules** in the Apify Console).
2. A weekly schedule catches newly published CHOW filings as CMS posts them.
3. Keep `opportunityId` as your dedupe key across runs — it's a stable composite identifier, so a scheduled pull never double-charges or double-lists the same transaction. `retrievedAt` tells you when each row was last confirmed against CMS.

### Why use this hospital ownership change tracker?

| Need | What this Actor gives you |
|---|---|
| Hospital acquisition / CHOW leads | One row per CMS-published ownership-change transaction, nationwide or by state |
| Timing | `derivedTimingSignal` buckets each deal as recently closed or upcoming |
| Buyer research | Buyer legal name, DBA, state, provider type, NPI, CCN, enrollment ID |
| Seller/incumbent research | The same fields for the outgoing owner, for "who did they leave" context |
| Ownership-structure signals | Organizational owner names and CMS-published owner-type flags (holding company, investment firm, financial institution, and more) for both sides |
| Filtering | Narrow by state, transaction type, or a custom look-back/look-ahead window |
| Predictable spend | `maxItems` is a hard cap on delivered opportunities and therefore on billable results |
| Traceability | Every row links back to the original CMS dataset and records when it was retrieved |

The Actor is intentionally focused on one job: turning two CMS datasets into a clean list of ownership-change opportunities. It does not scrape hospital websites, enrich contacts, or guess at deal value.

#### Spot institutional and corporate ownership behind a hospital transaction

`buyerOwnerSignals` and `sellerOwnerSignals` surface CMS's own published owner-type classifications for organizational owners — including holding company, investment firm, financial institution, management services company, medical staffing company, consulting firm, and created-for-acquisition — so you can filter for deals where the buyer or seller sits behind a corporate or institutional ownership structure, not just an operating hospital name.

### Input

```json
{
  "states": ["TX", "FL"],
  "lookbackDays": 365,
  "futureDays": 180,
  "transactionTypes": [],
  "maxItems": 250
}
```

| Field | Type | Default | Description |
|---|---|---:|---|
| `states` | string\[] | `[]` | Up to 20 two-letter US state/territory codes. A transaction matches when either the buyer's or the seller's enrollment state is in this list. Leave empty for nationwide results. |
| `lookbackDays` | integer | 365 | 0–3650. Include ownership changes effective this many days before today. |
| `futureDays` | integer | 180 | 0–730. Include published ownership changes with a future effective date, up to this many days ahead. |
| `transactionTypes` | string\[] | `[]` | Up to 3 of `CHOW`, `ACQUISITION/MERGER`, `CONSOLIDATION`. Leave empty for all published types. |
| `maxItems` | integer | 250 | 1–2000. Hard cap on opportunities delivered and therefore on billable results. |

For most users, the only settings that matter are **States** and **Maximum opportunities**.

### Output fields

Each row describes one CMS-published ownership-change transaction, with matching fields for the buyer (new owner) and the seller (outgoing owner).

| Field | Description |
|---|---|
| `opportunityId` | Stable composite identifier for the transaction |
| `transactionType` | CMS-published CHOW transaction type |
| `effectiveDate` | CMS-published effective date, normalized to `YYYY-MM-DD` |
| `daysFromToday` | *Derived.* Signed days from the run date to the effective date |
| `derivedTimingSignal` | *Derived.* One of `upcoming_90d`, `upcoming_later`, `recent_90d`, `historical` |
| `buyerEnrollmentId`, `sellerEnrollmentId` | CMS PECOS enrollment ID |
| `buyerAssociateId`, `sellerAssociateId` | CMS associate ID |
| `buyerNpi`, `sellerNpi` | National Provider Identifier |
| `buyerCcn`, `sellerCcn` | CMS Certification Number |
| `buyerLegalName`, `sellerLegalName` | Organization legal name |
| `buyerDbaName`, `sellerDbaName` | Doing-business-as name |
| `buyerState`, `sellerState` | Enrollment state |
| `buyerProviderType`, `sellerProviderType` | CMS provider type text |
| `buyerOwnerOrganizationNames`, `sellerOwnerOrganizationNames` | Semicolon-separated organizational owners from CMS's owner-information dataset. Individual (person) owner records are excluded by design — this field only ever names organizations |
| `buyerOwnerOrganizationCount`, `sellerOwnerOrganizationCount` | Count of distinct organizational owners matched |
| `buyerOwnerSignals`, `sellerOwnerSignals` | *CMS-published, not inferred.* CMS's own organizational-owner type flags (`created_for_acquisition`, `management_services_company`, `medical_staffing_company`, `holding_company`, `investment_firm`, `financial_institution`, `consulting_firm`), joined as a compact list where CMS marked them |
| `buyerMaxPublishedOwnershipPct`, `sellerMaxPublishedOwnershipPct` | Highest ownership percentage CMS published among matched organizational owners |
| `sourceDatasetId`, `sourceOwnerDatasetId` | CMS dataset identifiers used for this run |
| `sourceUrl`, `sourceOwnerUrl` | Links to the official CMS dataset pages |
| `retrievedAt` | ISO 8601 UTC timestamp when the data was retrieved |

Missing values are returned as `null`. The Actor does not invent buyer/seller details, contact information, or deal value — everything except the two derived timing fields and the owner-summary counts is a fact CMS itself published.

### Example output

```json
{
  "opportunityId": "O20021125000001:O19991231000099:2026-08-15:2",
  "transactionType": "ACQUISITION/MERGER",
  "effectiveDate": "2026-08-15",
  "daysFromToday": -38,
  "derivedTimingSignal": "recent_90d",
  "buyerEnrollmentId": "O20021125000001",
  "buyerLegalName": "EXAMPLE REGIONAL HEALTH SYSTEM INC",
  "buyerDbaName": null,
  "buyerState": "TX",
  "buyerProviderType": "PART A PROVIDER - HOSPITAL",
  "buyerOwnerOrganizationNames": "EXAMPLE HOLDINGS LLC",
  "buyerOwnerOrganizationCount": 1,
  "buyerOwnerSignals": "holding_company; investment_firm",
  "buyerMaxPublishedOwnershipPct": 100,
  "sellerEnrollmentId": "O19991231000099",
  "sellerLegalName": "EXAMPLE COMMUNITY HOSPITAL INC",
  "sellerDbaName": null,
  "sellerState": "TX",
  "sellerProviderType": "PART A PROVIDER - HOSPITAL",
  "sellerOwnerOrganizationNames": null,
  "sellerOwnerOrganizationCount": 0,
  "sellerOwnerSignals": null,
  "sellerMaxPublishedOwnershipPct": null,
  "sourceDatasetId": "c04031db-54ce-461c-85d1-d2613d71f167",
  "sourceOwnerDatasetId": "60625dc8-b621-45f0-9423-077fd133b13e",
  "sourceUrl": "https://data.cms.gov/provider-characteristics/hospitals-and-other-facilities/hospital-change-of-ownership",
  "sourceOwnerUrl": "https://data.cms.gov/provider-characteristics/hospitals-and-other-facilities/hospital-change-of-ownership-owner-information",
  "retrievedAt": "2026-09-22T00:00:00.000Z"
}
```

*(Names above are illustrative examples, not real transactions.)*

| Field | Value (illustrative) |
|---|---|
| `transactionType` | `ACQUISITION/MERGER` |
| `effectiveDate` | `2026-08-15` |
| `derivedTimingSignal` | `recent_90d` |
| `buyerLegalName` | `EXAMPLE REGIONAL HEALTH SYSTEM INC` |
| `buyerOwnerOrganizationNames` | `EXAMPLE HOLDINGS LLC` |
| `buyerOwnerSignals` | `holding_company; investment_firm` |
| `sellerLegalName` | `EXAMPLE COMMUNITY HOSPITAL INC` |
| `sellerOwnerOrganizationNames` | `null` |

### Use it as a hospital M\&A data API

The Actor can be called from any application through the Apify API.

```python
from apify_client import ApifyClient

client = ApifyClient("YOUR_APIFY_TOKEN")

run = client.actor("YOUR_USERNAME/hospital-chow-radar").call(
    run_input={
        "states": ["TX", "FL"],
        "lookbackDays": 365,
        "futureDays": 180,
        "maxItems": 250,
    }
)

for opportunity in client.dataset(run["defaultDatasetId"]).iterate_items():
    print(opportunity["effectiveDate"], opportunity["buyerLegalName"], opportunity["sellerLegalName"])
```

Use Apify schedules to catch newly published ownership changes automatically, and webhooks or integrations to route new opportunities into your CRM.

### Pricing and cost control

This Actor uses **pay-per-result** pricing: **$0.10 per delivered opportunity**, billed once per opportunity for each run. Check the Apify **Pricing** tab for the current rate.

There is no charge for starting a run or for source rows that don't match your filters. `maxItems` is a hard cap on the number of opportunities delivered — and therefore billed — in a single run. Identical transactions are de-duplicated within a run so you are never charged twice for the same CHOW filing.

### Reliability and data quality

The Actor is designed to fail visibly rather than quietly return misleading data.

- If either CMS dataset's structure changes in a way the Actor depends on, the run fails with a clear error instead of silently returning wrong or incomplete data.
- If either source unexpectedly returns zero rows before any filtering, the run fails rather than reporting an empty result as if it were a real "no activity" finding.
- Requests to CMS are retried with backoff on transient failures; ordinary client errors fail immediately instead of retrying forever.
- Identical source transactions are de-duplicated within a run.
- Missing values are returned as `null`, never guessed.

### Important limitations

- **Organizations only, not individuals.** CMS's owner-information dataset includes both organizational and individual (person) owners. This Actor deliberately excludes individual owner records — `buyerOwnerOrganizationNames`/`sellerOwnerOrganizationNames` and the owner-signal fields only ever reflect organizations, never named people.
- **Owner-type signals are CMS's own classifications, not this Actor's inference, and they are narrower than they might sound.** `buyerOwnerSignals`/`sellerOwnerSignals` report only the seven organizational-owner type flags CMS itself publishes in this dataset — `created_for_acquisition`, `management_services_company`, `medical_staffing_company`, `holding_company`, `investment_firm`, `financial_institution`, `consulting_firm`. They are not derived by matching keywords in company names, and they reflect what CMS had on file as of the source data, not a current verified ownership structure. An `investment_firm` or `financial_institution` flag means CMS classified the organizational owner that way on its enrollment paperwork — it is a useful pointer to an institutional or corporate owner behind the transaction, but it is not a specific ownership-type designation beyond what CMS's own flag names say, so treat it as a lead to research further, not a final classification.
- **One row per published transaction, not a full ownership history.** Each row reflects a single CMS CHOW filing between one buyer and one seller. A hospital with multiple ownership changes over time will appear in multiple rows.
- **Coverage follows the CMS CHOW dataset.** This Actor reports only ownership changes that hospitals disclosed through CMS's provider enrollment process. It does not independently verify deals, deal value, or closing status, and it does not cover facilities or transactions outside CMS's enrollment records.
- **No contact information.** This Actor returns organization-level facts published by CMS — enrollment IDs, NPI, CCN, legal/DBA names, and owner organization names. It does not include phone numbers, email addresses, or named individual contacts.
- `lookbackDays`, `futureDays`, and `maxItems` can intentionally limit how many transactions a run returns.
- This is an independent tool built on public CMS data and is not affiliated with or endorsed by CMS. You are responsible for using the data in accordance with applicable terms and laws.

### FAQ

#### What is CHOW data?

CHOW stands for Change of Ownership — a CMS provider-enrollment filing hospitals and other Medicare-enrolled facilities submit when they change owners. CMS publishes these filings, along with a companion owner-information dataset, as public data.

#### Can I find hospitals that recently changed ownership?

Yes. Set `lookbackDays` to your preferred window (default 365 days) and the Actor returns every matching CHOW transaction CMS has published, newest first.

#### Does this identify institutional or corporate hospital ownership?

To the extent CMS has published it. `buyerOwnerSignals`/`sellerOwnerSignals` surface CMS's own owner-type flags for organizational owners connected to the buyer and seller — including investment firm, holding company, and financial institution — where CMS has recorded them. These are CMS's own classifications, not a comprehensive ownership-type taxonomy, so treat a flag as a lead worth researching further rather than a final answer on who ultimately owns a hospital.

#### Can I filter by state?

Yes. `states` matches a transaction when either the buyer's or the seller's enrollment state is in your list.

#### How do I control the cost?

Set `maxItems`. It is a hard cap on the number of opportunities delivered in a run and therefore on billable results.

### Related Actors

Other data tools from the same developer, built to the same standard: official or public sources, hard cost caps, and honest documentation of limits.

- **[Hospital Price Transparency Enforcement Leads](https://apify.com/lukehunter/hospital-price-transparency-enforcement-leads)**: hospitals with recent CMS price transparency warning notices, CAP requests and CMP notices.
- **[New Healthcare Organization NPI Radar](https://apify.com/lukehunter/new-healthcare-organization-npi-radar)**: newly registered healthcare organizations from CMS's weekly NPI file, by provider type.
- **[Federal Register Rule Effective-Date Radar](https://apify.com/lukehunter/federal-rule-effective-date-radar)**: final federal rules about to take effect, with citations, dockets and urgency.
- **[Chicago Contract Recompete & Extension Radar](https://apify.com/lukehunter/chicago-contract-expiration-radar)**: expiring City of Chicago contracts with extension history, for recompete prospecting.
- **[Bank Branch Closings & Merger Radar (FDIC)](https://apify.com/lukehunter/bank-branch-merger-radar)**: new US bank branch closings, openings and mergers from the FDIC.
- **[Chicago New Business License Radar](https://apify.com/lukehunter/chicago-new-business-license-radar)**: newly licensed Chicago businesses as opening leads, grouped by category.
- **[NYC FDNY Contractor Leads & Hearing Radar](https://apify.com/lukehunter/fdny-violation-radar)**: fresh NYC fire-code summonses routed by remediation trade, with hearing dates.
- **[RCRA Enforcement Response Leads](https://apify.com/lukehunter/rcra-enforcement-radar)**: new EPA hazardous-waste (RCRA) enforcement actions and penalties, by state.
- **[Emerging Federal Contractor Radar](https://apify.com/lukehunter/emerging-federal-contractor-radar)**: companies that just won their first federal contracts, from USAspending.gov.
- **[County Multifamily Building Permits Surge Radar](https://apify.com/lukehunter/county-multifamily-permit-surge-radar)**: U.S. counties where 5+ unit apartment permits are surging year over year.
- **[Zillow ZIP Code Property Search Scraper](https://apify.com/lukehunter/zillow-zip-scraper)**: for-sale listings by ZIP code with prices, price cuts and days on Zillow.
- **[Walmart Category Scraper](https://apify.com/lukehunter/walmart-category-scraper)**: product names, prices, was-prices and ratings from Walmart category pages.

# Actor input Schema

## `states` (type: `array`):

Two-letter codes, up to 20. A transaction matches when either buyer or seller enrollment is in one of these states. Leave empty for nationwide results.

## `lookbackDays` (type: `integer`):

Include ownership changes effective this many days before today, 0-3650, default 365.

## `futureDays` (type: `integer`):

Include published ownership changes whose effective date is this many days in the future, 0-730, default 180.

## `transactionTypes` (type: `array`):

Optional values: CHOW, ACQUISITION/MERGER, CONSOLIDATION (up to 3). Leave empty for all types.

## `maxItems` (type: `integer`):

Hard cap on delivered rows and therefore on billable opportunity events, 1-2000, default 250.

## Actor input object example

```json
{
  "states": [],
  "lookbackDays": 365,
  "futureDays": 180,
  "transactionTypes": [],
  "maxItems": 250
}
```

# Actor output Schema

## `opportunities` (type: `string`):

No description

# 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 = {};

// Run the Actor and wait for it to finish
const run = await client.actor("lukehunter/hospital-chow-radar").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 = {}

# Run the Actor and wait for it to finish
run = client.actor("lukehunter/hospital-chow-radar").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 '{}' |
apify call lukehunter/hospital-chow-radar --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,lukehunter/hospital-chow-radar"
        }
    }
}
```

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/C6XwIudocbVWf6w9D/builds/rC0A5KvVdaGbu0D2J/openapi.json