> 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/readiness-framework.md). # 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**. {% hint style="info" %} **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. {% endhint %} {% hint style="warning" %} Informational reference compiled from public Federal Register, eCFR, and CMS sources. Not legal advice; consult counsel for compliance decisions. {% endhint %} ## 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](/data-catalog/cms-prior-auth-compliance-dataset/compliance-questions-cookbook.md) 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.* --- # 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/readiness-framework.md?ask=&goal= ``` `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.