> 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/cms-prior-auth-compliance-dataset.md).

# CMS Prior Authorization Compliance Intelligence Dataset

### About the Dataset

The **CMS Prior Authorization Compliance Intelligence Dataset** is a curated, provenance-traced regulatory reference layer over the CMS prior-authorization and interoperability rulemaking wave — **CMS-0057-F** (the Interoperability and Prior Authorization Final Rule, in effect), **CMS-0062-P** (the drug prior-authorization and standards Proposed Rule, pending finalization), and **CMS-0053-F** (the Claims Attachments Final Rule, adjacent). It answers, in one query, **which obligation applies to which entity type, by exactly what date and under which date semantics, with what API, public-reporting, denial-notice, and documentation duties** — every row traced to a Federal Register pinpoint citation and a verbatim rule-text excerpt, tagged FACT / INTERPRETATION / DERIVED with a confidence rating, and human-reviewed.

This is not a FHIR API, a workflow tool, or a consulting memo. It is the normalized, maintained reference matrix that today lives only in fragmented Federal Register PDFs — analysis-ready in Snowflake and Databricks, with a customer-visible change audit log so a maintained reference, not a one-time snapshot, is what you subscribe to.

{% hint style="info" %}
**Get Full Access** | [Snowflake Marketplace](https://app.snowflake.com/marketplace/listing/GZT1Z7QRT1XU) | [Free Trial](https://trial.dataplex-consulting.com)
{% endhint %}

{% hint style="warning" %}
**Informational reference compiled from public Federal Register, eCFR, and CMS sources. Not legal advice; consult counsel for compliance decisions.**
{% endhint %}

### Quick Access

**Reference tables**: RULE\_DOCUMENTS, RULE\_OBLIGATIONS, ENTITY\_TYPES, OBLIGATION\_APPLICABILITY, STANDARDS\_REGISTRY, OBLIGATION\_STANDARDS, REPORTING\_REQUIREMENTS, DENIAL\_NOTICE\_ELEMENTS, METRIC\_DEFINITIONS, PAYER\_DIRECTORY, PAYER\_METRIC\_SOURCES, PAYER\_METRICS\
**Derived tables**: COMPLIANCE\_GOLD, COMPLIANCE\_DEADLINES, RULE\_AUDIT\_LOG, CURATION\_STATUS\
**AI**: COMPLIANCE\_ANALYST semantic view — natural-language analytics via Cortex Analyst\
**Sources**: Federal Register (rule full text, public domain), eCFR (codified CFR text), CMS fact sheets, HL7 Da Vinci / CARIN / US Core implementation-guide metadata (facts only), payers' own public CMS-required PA-metrics postings\
**Coverage**: the CMS prior-authorization / interoperability rulemaking wave — CMS-0057-F, CMS-0062-P, and CMS-0053-F, with compliance anchors spanning 2024 through 2028; plus 475+ payer organizations, a registry of where the top payers by enrollment post their CMS-required PA metrics, and the posted metric values themselves — each human-reviewed before it ships\
**Update Frequency**: Monthly — a regulatory monitor sweeps the Federal Register and the CMS-0062-P finalization docket; new obligations land as human-reviewed curation releases\
**Geography**: United States (federal CMS rulemaking, applies nationwide)

{% hint style="info" %}
**Traceability, not legal certainty.** Every row cites a specific Federal Register pinpoint and carries a verbatim rule-text excerpt. Interpretations are labeled and confidence-rated; proposed-rule content is included and clearly flagged as **proposed and not binding**. Nothing here is a legal opinion — see the disclaimer above.
{% endhint %}

## The three-document corpus

The product's scope is a deliberate cap on three Federal Register documents, plus a small set of watched adjacent movers tracked as thin `RULE_DOCUMENTS` rows.

| Document                                                                                                            | Type                       | Role                                                                                                                                                                                                                                 |
| ------------------------------------------------------------------------------------------------------------------- | -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **CMS-0057-F** — Interoperability and Prior Authorization Final Rule (89 FR 8758)                                   | FINAL, in effect           | The backbone. Full-depth curation: operational obligations effective January 1, 2026; APIs January 1, 2027; first public metrics posting March 31, 2026.                                                                             |
| **CMS-0062-P** — Advancing Interoperability and Improving Prior Authorization for Drugs Proposed Rule (91 FR 19890) | PROPOSED (comments closed) | Obligation-summary depth. **Every row is `PROPOSED_NOT_BINDING`** with `date_certainty = PROPOSED`. Proposed drug-PA compliance October 1, 2027; the finalization docket is the live watch.                                          |
| **CMS-0053-F** — Claims Attachments Final Rule (91 FR 14350)                                                        | FINAL, adjacent            | Adjacency rows only — **every row `is_pa_scope = FALSE`**. CMS declined to finalize X12N 278 for prior-authorization attachments; the link to CMS-0062-P's proposed FHIR replacement is modeled explicitly. Compliance May 26, 2028. |

`document_status` (the regulatory lifecycle of the document) and each row's `row_status` (our curation lifecycle) are deliberately independent axes — a proposed rule's obligations are curated and versioned by us long before CMS finalizes them.

## Overview

The dataset provides analysis-ready access to the CMS prior-authorization compliance matrix across **twenty tables** — twelve curated reference tables, four derived analytics tables, and four standard metadata tables — **plus the `COMPLIANCE_ANALYST` semantic view**, so you can query the product in natural language with Snowflake Cortex Analyst.

### Curated reference tables

* **RULE\_DOCUMENTS** — One row per Federal Register document: citation, type, publication and effective dates, regulatory status, the `finalized_as_document_id` watch pointer, and PA relevance.
* **RULE\_OBLIGATIONS** — One obligation per document (API, operational, reporting, denial-notice, documentation, or measure), with the verbatim requirement text, `is_pa_scope`, `applies_regardless_of_api_build`, and `binding_status`.
* **ENTITY\_TYPES** — One row per program/entity type, **including explicit out-of-scope rows** (traditional Medicare FFS, Part D, QHPs on State-Based Exchanges, stand-alone dental, commercial/ERISA) with the citation basis and the entity's default date semantics.
* **OBLIGATION\_APPLICABILITY** — The central fact: one row per (obligation × entity type × version), with `applicability` (REQUIRED / EXEMPT / OPTIONAL / EXTENSION\_AVAILABLE / NOT\_APPLICABLE), the three-column compliance-date pattern, `date_certainty`, timeframe detail, and extension/exemption notes. **Exemptions are explicit rows, never missing ones.**
* **STANDARDS\_REGISTRY** — One row per standard or implementation-guide **version** (HL7 FHIR / Da Vinci / CARIN / US Core IGs, X12, NCPDP, HL7 CDA), with version status, expiry date, and a `license_class` firewall.
* **OBLIGATION\_STANDARDS** — The bridge mapping each obligation to the standards it requires, with `binding_strength` (REQUIRED / NAMED / ENCOURAGED / PROPOSED).
* **REPORTING\_REQUIREMENTS** — One row per reporting obligation and its required content element, with destination (payer website or CMS), cadence, due rule, first due date, and a link to `METRIC_DEFINITIONS`.
* **DENIAL\_NOTICE\_ELEMENTS** — The required elements of a prior-authorization denial notice and the channel each applies to.
* **METRIC\_DEFINITIONS** — One row per operational PA metric (approval/denial rates, decision times, appeals-overturn, API usage), with numerator/denominator definitions and a `benchmarkable` flag — the shared definitional spine for comparing PA metrics.
* **PAYER\_DIRECTORY** *(ungated)* — One row per payer parent organization — Medicare Advantage parent orgs, Medicaid managed-care parents, and state/territory Medicaid agencies — with the entity types it maps to, operating states, and approximate enrollment. The reference list of who the obligations apply to.
* **PAYER\_METRIC\_SOURCES** *(gated)* — One row per top-payer posting location: where each covered payer publishes its CMS-required annual (March 31) public PA metrics, with the posting URL, format, calendar year covered, and dual-verified provenance. The verified locations registry that anchors the values table below.
* **PAYER\_METRICS** *(gated)* — The posted metric values themselves: one row per (payer × metric × line of business × period) — approval and denial rates, decision times, appeals-overturn rates, request volumes — exactly as each payer posted them. Every value carries the verbatim excerpt that licenses it, a pinpoint into the posting, and the SHA-256 of the archived snapshot it was read from, and **every value is individually human-reviewed before it ships** — unreviewed values never reach this view.

### Derived analytics tables

* **COMPLIANCE\_GOLD** — The one-row-per-(entity type × obligation) answer table, `is_current` rows only: what applies to me, by which anchor date under which date semantics, with what standards and reporting duties, at what certainty. Excludes any quarantined row; **surfaces — never hides** — the certainty, binding-status, and confidence flags.
* **COMPLIANCE\_DEADLINES** — A pure projection of every dated obligation, recurring report, document milestone, and implementation-guide expiry into one calendar, carrying the date triple and `date_certainty` through by construction (a deadline can never contradict its source fact).
* **RULE\_AUDIT\_LOG** — A customer-visible, field-level record of every editorial change with its reason and triggering document — the proof that the reference is maintained.
* **CURATION\_STATUS** — The completeness & quarantine ledger: one row per currently quarantined row (held back from `COMPLIANCE_GOLD` pending verification) and per row verified in the last 180 days, each with its table, natural key, reason, and a per-table row denominator — so "where is my row?" is a query, not a support ticket. Always fully visible.

### Metadata Tables

Every Dataplex data product includes these standard metadata tables:

| Table             | Purpose                                                                                                                                                                      |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `FEEDS`           | Dataset catalog — tables, descriptions, and last-updated dates. `last_updated_at` is the greatest audit-log change time per table (curation-driven, never a fake timestamp). |
| `FEEDS_FILES`     | Curation-release history with an `is_latest` flag — one row per published curation release.                                                                                  |
| `CHANGELOG`       | Change log — curation releases, schema changes, corrections.                                                                                                                 |
| `DATA_DICTIONARY` | Column descriptions for all tables.                                                                                                                                          |

## Entity Relationship Diagram

<figure><img src="/files/R3eWmC5wKTXbYVameTZS" alt="CMS Prior Authorization Compliance Intelligence Entity Relationship Diagram"><figcaption><p>Provenance-traced regulatory model: RULE_DOCUMENTS is the document spine every curated row traces back to; RULE_OBLIGATIONS is the semantic hub, joined to entities through OBLIGATION_APPLICABILITY and to standards through OBLIGATION_STANDARDS; COMPLIANCE_GOLD and COMPLIANCE_DEADLINES are derived projections</p></figcaption></figure>

**RULE\_DOCUMENTS** is the provenance spine: every curated row carries a `source_doc_id` back to it, plus a Federal Register pinpoint and verbatim excerpt. **RULE\_OBLIGATIONS** is the semantic hub — obligations join to entity types through `OBLIGATION_APPLICABILITY` (the central fact), to standards through `OBLIGATION_STANDARDS`, and out to `REPORTING_REQUIREMENTS`, `DENIAL_NOTICE_ELEMENTS`, and `METRIC_DEFINITIONS`. `COMPLIANCE_GOLD` and `COMPLIANCE_DEADLINES` are derived from the applicability and reporting facts and never hold a value their source rows do not.

## How compliance dates work

The single most important thing to understand before querying: **there is no bare `compliance_date` column anywhere in this product.** CMS compliance dates drift by entity type, so applicability rows carry a **three-column date pattern** instead of a misleading single date.

| Column                           | Meaning                                                                                                                                                                                                                        |
| -------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `compliance_date_anchor` (DATE)  | The verbatim on-or-after anchor from the rule text (e.g. `2026-01-01`). It is **never a resolved per-payer due date** and is **never fabricated** — a row that genuinely lacks a dated anchor ships quarantined, not invented. |
| `compliance_date_type` (enum)    | How to read the anchor: `LITERAL_DATE`, `RATING_PERIOD_ON_OR_AFTER`, `PLAN_YEAR_ON_OR_AFTER`, `PERFORMANCE_PERIOD`, or `RELATIVE_TO_FINALIZATION`.                                                                             |
| `compliance_date_display` (text) | The human phrasing, e.g. *"Rating periods beginning on or after January 1, 2027."*                                                                                                                                             |

Why it matters: the same obligation is due on a **literal** January 1 for Medicare Advantage and Medicaid/CHIP fee-for-service, but keys off the **rating period beginning on or after** that date for managed care, and off the **plan year beginning on or after** it for QHP issuers on the FFEs. Resolving a managed-care plan's actual due date requires its rating-period start, which is not in the rule — so this product gives you the anchor and the semantics, and never a fabricated per-payer date. A separate `first_deliverable_due` (e.g. `2026-03-31` for the first public metrics posting) carries an actual literal deadline where the rule states one.

## Certainty and confidence model

The product sells traceability, and its schema makes the strength of every assertion explicit rather than flattening everything to "the data says so."

* **`assertion_type`** — `FACT` (stated in the rule text), `INTERPRETATION` (our reading, with notes), or `DERIVED` (computed from other rows).
* **`interpretation_confidence`** — `HIGH` / `MEDIUM` / `LOW`. HIGH is reserved for adversarially confirmed readings.
* **`date_certainty`** — `FINAL` or `PROPOSED`, orthogonal to interpretation confidence. Every CMS-0062-P row is `PROPOSED`; a `FINAL` date always traces to a `document_status = FINAL` source.
* **`binding_status`** — `FINAL_BINDING` or `PROPOSED_NOT_BINDING`. Proposed-rule obligations are included as forward radar and clearly labeled.
* **`needs_verification`** — when `TRUE`, the row is **quarantined**: excluded from `COMPLIANCE_GOLD` and every customer-visible derived view. The quarantine machinery is a standing pattern for any ambiguous fact.
* **`reviewed_by` / `review_date`** — every production row names a human reviewer; no interpretation-only row ships unreviewed.

Every row also carries append-only lifecycle columns (`row_version`, `row_status`, `is_current`, `superseded_by_row_id`) so a rule change becomes a new version sourced to the superseding document, and the old row is retained and marked superseded — the change is visible in `RULE_AUDIT_LOG`, not silently overwritten.

## How time works in this product

If you already use our file-versioned data products, set that mental model aside here. In those products, each source refresh lands as a new file row in `FEEDS_FILES` and you track change by comparing whole-table snapshots. This is a curated regulatory reference, so change is tracked at the **row and field level** instead: the time machine is append-only row versioning plus a field-level audit log, not file versioning. A nightly rebuild that finds nothing new to curate produces no new version and moves no freshness date.

Three layers answer three different questions:

| Layer                   | Where it lives                                                                                                                                   | Answers                                                                                                                                                                                                                                                                                                                                                                                                                                                            |
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Catalog & freshness** | `FEEDS`, `FEEDS_FILES`                                                                                                                           | *What tables exist, how fresh are they, and which release am I on?* `FEEDS.last_updated_at` is the newest audit-log change time per table, so it advances only when a curation release actually changed that table — never on a no-op rebuild. `FEEDS_FILES` carries one row per published curation **release** (`R1.0.0`, `R1.1.0`, `R1.1.1`, …), with `is_latest = TRUE` on the newest; every data row's `feeds_files_id` points at the release that shipped it. |
| **Change history**      | `RULE_AUDIT_LOG`                                                                                                                                 | *What changed, and why?* One row per field-level editorial change, each with a customer-facing `change_reason` and a `change_type` of `CREATED`, `VERIFIED`, `SUPERSEDED`, `CORRECTION`, or `STATUS_CHANGE`.                                                                                                                                                                                                                                                       |
| **Point-in-time state** | SCD2 columns on every curated row: `row_version`, `is_current`, `row_status`, `curation_valid_from`, `curation_valid_to`, `superseded_by_row_id` | *What did the reference assert on date X?* Rows are never overwritten — when a fact changes, the old row is retained with a `curation_valid_to` set and a new `is_current` version is written. Filtering on the `curation_valid_from` / `curation_valid_to` interval reconstructs the reference as it stood on any past date.                                                                                                                                      |

In short: `FEEDS` / `FEEDS_FILES` tell you *what tables exist, how fresh they are, and which release you are on*; `RULE_AUDIT_LOG` tells you *what changed and why*; the SCD2 columns tell you *what the reference asserted on a given date*. Most day-to-day queries filter `is_current = TRUE` (or use the pre-filtered `COMPLIANCE_GOLD`) and never touch history — reach for the audit log and the SCD2 interval only when you need to see change over time.

### Which release am I on, and what shipped in it?

{% tabs %}
{% tab title="Snowflake" %}

```sql
SELECT release_id, release_date, title, is_latest
FROM DWV.FEEDS_FILES
ORDER BY release_date DESC, release_id DESC;
```

{% endtab %}

{% tab title="Databricks" %}

```sql
SELECT release_id, release_date, title, is_latest
FROM cms_prior_auth_compliance_dwv.feeds_files
ORDER BY release_date DESC, release_id DESC;
```

{% endtab %}
{% endtabs %}

### What changed in the reference since my last check?

{% tabs %}
{% tab title="Snowflake" %}

```sql
SELECT changed_at, table_name, row_pk, change_type, change_reason
FROM DWV.RULE_AUDIT_LOG
WHERE changed_at >= '2026-06-01'
ORDER BY changed_at DESC;
```

{% endtab %}

{% tab title="Databricks" %}

```sql
SELECT changed_at, table_name, row_pk, change_type, change_reason
FROM cms_prior_auth_compliance_dwv.rule_audit_log
WHERE changed_at >= '2026-06-01'
ORDER BY changed_at DESC;
```

{% endtab %}
{% endtabs %}

### What did the reference assert on a past date?

Filter one obligation's applicability rows to the versions whose curation-validity interval contains your as-of date. A date earlier than a row's `curation_valid_from` returns nothing for that row — the reference had not asserted it yet.

{% tabs %}
{% tab title="Snowflake" %}

```sql
SELECT entity_type_id, applicability, compliance_date_display, row_version
FROM DWV.OBLIGATION_APPLICABILITY
WHERE obligation_id = 'CMS-0057-F:PA-DECISION-TIMEFRAMES'
  AND curation_valid_from <= DATE '2027-06-01'
  AND (curation_valid_to IS NULL OR curation_valid_to > DATE '2027-06-01')
ORDER BY entity_type_id;
```

{% endtab %}

{% tab title="Databricks" %}

```sql
SELECT entity_type_id, applicability, compliance_date_display, row_version
FROM cms_prior_auth_compliance_dwv.obligation_applicability
WHERE obligation_id = 'CMS-0057-F:PA-DECISION-TIMEFRAMES'
  AND curation_valid_from <= DATE '2027-06-01'
  AND (curation_valid_to IS NULL OR curation_valid_to > DATE '2027-06-01')
ORDER BY entity_type_id;
```

{% endtab %}
{% endtabs %}

The full set — release history, point-in-time reconstruction, one obligation's complete version history, and what is currently under verification — is in the [**Compliance Questions Cookbook**](/data-catalog/cms-prior-auth-compliance-dataset/compliance-questions-cookbook.md) under *Tracking changes over time*.

## Payer directory & metrics posting registry

Three tables connect the obligations to the actual payers who carry them — who they are, where they post their required metrics, and what they posted.

**PAYER\_DIRECTORY** *(ungated)* is a reference list of 475+ payer parent organizations — Medicare Advantage parent orgs, Medicaid managed-care parents, and state/territory Medicaid agencies — each mapped to the entity types it belongs to (via `entity_type_ids`), with its operating states, approximate enrollment, and, for Medicare Advantage, its CMS contract IDs. It answers "who are the organizations these obligations apply to, and which entity-type rules reach each of them."

**PAYER\_METRIC\_SOURCES** *(gated)* is the URL registry of where the top payers by enrollment publish their CMS-required annual public prior-authorization metrics — the postings due every March 31. Each row carries the posting URL, its format (HTML, PDF, or dashboard), the calendar year covered, and dual-verified retrieval provenance. Where a posting could not be located, that is recorded explicitly (`found = FALSE`) rather than left blank. The registry covers the top payer parents by enrollment.

**PAYER\_METRICS** *(gated)* is the values table: the prior-authorization metrics each covered payer actually posted — approval and denial rates for standard and expedited requests, average and median decision times, appeals-overturn rates, and request volumes — one row per (payer × metric × line of business × period), keyed to `METRIC_DEFINITIONS` so the same metric is comparable across payers. Coverage grows as postings are reviewed.

{% hint style="info" %}
**Every value is licensed by its source and reviewed by a human before it ships.** Each `PAYER_METRICS` row carries the verbatim excerpt from the payer's posting that contains the value, a pinpoint (page or section) into that posting, and the SHA-256 of the archived snapshot it was read from. Values are extracted by two independent passes that must agree, and then individually human-reviewed; a value that hasn't been reviewed never reaches this view. The `RULE_AUDIT_LOG` records every promotion with a `VERIFIED` entry.
{% endhint %}

## Trial scope

The free trial gives 14-day access to the full schema, the full metadata catalog, and a **demonstrative cohort** of prior-authorization obligations chosen to span every date-semantics regime — literal (Medicare Advantage / FFS), rating-period (managed care), and plan-year (QHP on the FFEs) — plus an exempt case (QHP on the FFEs and the decision-timeframe exemption), a proposed-rule case (CMS-0062-P), a claims-attachments adjacency case (CMS-0053-F), and the March 31 public-metrics posting obligation. Alongside the obligation cohort, a small cohort of payers in `PAYER_METRIC_SOURCES` and `PAYER_METRICS` is included so the posting-registry and posted-values shapes are visible on the trial. The reference tables (entity types, metric definitions, rule documents, standards registry, and the full `PAYER_DIRECTORY`) and the change audit log are always fully available. Full access unlocks the complete obligation × entity applicability matrix, the gold view, deadlines, standards mappings, reporting requirements, denial-notice elements, the full payer metrics-posting registry, and the full set of reviewed posted metric values.

## How to Query the Data

### Platform Schema Reference

This dataset is available on both Snowflake and Databricks. Queries use schema-only references — the database is already set by the share or catalog context:

| Platform       | Schema                          | Example                                         |
| -------------- | ------------------------------- | ----------------------------------------------- |
| **Snowflake**  | `DWV`                           | `DWV.COMPLIANCE_GOLD`                           |
| **Databricks** | `cms_prior_auth_compliance_dwv` | `cms_prior_auth_compliance_dwv.compliance_gold` |

### Ask it questions — Cortex Analyst and the semantic view

The share includes the **`COMPLIANCE_ANALYST` semantic view** — a semantic model over the compliance matrix and the posted payer metrics, with relationships, synonyms, and business definitions built in. Point **Cortex Analyst** at it (in Snowsight: AI & ML → Cortex Analyst → select `DWV.COMPLIANCE_ANALYST`) and ask questions in plain English:

* *"Which obligations apply to Medicare Advantage organizations, and by when?"*
* *"Compare payers' standard prior authorization approval rates."*
* *"How many proposed obligations are not yet binding?"*

<figure><img src="/files/NU2yztLDi8SnlErxiqaG" alt="Cortex Analyst answering a natural-language question against the COMPLIANCE_ANALYST semantic view"><figcaption><p>Cortex Analyst against COMPLIANCE_ANALYST: ask which obligations apply to Medicare Advantage organizations and by when — the obligation set with compliance dates and certainty comes back, with the generated query fully inspectable</p></figcaption></figure>

New to these features? See Snowflake's documentation on [Cortex Analyst](https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst) and [semantic views](https://docs.snowflake.com/en/user-guide/views-semantic/overview).

The same semantic model is queryable directly in SQL with the `SEMANTIC_VIEW()` construct — see the [Compliance Questions Cookbook](/data-catalog/cms-prior-auth-compliance-dataset/compliance-questions-cookbook.md#ask-the-whole-product-a-question-with-the-semantic-view) for runnable examples.

### Everything that applies to one entity type, in one query

The gold table answers the core buyer question — what applies to me, by when, under which semantics, and how certain — in a single row per obligation.

{% tabs %}
{% tab title="Snowflake" %}

```sql
SELECT entity_type_id, obligation_id, obligation_category,
       applicability, compliance_date_anchor, compliance_date_display,
       date_certainty, binding_status, interpretation_confidence
FROM DWV.COMPLIANCE_GOLD
WHERE entity_type_id = 'MA_ORG'
ORDER BY compliance_date_anchor;
```

{% endtab %}

{% tab title="Databricks" %}

```sql
SELECT entity_type_id, obligation_id, obligation_category,
       applicability, compliance_date_anchor, compliance_date_display,
       date_certainty, binding_status, interpretation_confidence
FROM cms_prior_auth_compliance_dwv.compliance_gold
WHERE entity_type_id = 'MA_ORG'
ORDER BY compliance_date_anchor;
```

{% endtab %}
{% endtabs %}

### Discover Available Data

Start with the `FEEDS` table to see what's available, and `FEEDS_FILES` for release freshness.

{% tabs %}
{% tab title="Snowflake" %}

```sql
SELECT table_name, description, last_updated_at, total_rows_extracted, total_batches
FROM DWV.FEEDS
ORDER BY table_name;
```

{% endtab %}

{% tab title="Databricks" %}

```sql
SELECT table_name, description, last_updated_at, total_rows_extracted, total_batches
FROM cms_prior_auth_compliance_dwv.feeds
ORDER BY table_name;
```

{% endtab %}
{% endtabs %}

The worked buyer questions — each answered by a single query, including the payer directory and metrics-posting registry — are in the [**Compliance Questions Cookbook**](/data-catalog/cms-prior-auth-compliance-dataset/compliance-questions-cookbook.md).

## Reference, Deadlines & Self-Assessment

* [**Schema Reference**](/data-catalog/cms-prior-auth-compliance-dataset/schema-reference.md) — every table's grain, purpose, and column-level detail, including the universal provenance, interpretation, and lifecycle column blocks carried by every curated row.
* [**Compliance Questions Cookbook**](/data-catalog/cms-prior-auth-compliance-dataset/compliance-questions-cookbook.md) — the top buyer questions, each resolved to one documented SQL query against `DWV`.
* [**Deadline Calendar**](/data-catalog/cms-prior-auth-compliance-dataset/deadline-calendar.md) — the verified compliance anchors by entity type and obligation, with proposed dates clearly flagged, generated from the curated data.
* [**Readiness Self-Assessment Framework**](/data-catalog/cms-prior-auth-compliance-dataset/readiness-framework.md) — a practical framework for scoring API, operational, and reporting readiness against these obligations (editorial guidance, not data).

## Who Uses This Data

### Common Use Cases

* **Compliance calendars by entity type** — Build a prior-authorization compliance calendar for Medicare Advantage, Medicaid or CHIP fee-for-service or managed care, or a QHP issuer on the FFEs, with each obligation's anchor date and the date semantics that apply to that entity.
* **Public reporting readiness** — Enumerate the annual public PA metrics payers must post on their websites, the required content elements, and the recurring March 31 due rule, to plan and evidence the annual posting.
* **Denial-notice template validation** — Check denial-notice templates against the required content elements and the channels they apply to.
* **API and standards planning** — Map each API obligation to the FHIR / Da Vinci implementation guides and other named standards it requires, with binding strength and version — including proposed-rule standards on the horizon and implementation-guide expiries.
* **Forward regulatory radar** — Track proposed drug prior-authorization rulemaking (CMS-0062-P), the claims-attachments compliance date (CMS-0053-F), and the MIPS electronic prior-authorization measure, each clearly flagged as proposed or final, so roadmaps anticipate the next obligation.
* **Scope determination** — Confirm whether a program or plan type is in scope, with the verbatim citation basis for inclusion or exclusion.

### Related Datasets

This dataset is part of **Compliance Intelligence by Dataplex**:

* [**Compliance Intelligence by Dataplex**](/data-catalog/compliance-intelligence-by-dataplex.md) — the family landing page grouping this product with CMS Nursing Home Compliance Intelligence.
* [**Nursing Home Compliance Intelligence Dataset**](/data-catalog/cms-nh-compliance-dataset.md) — the sibling product: ownership, staffing, and enforcement compliance intelligence over CMS nursing home data, on the same provenance-first, published-methodology model.
* [**CMS Data Feeds Dataset**](/data-catalog/cms-data-feeds-dataset.md) — the broader CMS data feeds for cross-program analysis.

### Frequently Asked Questions

**Who is this dataset for?** The analyst or data engineer who supports a payer's compliance, regulatory-affairs, or product team — anyone who needs to answer "which CMS prior-authorization obligation applies to us, by exactly what date and under which date semantics" without reading Federal Register PDFs. It is equally useful to consultancies and law firms serving multiple payer clients.

**Is this legal advice?** No. It is an informational reference compiled from public Federal Register, eCFR, and CMS sources. It is built to be traceable — every row cites a rule pinpoint and a verbatim excerpt — but it is not a legal opinion. Consult counsel for compliance decisions.

**Why is there no single `compliance_date` column?** Because CMS compliance dates drift by entity type. A single date column would be wrong for most entities. The product carries a verbatim `compliance_date_anchor`, a `compliance_date_type` that tells you whether it is a literal date, a rating-period start, a plan-year start, or a performance period, and a `compliance_date_display` in plain English. See [How compliance dates work](#how-compliance-dates-work).

**What does a `PROPOSED` row mean?** It comes from a proposed rule (CMS-0062-P) that CMS has not finalized. Proposed obligations are included as forward radar so you can plan ahead, but they carry `date_certainty = PROPOSED` and `binding_status = PROPOSED_NOT_BINDING` and are clearly labeled everywhere. They are not current legal requirements.

**How is a "maintained" reference different from downloading the rules myself?** The rules live across long Federal Register documents with entity-specific dates, exemptions, and cross-references. This product normalizes them into a queryable matrix, traces every assertion to a pinpoint and verbatim quote, labels interpretations and their confidence, and — critically — maintains it: a regulatory monitor watches for new CMS actions, and every editorial change is recorded in `RULE_AUDIT_LOG` with its reason and triggering document. When CMS-0062-P is finalized, the change is absorbed as an audited supersession you can watch happen.

**Is payer-level prior-authorization metrics benchmarking included?** Yes. `PAYER_DIRECTORY` lists the payer organizations, `PAYER_METRIC_SOURCES` is the verified registry of *where* each covered payer posts its CMS-required March 31 PA metrics, and `PAYER_METRICS` carries the posted values themselves — approval/denial rates, decision times, appeals-overturn, and volumes — keyed to the shared `METRIC_DEFINITIONS` spine so the same metric is comparable across payers. Every value is pinned to a verbatim excerpt and an archived snapshot of the payer's own posting, and individually human-reviewed before it ships. Coverage grows as postings are reviewed.

{% hint style="success" %}
**Ready to access CMS Prior Authorization Compliance Intelligence?**

Questions? [Contact our team](mailto:support@dataplex-consulting.com) for a walkthrough.
{% endhint %}

| Platform       | Action                                                                                              |
| -------------- | --------------------------------------------------------------------------------------------------- |
| **Snowflake**  | [View listing on Snowflake Marketplace](https://app.snowflake.com/marketplace/listing/GZT1Z7QRT1XU) |
| **Databricks** | [Free Trial](https://trial.dataplex-consulting.com)                                                 |

***

*Informational reference compiled from public Federal Register, eCFR, and CMS sources. Not legal advice; consult counsel for compliance decisions.*


---

# 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/cms-prior-auth-compliance-dataset.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.