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.
Get Full Access | Snowflake Marketplace | Free Trial
Informational reference compiled from public Federal Register, eCFR, and CMS sources. Not legal advice; consult counsel for compliance decisions.
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)
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.
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.
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_idwatch 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, andbinding_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_classfirewall.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
benchmarkableflag — 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_currentrows 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_certaintythrough 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_GOLDpending 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:
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
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.
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), orDERIVED(computed from other rows).interpretation_confidence—HIGH/MEDIUM/LOW. HIGH is reserved for adversarially confirmed readings.date_certainty—FINALorPROPOSED, orthogonal to interpretation confidence. Every CMS-0062-P row isPROPOSED; aFINALdate always traces to adocument_status = FINALsource.binding_status—FINAL_BINDINGorPROPOSED_NOT_BINDING. Proposed-rule obligations are included as forward radar and clearly labeled.needs_verification— whenTRUE, the row is quarantined: excluded fromCOMPLIANCE_GOLDand 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:
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?
What changed in the reference since my last check?
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.
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 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.
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.
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:
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?"
New to these features? See Snowflake's documentation on Cortex Analyst and semantic views.
The same semantic model is queryable directly in SQL with the SEMANTIC_VIEW() construct — see the Compliance Questions Cookbook 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.
Discover Available Data
Start with the FEEDS table to see what's available, and FEEDS_FILES for release freshness.
The worked buyer questions — each answered by a single query, including the payer directory and metrics-posting registry — are in the Compliance Questions Cookbook.
Reference, Deadlines & Self-Assessment
Schema Reference — 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 — the top buyer questions, each resolved to one documented SQL query against
DWV.Deadline Calendar — the verified compliance anchors by entity type and obligation, with proposed dates clearly flagged, generated from the curated data.
Readiness Self-Assessment Framework — 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 — the family landing page grouping this product with CMS Nursing Home Compliance Intelligence.
Nursing Home Compliance Intelligence Dataset — 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 — 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.
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.
Ready to access CMS Prior Authorization Compliance Intelligence?
Questions? Contact our team for a walkthrough.
Databricks
Informational reference compiled from public Federal Register, eCFR, and CMS sources. Not legal advice; consult counsel for compliance decisions.
Last updated