> For the complete documentation index, see [llms.txt](https://docs.dataplex-consulting.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dataplex-consulting.com/data-catalog/facilityguard-app/methodology.md).
# Methodology
This page documents how FacilityGuard detects ownership changes, what we measured, against what denominators, and, just as important, what the federal filings it reads cannot see. It's written for a diligence reader who needs to cite the product with confidence.
## How detection works
FacilityGuard identifies each owner by the stable ID CMS assigns it, never by name. Each month CMS publishes a new ownership snapshot; FacilityGuard compares consecutive snapshots, matches enrollments to facility CCNs, and produces typed events: owner appears, owner gone, ownership-percentage change, enrollment appears, enrollment gone.
Two rules do most of the work:
* **Changes are tracked by ID, not by name.** CMS owner-name strings change from month to month at roughly 41% (almost all of it formatting and re-keying, not real change), while ID-based changes run at about 1% per month. Matching on names would bury the real signal under roughly 40× the noise, so names are never used to detect change. A separate, deliberately conservative step links Care Compare's name-only records back to the ID, and it is never used to count facilities or detect change.
* **Detection uses the publications that actually exist.** A few source months are missing upstream, so each comparison runs between consecutive *available* publications, and every event names both publications it was found between. A missing month can never manufacture a phantom event.
Every event is **found in a comparison of two published snapshots**: the detection month is the publication month of the newer snapshot, not the date the underlying transaction happened.
From snapshot to review ledger: one dated file per month, an ID-based comparison (names churn \~41% per month from formatting alone; IDs churn \~1%), a guard so a missing month can never manufacture an event, and grading before anything reaches your watchlist.
## Alert grades
The 2025–26 CMS disclosure expansion added a lot of link churn to the ownership files, so events are graded to keep the validated signal quiet:
| Grade | What it holds |
| -------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------- |
| **Strong signal** | The validated change-of-ownership signal: enrollment-level buyer-appears / seller-gone patterns. This is what leads the feed. |
| **Watchlist** | Ownership-interest moves worth watching: owner-level appears/gone and percentage changes. |
| **Disclosure churn** | Bookkeeping churn from CMS's expanded-disclosure rollout: typed and kept, never dropped, but separated from the signal so it doesn't drown it. |
The strong signal runs at roughly **1% of facilities per month** (median, trailing twelve months), quiet enough that you can review every alert.
## What we measured
These are the headline claims, each with its denominator. The live data date is shown in the app on every page.
| Metric | Measured | Denominator / basis |
| ---------------------------- | ------------ | ------------------------------------------------------------------------------------------------------------- |
| Change-of-ownership backtest | 100.0% | 1,677 of 1,677 events in the official CMS change-of-ownership file were found in earlier snapshot comparisons |
| Lead over the official file | \~4 months | average lead of the earlier detection over the official file's publication, in the backtest above |
| Strong-signal rate | \~1% / month | median trailing-twelve-month share of facilities with a strong-signal event |
| Dead-end chains | 30.4% | 4,383 of 14,425 facilities have at least one owner with zero federal upstream disclosure |
| Name-link recall | 98.51% | share of distinct Care Compare owner names linked to at least one owner ID |
| Unresolved name collisions | 2.18% | of matched names; labeled, never silently merged |
**How the backtest is built:** the testable window is the range of snapshots in the current build (roughly the trailing three years). The denominator is every event in the official CMS change-of-ownership file whose effective date falls inside that window, with far enough margin that both the seller and the re-enrolled buyer had a chance to appear. "Detected" means the buyer-appears *and* seller-gone pattern showed up in an earlier snapshot comparison. Events outside the testable window are excluded by construction, not silently dropped; the window bounds are stated on the build.
**Reading the \~4-month claim:** "about 4 months ahead of the official file" is a backtest result: it's measured by replaying history and comparing when each of the 1,677 official events first appeared in the data against when the official file published it. It describes the publication lag of the official feed, not a prediction about any individual future transaction.
## How current the data is
Every detection cycle records the exact source dates it ran against, every event names the two publication dates it was found between, and every page shows the source dates behind what it displays. CMS ownership and enrollment snapshots arrive monthly; the official change-of-ownership confirmation feed is cumulative and lags filings by roughly five months. The data is current as of its displayed date.
## What this is not
* **Not complete ownership monitoring.** FacilityGuard is a filed-change watchlist over CMS-disclosed ownership. Roughly a third of private-equity activity is visible in federal filings (the estimate comes from published peer-reviewed research in Health Affairs, 2024, and from KFF analyses of CMS data, not from us); transactions structured to avoid federal disclosure are invisible to this product, and we say so.
* **Dead ends are flagged, not resolved.** About 30% of chains dead-end into an owner with zero federal upstream disclosure. FacilityGuard marks the dead end as a finding; it does not guess what sits above it.
* **PE / REIT / holding-company flags are CMS self-reported.** The current build carries on the order of a hundred self-flagged private-equity entities, a few hundred REITs, and roughly three thousand holding companies among the owners it tracks, so absence of a flag is not absence of involvement.
* **Detection dates are publication dates.** An event found in the May 2026 comparison tells you when CMS's files first showed it, not when the transaction closed.
* **Names are display data, not identity.** A small share of owner links carry no CMS-disclosed name (shown as "(name not disclosed by CMS)"), and name strings vary wildly; identity is always the CMS-assigned ID.
* **Coverage is skilled nursing facilities**: CMS's SNF disclosure files, roughly 14,700 facilities nationally.
{% hint style="warning" %}
FacilityGuard is a filed-change watchlist over CMS-disclosed ownership, not complete ownership monitoring. Roughly a third of private-equity activity is visible in federal filings; chains that dead-end in the filings are flagged as dead ends. Changes are detected in CMS's monthly publications, so a detection date is a publication date, not the date a transaction closed.
{% endhint %}
***
## Citing FacilityGuard in a memo or report
FacilityGuard is built by **Dataplex Consulting**, the provider behind the healthcare datasets in this Data Catalog.
If you reference a FacilityGuard finding in a diligence memo, board deck, or compliance report, include three things in the citation:
1. **The source**: Dataplex Consulting's FacilityGuard.
2. **The data date**: every page in the app displays the date of the CMS publications it reflects. Quoting it tells your reader exactly which month's filings your finding came from.
3. **A link to this page**: it documents how detection works and how each headline number was measured, and its address will not change.
The statistics on this page are written to be quotable: each one states the measurement alongside what it was measured against (for example, 1,677 of 1,677 official change-of-ownership events found in the backtest). For any individual alert you cite, the app shows the supporting evidence: the two CMS publications the change was found between, the CMS-assigned IDs of the owners involved, and whether the official CMS change-of-ownership file has since confirmed it.
**FacilityGuard docs:** [Overview](/data-catalog/facilityguard-app.md) · [Quickstart](/data-catalog/facilityguard-app/quickstart.md) · [Using the App](/data-catalog/facilityguard-app/using-the-app.md) · [What FacilityGuard Checks](/data-catalog/facilityguard-app/data-dictionary.md) · [Security & Plans](/data-catalog/facilityguard-app/security-and-plans.md)
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://docs.dataplex-consulting.com/data-catalog/facilityguard-app/methodology.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.