2027 CMS Program Audit Universes: What Your Data Team Needs to Change

These are the changes worth discussing with your data team and delegated entities before the next engagement letter arrives.

CMS has posted its revised Medicare Parts C and D Program Audit Protocols under CMS-10717. This article uses the final package available on November 10, 2026, including the protocols carrying OMB approval through October 31, 2029. The references below identify the individual documents and pages inside the official CMS download.

Which CMS Audit Universes Change in 2027?

The final package changes which files CMS collects and what several familiar files contain.

Removing an audit universe does not, by itself, remove the underlying operational obligation. For example, the revised CDAG redetermination layout still asks about appeals of at-risk determinations even though the separate AR universe is gone. (Sources: ODAG pp. 14, 28-29; CDAG pp. 14, 33-39; FA p. 8; SNPCC pp. 12-16; CPE pp. 3-6)

ODAG: A New Prior Authorization Clock, a Reopening File, and Revised Extraction Rules

The audit clock now matches the 7-day prior authorization rule

Beginning in 2026, standard requests for items and services subject to the prior authorization rules in 42 CFR 422.122 carry a 7-calendar-day regulatory deadline (42 CFR 422.568(b)(1)(ii)). (Source: CMS prior authorization FAQ) The prior ODAG protocol lists a 14-day threshold for its standard organization-determination timeliness test. The 7-day regulatory requirement applies beginning in 2026, regardless of that older protocol wording.

The 2027 protocol brings the published audit test in line with the regulation. For standard initial determinations, it applies:

Expedited standards do not change: 72 hours for an item or service (17 days with an extension), and 24 hours for a Part B drug. The longer limits apply only when an extension meets the applicable regulatory conditions; they are not automatic. (Source: ODAG pp. 4-5)

To apply two clocks, CMS needs to know which one each row belongs under. The OD layout now has a field for that: Column Z, Is Prior Authorization Required? Enter Y if any service, item, or Part B drug in the request required prior authorization. (Source: ODAG p. 18) Our earlier analysis of prior authorization metrics noted that the 2026 OD layout had no way to make this distinction. The 2027 layout does, which means the plan now has to supply it.

Before audit season, three things are worth checking:

RCD has a specific scope

The new RCD universe covers organization and reconsidered determinations, for both coverage and payment, that the sponsoring organization reopened and revised during the review period.

The instructions limit the file to reopenings initiated by the sponsor or an FDR acting on its behalf. They exclude reopenings requested or initiated by outside parties, including enrollees, providers, the IRE, an ALJ, or the Medicare Appeals Council.

The date used to place a case in the review period is the date the sponsor notified the enrollee or provider of the revision. The layout also collects the original determination date and disposition, the reopening date and reason, and the reopened disposition. Those events need separate source fields. (Source: ODAG pp. 28-29)

A useful preparation exercise is to trace a reopened case from its original decision through the revised notice. If the system overwrites the original disposition, the reporting team may have to retrieve it from case history. Finding that limitation now gives the operational team time to address it.

OD gains a second new field

Alongside Column Z, the OD layout adds a notification-type field in Column AA. It identifies the written notice used for the notification assessment, with choices including IDN, CDL, NOMNC, Other, and None.

The inclusion instructions also cover certain decisions made without a request, including concurrent review decisions and specified reductions, terminations, and discharges. Review the selection logic as well as the additional columns. An extract limited to incoming authorization requests can miss decisions covered by the revised instructions. (Source: ODAG pp. 15-18)

2027 ODAG review periods by enrollment size

For ODAG Tables 1, 2, 4, and 5, the final package specifies:

The first two bands increase from the prior 12-week and 8-week periods. PYMT_C has its own rule: four weeks below 500,000 enrollees and two weeks at or above that threshold. In the 2026 protocol, PYMT_C followed the same bands as the other tables, so for plans under 250,000 enrollees the PYMT_C window gets shorter, from 12 or 8 weeks to 4. CMS reserves the right to expand the review period. (Source: ODAG p. 14; comparison with the preceding ODAG protocol)

Test the larger extraction window before audit season. A query that works on eight weeks of data may need attention when it must return twelve weeks with the same submission deadline.

Service Level Data Does Not Mean You Can Retire ODAG Extracts Today

The revised ODAG protocol describes using the Service Level Data Collection for Initial Determinations and Appeals, CMS-10905. Once the data is available, CMS says it will suspend collection of audit universe Tables 1 through 3: OD, RECON, and PYMT_C.

That transition is conditional. In its final comment responses, CMS says it will stop collecting those tables once Service Level Data is fully operational and will issue a memo before the transition. The protocol also expressly retains grievance-universe collection regardless of whether Service Level Data is used. (Sources: ODAG pp. 3, 13; Responses to Comments Received, 30-day notice, pp. 13-14)

Keep the existing extraction capability available until CMS communicates the transition and the applicable audit instructions are clear. The specifications do not establish a blanket January 1 retirement date for all ODAG universes.

Grievances: The Population Changes in Both Part C and Part D

Both GRV_C and GRV_D now include withdrawn and dismissed grievances. Each layout adds fields for:

• The grievance disposition: withdrawn, dismissed, or processed.
• Whether the grievance led to a related coverage request.
• The date that coverage request was initiated.

The date logic matters. Processed grievances use the resolution-notification date to determine whether they fall within the universe period. For withdrawn and dismissed grievances, the instructions allow the received date or the notification date. (Sources: ODAG pp. 26-27; CDAG pp. 43-45)

Start by looking for filters that discard withdrawn or dismissed records. Then check whether the grievance system records the link to a coverage request. Adding three empty columns will not solve either problem.

Document the permitted date approach your team uses for withdrawn and dismissed cases so that internal reports and delegate extracts apply it consistently.

