> 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/data-dictionary.md).

# What FacilityGuard Checks

FacilityGuard monitors what CMS publicly discloses about who owns each skilled-nursing facility, and how that disclosure changes over time. You don't manage any of this data; FacilityGuard keeps it current for you and updates automatically as CMS refreshes its sources. This page explains, in plain terms, what it watches and what each part tells you.

## Current ownership, per facility

For every facility, FacilityGuard resolves the ownership CMS currently discloses: the direct and indirect owners, their roles, and their disclosed ownership percentages, with undisclosed percentages shown as "% not disclosed", never as blank or zero. Each owner is identified by its stable CMS-assigned ID, so the same company reads as the same entity even when its name is spelled differently across filings.

**What it tells you:** the disclosed structure behind a facility today, and, through the coverage code (fully disclosed, partial, dead-end, or no enrollment data), exactly how far that disclosure goes. **Refreshes:** monthly, with each new CMS ownership publication.

## Ownership history

FacilityGuard keeps the month-by-month record of disclosed ownership, which is what makes the change watchlist possible. It's the paper trail behind every alert: the state of each facility's ownership at each publication, so you can see not just what changed but when it showed up.

**What it tells you:** how a facility's disclosed ownership has moved over time. **Refreshes:** monthly.

## Filed ownership-change events

By comparing consecutive monthly publications, FacilityGuard produces a feed of typed change events (owner appears, owner gone, ownership-percentage change, enrollment appears or gone), graded into a validated strong signal, a watchlist tier, and lower-stakes disclosure churn. Each event names the two publications it was found between and carries a confirmation chip that flips when the official CMS change-of-ownership file later publishes the matching event.

**What it tells you:** the changes worth reviewing, led by the low-noise signal, with a receipt and an official-confirmation track record for each. **Refreshes:** monthly, one detection cycle per new publication.

## Owner type flags

Each owner carries the type flags CMS self-reports: private equity, REIT, holding company, and related categories. These are surfaced on the ownership chain and rolled up on Portfolio health so you can see, for example, which of your facilities have a PE-flagged owner in the disclosed chain.

**What it tells you:** disclosed private-equity, REIT, and holding-company involvement. These flags are self-reported, so absence of a flag is not absence of involvement. **Refreshes:** monthly.

## Coverage and dead ends

FacilityGuard classifies every facility by how complete its disclosure is, and flags the point where the filings stop. About 30% of chains dead-end into an owner with zero federal upstream disclosure; FacilityGuard marks that as a finding rather than drawing a confident-looking complete chart.

**What it tells you:** which of your facilities you can rely on for a full picture, and which come with an "as disclosed in federal filings" limit, shown against the national base rate so you know whether your book is unusually opaque or just normal. **Refreshes:** monthly.

***

* Everything here is **read-only** and stays current automatically as we refresh the underlying CMS sources; no action needed on your side. Every page shows the exact source dates behind what it displays.
* Owners are always identified by their CMS-assigned ID; names are display data. See [Methodology](/data-catalog/facilityguard-app/methodology.md) for why FacilityGuard never merges owners by name.
* FacilityGuard reads nothing in your account except the single facility list you connect (read-only).

## Query the data directly (optional)

You never *need* SQL; every screen works without it. But the CMS ownership data FacilityGuard ships with, and your own portfolio and reviews, are read‑only tables inside the installed app you can query directly for ad‑hoc analysis or to join into your own reporting. Anyone you've granted the `app_user` or `app_admin` role can read them. (`<app_name>` below is whatever your admin named the app at install.)

* **`<app_name>.shared_dw.*`** holds the CMS reference data: `facility_ownership_current`, `facility_ownership_history`, `ownership_change_events`, `owner_entity_dim`, and `name_bridge`. These span **all** CMS‑enrolled facilities; the app's screens scope them to your bound portfolio.
* **`<app_name>.fg_state.*`** holds your own state: `portfolio` (the facilities you bound), `run_log` (every bind and refresh), and `event_reviews` (your review ledger).

**Confirmed change‑of‑ownership events on your portfolio, most recent first:**

```sql
SELECT e.ccn, e.facility_name, e.facility_state, e.event_type,
       e.chow_effective_date, e.detected_vintage_month
FROM <app_name>.shared_dw.ownership_change_events e
JOIN <app_name>.fg_state.portfolio p ON p.ccn = e.ccn
WHERE e.alert_tier = 'chow_signal' AND e.chow_confirmed = TRUE
ORDER BY e.detected_vintage_month DESC;
```

`chow_signal` events are enrollment‑level (the facility's Medicare enrollment appearing or disappearing, the strongest disclosed change‑of‑ownership marker), so they carry no single `owner_name`. To see who owns the facility now, look it up in `facility_ownership_current` (below); owner‑level appear/leave events are graded `watchlist`.

**Your bound facilities that have a private‑equity owner in the disclosed chain:**

```sql
SELECT ccn, facility_name, facility_state
FROM <app_name>.fg_state.portfolio
WHERE has_pe_owner = TRUE
ORDER BY facility_state, facility_name;
```

> `alert_tier` grades each event `chow_signal` (a likely change of ownership), `watchlist` (notable), or `disclosure` (disclosure‑only movement), the same grading the change watchlist shows. Drop the `portfolio` join to query across **all** CMS‑enrolled facilities instead of just your book.

***

**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) · [Methodology](/data-catalog/facilityguard-app/methodology.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/data-dictionary.md?ask=<question>&goal=<endgoal>
```

`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.