Readiness Self-Assessment Framework

A practical framework for scoring how ready a payer is for the CMS prior-authorization and interoperability obligations, across three dimensions: API readiness, operational readiness, and reporting readiness.

This page is editorial guidance, not data. Unlike the dataset — where every row traces to a Federal Register pinpoint and a verbatim quote — this framework is Dataplex's practical structuring of the obligations into a self-assessment. It is a way to organize your own internal review; the authoritative obligations, dates, and semantics live in the dataset tables (OBLIGATION_APPLICABILITY, COMPLIANCE_GOLD, REPORTING_REQUIREMENTS, OBLIGATION_STANDARDS). Use the data for what is required; use this framework to structure how you check yourself against it.

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

How to use this framework

1. Identify your entity types. Pull your applicable obligations from COMPLIANCE_GOLD filtered to your entity_type_id(s). That list — not this page — is your obligation set.

2. Score each dimension below as Not started / In progress / Ready, honestly, against the anchor dates that apply to you under your date semantics.

3. Prioritize by the nearest anchor. The January 1, 2026 operational obligations apply regardless of API build, so operational and reporting readiness are the near-term priorities even for payers whose API work targets January 1, 2027.

4. Revisit as the radar moves. The proposed CMS-0062-P obligations (drug PA, targeted October 1, 2027) and the STU-2 IG expiry (proposed January 1, 2028) are not binding yet, but a readiness plan that ignores them will be re-planning in a year.

Dimension 1 — API readiness

The four CMS-0057-F APIs (Patient Access, Provider Access, Payer-to-Payer, Prior Authorization) with a January 1, 2027 anchor, plus the underlying FHIR / Da Vinci implementation guides.

Check	Not started → Ready
Implementation-guide versions pinned	Have you identified the exact IG versions each API obligation requires (from OBLIGATION_STANDARDS × STANDARDS_REGISTRY), and confirmed you are building to current — not expiring — versions?
Prior Authorization API stack	Is the CRD + DTR + PAS capability scoped as one integrated build, not three disconnected projects?
Patient Access API PA information	Beyond the 2024 expanded-data-content requirement already in effect, is the January 2027 addition of prior-authorization information planned?
Provider Access & Payer-to-Payer	If you are a Medicaid/CHIP FFS program, have you decided whether to use the available extension path, and documented the basis?
Endpoint publication & discovery	Are your API endpoints registered/publishable as the rules contemplate?
Upgrade runway	Do you have a plan for the proposed STU-2-era IG expiry (January 1, 2028) so a 2027 build is not immediately stale?

Dimension 2 — Operational readiness

The three January 1, 2026 obligations that apply regardless of API build — the near-term, non-negotiable core.

Check	Not started → Ready
Decision timeframes	Can you meet 72-hour expedited and 7-calendar-day standard PA decisions today? (QHP issuers on the FFEs are exempt from this obligation — confirm your status.)
Denial-reason specificity	Does every denial — through any communication channel — carry a specific reason detailed enough for the provider's next action, per the required denial-notice elements?
Entity-specific effective dating	Have you resolved whether your obligations key off a literal date, a rating period, or a plan year — and set your internal go-live to the correct one?
Extension / exemption posture	Have you documented every extension path or exemption you intend to rely on, with the citation basis (the dataset carries the verbatim basis in scope_basis and extension_exemption_notes)?
Denial-notice templates	Have you validated your enrollee, provider, and API-response denial notices against the required elements and their channel scopes?

Dimension 3 — Reporting readiness

The public website postings and the CMS-submitted usage metrics — the obligations that recur annually and make this a standing program, not a one-time project.

Check	Not started → Ready
Public metrics posting	Can you produce the required public PA metrics (approval and denial rates, standard and expedited; appeals overturned; average and median decision times; the items-and-services list) for the March 31 annual posting?
First posting readiness	The first public posting was due March 31, 2026 for CY2025 and recurs every spring — is your data pipeline for it in place, or are you posting under time pressure each March?
CMS-submitted API usage metrics	Can you report Patient Access API usage metrics to CMS annually (also first due March 31, 2026 for CY2025)?
Metric definitions locked	Are your numerator/denominator definitions aligned to the rule's metric definitions (see METRIC_DEFINITIONS), so year-over-year figures are consistent and defensible?
MIPS ePA measure	If you have MIPS clinicians or eligible hospitals/CAHs, is the Electronic Prior Authorization measure attestation planned for the CY2027 performance period?

Turning the framework into a plan

The dataset does the authoritative work: run the Compliance Questions Cookbook queries for your entity type to get your obligation set, deadlines, required standards, reporting duties, and denial-notice elements — traced to the rule. Use the three dimensions above to structure your internal review of each, prioritized by the nearest anchor under your date semantics. This framework and the obligation data are the basis for a self-directed readiness review.

---

This framework is editorial guidance from Dataplex, not part of the traced dataset. Informational reference compiled from public Federal Register, eCFR, and CMS sources. Not legal advice; consult counsel for compliance decisions.