CDAG: Familiar Tables Still Need a Field-by-Field Review

Most retained CDAG layouts will look familiar. That makes it easy to underestimate the work.

For example, the RD field asking about a denial for lack of medical necessity now explicitly refers to the initial coverage determination. A report mapped to the appeal decision would answer a different question. The PYMT_D request-type values also use the revised capitalization shown in the final layout.

The final CDAG instructions revise NDC reporting as well. They allow None when the NDC is unknown or when a multi-ingredient compound claim has no Part D ingredients. Teams should read that instruction in the CDAG tables themselves rather than importing the NDC rules from FA. (Sources: CDAG pp. 17, 23, 29-30, 34, 37, 40)

For each retained table, compare the field description, accepted values, and exceptions alongside the header. An unchanged column count is not evidence that the existing extract is ready.

FA: A New Column Shifts the Rejected-Claims Layout

RCFA and RCT add Drug Name, Strength, and Dosage Form at Column J. NDC moves to K, and the later fields shift accordingly. CMS directs the sponsor to populate the description using the pharmacy-submitted NDC and the plan's drug database. When the NDC is invalid or not found in that database, the specified value is NA.

The repeating reject-reason and pharmacy-message pairs follow the fixed fields. Check their starting position after adding the drug-description column. (Source: FA pp. 10-12)

FA also preserves specific instructions for pharmacy-submitted values. Its general instructions permit blanks for fields submitted blank by the pharmacy, and its NDC field retains handling that differs from CDAG. A single rule that rejects every blank in every universe would miss this distinction. (Source: FA pp. 9-11)

Ask the PBM for a sample containing multiple reject codes, an unknown drug identifier, and an eligibility rejection where the member cannot be identified. Those cases will tell you more about the mapping than a file containing only straightforward records.

SNPCC: Replace the Single Enrollment File With Two Populations

The final SNPCC package separates enrollment reporting into:

• SNPNE: current new enrollees with effective enrollment dates within twelve months of the engagement letter, including the specified cases with a coverage break greater than ninety days.
• SNPCE: current enrollees with at least 365 days of continuous enrollment as of the engagement letter.

Both tables use the original enrollment date in the SNP contract across PBP changes when there has been no break in coverage greater than ninety days. A recent PBP change is therefore not sufficient, on its own, to restart the enrollment date. (Source: SNPCC pp. 12-16)

SNPNE includes the initial HRA completion date and a new initial ICP creation date, as well as the most recent ICP date. SNPCE asks for the most recent and previous HRA dates. Both include a hospital-or-SNF-admission indicator with a twenty-six-week lookback specified in the field instructions.

The old EXC-10 convention is not part of the new layouts. Use the instructions attached to each new HRA field, including its applicable date window and None convention. Do not carry the old value into a new file or substitute a different date simply to make a record pass validation. (Source: SNPCC pp. 13-16)

The package also removes the impact analysis from the SNPCC audit package. CMS says it will continue to request a root cause analysis for any potential noncompliance, and will keep the impact analysis tools on its website for plans to use in their own monitoring. Separately, the protocol adds an HRA Timeliness Mitigation Analysis: when CMS identifies potential HRA timeliness noncompliance, the sponsor quantifies the outreach it made to complete the assessment. It is not a replacement for the impact analysis, and it is not a third enrollment universe. The protocol gives sponsors ten business days to respond to the mitigation-analysis request. (Sources: SNPCC pp. 18-19; final 30-day comment responses pp. 18-19)

CPE: 2027 COA Field Changes

COA remains a twelve-column universe, but its contents change. The revised layout removes Compliance or FWA? and Activity Results Shared? It adds a description of corrective action and the related program area or areas.

The new field follows from a change in scope. CMS states that CPE will no longer be a standalone program area evaluation; instead, CMS and the sponsor review the compliance program together with its impact on the other audited areas. (Source: CPE p. 3) The COA universe is how CMS connects oversight activity to those areas, so the program-area field carries more weight than its position at the end of the layout suggests.

The request covers oversight associated with the audited program areas over the six-month period preceding and including the engagement letter. The record-layout instructions use the activity start or completion date to determine inclusion. (Source: CPE pp. 4-6)

Review the source log before rebuilding the export. If it records only that corrective action was required, someone still needs to supply the description. If an activity spans FA and CDAG, the reporting process needs to preserve both associations.

What to Ask for Before Approving the 2027 Files

Request a sample submission and a mapping document from each team or delegate responsible for an affected universe. The mapping should identify the source of each field, the inclusion and exclusion logic, the date used to select the review period, and the permitted values for missing or inapplicable information.

Then review a small set of cases against the underlying records:

1. A withdrawn or dismissed grievance.
2. A plan-initiated Part C reopening.
3. A standard OD request with Column Z set to Y.
4. A rejected pharmacy claim with more than one rejection reason.
5. A SNP enrollee with a PBP change or break in coverage.
6. A compliance activity involving more than one audit area.

The final layouts remove the old field-type and field-length columns. CMS still expects complete, readable submissions that follow the field descriptions and general instructions. Removing a published character limit does not make an incomplete explanation useful. (Sources: final record layouts; 30-day comment responses p. 3)

Keep the 2026 and 2027 mappings separately identified. Preserve the submitted source values when validating a file, report discrepancies, and have the responsible team resolve them at the source. That leaves a record of what changed and why.

Your first 2027 rehearsal should end with a clear answer to three questions: Did we select the right cases? Did we put the right information in each field? Can we trace that information back to the record CMS would review?

For background on the existing table structure, see our 2026 CMS universe reference and the protocol reference pages for ODAG, CDAG, FA, SNPCC, and CPE. Those pages describe the protocols in use for 2026 audits. Use the final 2027 package for the revised submission requirements.

Frequently Asked Questions