> 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/deadline-calendar.md).

# Deadline Calendar

The verified compliance anchors across the CMS prior-authorization rulemaking wave, organized by date. Every anchor below is drawn from the curated `OBLIGATION_APPLICABILITY` facts and is reproducible from the `COMPLIANCE_DEADLINES` view; this page is a narrative rendering of the same data, not a separate source. **Final and proposed dates are marked; proposed dates come from CMS-0062-P and are not binding.**

{% hint style="warning" %}
Informational reference compiled from public Federal Register, eCFR, and CMS sources. Not legal advice; consult counsel for compliance decisions. Dates key off entity-specific semantics; see [How the anchors read per entity](#how-the-anchors-read-per-entity) before treating any anchor as a literal due date.
{% endhint %}

## Milestone timeline

| Anchor           | What is due                                                                                                                                                                 | Rule       | Certainty    | Status                                          |
| ---------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | ------------ | ----------------------------------------------- |
| **Apr 8, 2024**  | Patient Access API: expanded data content (all USCDI classes) for impacted payers                                                                                           | CMS-0057-F | Final        | In effect                                       |
| **Jan 1, 2026**  | PA decision timeframes: 72h expedited / 7 calendar days standard (all impacted payers **except** QHP issuers on the FFEs, who are exempt)                                   | CMS-0057-F | Final        | In effect                                       |
| **Jan 1, 2026**  | Denial-reason specificity, any communication channel (all impacted payers)                                                                                                  | CMS-0057-F | Final        | In effect                                       |
| **Jan 1, 2026**  | Public reporting of PA metrics begins (all impacted payers)                                                                                                                 | CMS-0057-F | Final        | In effect                                       |
| **Mar 31, 2026** | **First public PA-metrics posting due** on payer websites (for CY2025), recurring annually thereafter                                                                       | CMS-0057-F | Final        | In effect · recurs annually (next Mar 31, 2027) |
| **Mar 31, 2026** | **First Patient Access API usage metrics reported to CMS** (for CY2025), recurring annually                                                                                 | CMS-0057-F | Final        | In effect · recurs annually (next Mar 31, 2027) |
| **Jan 1, 2027**  | Patient Access API: add prior-authorization information                                                                                                                     | CMS-0057-F | Final        | Upcoming                                        |
| **Jan 1, 2027**  | Provider Access API (extension path available for Medicaid/CHIP FFS)                                                                                                        | CMS-0057-F | Final        | Upcoming                                        |
| **Jan 1, 2027**  | Payer-to-Payer API (extension path available for Medicaid/CHIP FFS)                                                                                                         | CMS-0057-F | Final        | Upcoming                                        |
| **Jan 1, 2027**  | Prior Authorization API: CRD + DTR + PAS capability (extension path available for Medicaid/CHIP FFS)                                                                        | CMS-0057-F | Final        | Upcoming                                        |
| **CY2027**       | MIPS Electronic Prior Authorization measure performance period (clinicians and eligible hospitals/CAHs)                                                                     | CMS-0057-F | Final        | Upcoming                                        |
| **Oct 1, 2027**  | Drug prior-authorization into the Prior Authorization API; drug PA decision timeframes; drug denial-reason specificity; NCPDP pharmacy PA standards; public drug-PA metrics | CMS-0062-P | **Proposed** | Proposed                                        |
| **Jan 1, 2028**  | Interoperability + PA API requirements extended to small-group QHP issuers on the FF-SHOPs                                                                                  | CMS-0062-P | **Proposed** | Proposed                                        |
| **Jan 1, 2028**  | STU-2-era FHIR implementation-guide stack proposed to expire                                                                                                                | CMS-0062-P | **Proposed** | Proposed                                        |
| **May 26, 2028** | Claims-attachments standards: X12N 275/277 and the C-CDA attachments IGs (claims attachments only; **not** prior-authorization scope)                                       | CMS-0053-F | Final        | Upcoming                                        |

*Status computed as of July 7, 2026 from the anchor dates above; proposed dates are never marked in effect.*

Two obligations from CMS-0062-P (adopting FHIR as the HIPAA standard replacing X12N 278, and the FHIR PA-attachments standard) attach to HIPAA covered entities with a compliance clock defined **relative to a future final rule's effective date** ("24 months from the effective date of a final rule"). Because no dated anchor exists yet, they carry `compliance_date_type = RELATIVE_TO_FINALIZATION` with a NULL anchor and are quarantined from the gold view; **the date is tracked, never fabricated**, and will resolve when CMS-0062-P is finalized.

## How the anchors read per entity

The same anchor date means different things for different entity types. This is why the product never publishes a bare `compliance_date`: the anchor is paired with a `compliance_date_type` that tells you how to resolve it.

| Entity type                                 | Default date semantics      | How to read a Jan 1 anchor                               |
| ------------------------------------------- | --------------------------- | -------------------------------------------------------- |
| Medicare Advantage organizations            | `LITERAL`                   | The literal calendar date                                |
| State Medicaid / CHIP fee-for-service       | `LITERAL`                   | The literal calendar date                                |
| Medicaid / CHIP managed care                | `RATING_PERIOD_ON_OR_AFTER` | The first rating period beginning on or after the anchor |
| QHP issuers on the FFEs (and FF-SHOPs)      | `PLAN_YEAR_ON_OR_AFTER`     | The first plan year beginning on or after the anchor     |
| MIPS clinicians / eligible hospitals & CAHs | `PERFORMANCE_PERIOD`        | The applicable EHR reporting / performance period        |

Resolving a managed-care plan's actual due date requires its rating-period start, and a QHP's requires its plan-year start; neither is in the rule text, so the product supplies the anchor and the semantics and leaves the final resolution to the entity. Query `OBLIGATION_APPLICABILITY` (or `COMPLIANCE_GOLD`) with your `entity_type_id` to get the anchor and its semantics for every obligation.

## Extensions and exemptions

These are first-class rows, not footnotes:

* **QHP issuers on the FFEs are exempt** from the PA decision-timeframe obligation: an explicit `EXEMPT` applicability row, not a missing one.
* **Medicaid and CHIP fee-for-service programs have an extension path** on the Provider Access, Payer-to-Payer, and Prior Authorization APIs: `EXTENSION_AVAILABLE` applicability, with the basis in `extension_exemption_notes`.
* **CMS-0053-F rows are adjacency only**: every one carries `is_pa_scope = FALSE`. They appear in the calendar because the May 26, 2028 claims-attachments date is a real CMS deadline payers track, but they are not prior-authorization obligations, and CMS explicitly declined to finalize X12N 278 for prior-authorization attachments (the gap CMS-0062-P proposes to fill with FHIR).

## Reproduce this calendar

```sql
SELECT
    deadline_type,
    entity_type_id,
    obligation_id,
    compliance_date_anchor,
    compliance_date_type,
    compliance_date_display,
    date_certainty
FROM DWV.COMPLIANCE_DEADLINES
ORDER BY compliance_date_anchor, date_certainty DESC, entity_type_id;
```

***

*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/deadline-calendar.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.
