The CDAG Universe: A Table-by-Table Guide for Part D Compliance Teams
Sevana Health Team
May 15, 2026
If you read our ODAG table-by-table guide and thought, “Great, now do Part D,” this is that post. Coverage Determinations, Appeals and Grievances (CDAG) is the Part D counterpart to ODAG, and on the surface the two protocols look almost identical. Same lifecycle, same cross-table relationships, similar field structures.
The differences are where plans get into trouble. CDAG has tighter timeframes, different case types, and almost always pulls from a Pharmacy Benefit Manager (PBM) system that wasn't designed with CMS universe files in mind. Universes that pass ODAG validation cleanly will often fall apart on CDAG for reasons that have nothing to do with Part C.
This guide walks through the CDAG tables one at a time, calls out where each diverges from its ODAG cousin, and points to the validation issues we see most often when plans run their files through the scrubber.
A note on terminology. Part D uses different words for the same concepts. What ODAG calls a “reconsideration” is a “redetermination” in CDAG. What ODAG calls a payment determination on the medical side is a payment determination on the pharmacy side (same name, different data sources). If your team is more familiar with Part C, the vocabulary alone causes confusion in the first few cycles.
The CDAG Tables at a Glance
CDAG has six tables. A member or prescriber asks for something, the plan makes a decision, the member can appeal, and the plan has to actually do what was approved. Exception requests get their own table because the documentation rules are different.
CD (Coverage Determinations)
Prior authorization requests, B vs. D coverage decisions, and other standard coverage determinations.
CDER (Exception Requests)
Tier exceptions, formulary exceptions, step therapy exceptions, and quantity limit exceptions. Separate table because each requires a prescriber's supporting statement.
PYMT_D (Payment Determinations)
Member requests reimbursement for a Part D drug they already paid for out of pocket.
RD (Redeterminations)
Member or prescriber appeals a denied CD, CDER, or PYMT_D. Plan takes a second look.
EFF_D (Effectuations)
Plan carries out an approved determination. Did the prescription actually get filled or the reimbursement actually get paid?
GRV_D (Grievances)
Member files a complaint about pharmacy access, customer service, or other Part D experience issues. Distinct from the CD/appeal process.
Where CDAG Diverges from ODAG
Before we go table by table, the differences worth understanding up front:
| Dimension | ODAG (Part C) | CDAG (Part D) |
|---|---|---|
| Standard pre-service timeframe | 14 calendar days | 72 hours |
| Expedited timeframe | 72 hours | 24 hours |
| Payment timeframe | 60 days (clean claim) | 14 calendar days |
| Appeal name | Reconsideration | Redetermination |
| Appeal standard timeframe | 30 calendar days | 7 calendar days |
| Appeal expedited timeframe | 72 hours | 72 hours |
| Primary source system | Utilization Management (UM) platform | PBM and claims processor |
| Requester | Usually the provider | Often the prescriber, often via the pharmacy |
| Case categories | Pre-service, post-service, expedited | Plus tier exceptions, formulary exceptions, quantity limits, step therapy, prior auth, B vs. D |
The compressed timeframes deserve emphasis. A 72-hour standard for a coverage determination means that a request received Friday at 4pm has to be resolved by Monday at 4pm. A 24-hour expedited window means an after-hours request that comes in Saturday morning is due Sunday morning. The math is unforgiving, and small delays in receipt logging blow timeliness in a way that ODAG's 14-day standard rarely does.
Table 1: Coverage Determinations (CD)
The foundation table for CDAG. Every request to cover a Part D drug goes here, whether the request originated with the member, the prescriber, or the pharmacy at the point of sale. CMS audits this table heavily because it's where most Part D access decisions actually happen.
What Goes in This Table
CD captures standard coverage determinations: prior authorizations and the special category decisions that don't involve a formulary exception. Tier, formulary, step therapy, and quantity limit exceptions live in CDER (Table 2) because they have different documentation requirements.
Standard CDs
- •Prior authorization requests
- •Pharmacy-initiated coverage determinations at point of sale
- •Member or prescriber-initiated coverage questions
Special Categories
- •B vs. D determinations (which part covers the drug)
- •At-risk beneficiary (drug management program) determinations
- •Expedited requests (24-hour clock)
The Fields That Cause the Most Trouble
| Field | What Goes Wrong | Impact |
|---|---|---|
| Request Receipt Date and Time | Time stamps missing on expedited cases. Receipt date based on when the case landed in the PBM's UM queue instead of when the request was received from any source. Pharmacy point-of-sale rejections not counted as receipt. | IDS risk, timeliness uncomputable |
| Case Type / Request Category | Tier exceptions coded as formulary exceptions. Quantity limit exceptions coded as step therapy. The PBM's internal categories don't map cleanly to CMS allowed values. | Audit finding on case categorization |
| Expedited Indicator | Member or prescriber requested expedited handling, plan declined to expedite, but the universe shows the case as standard with no record of the expedited request or the denial of expedited status. | Failure to document expedited denial |
| Decision Date and Time | Date the decision was system-entered rather than when it was clinically made. Decisions made after hours timestamped to the next business day. | IDS risk, timeliness rates inflated |
| Drug Identifier (NDC) | NDC missing, truncated, or formatted with dashes. NDC valid at time of submission but obsolete at time of decision. | Format-level IDS finding |
| Prescriber Information | Prescriber NPI missing or invalid. Practice name in the prescriber name field. International prescribers handled inconsistently. | Cross-reference failures during case review |
| Verbal Notification | Required for expedited denials, missing because the verbal step happens through a call center that doesn't feed the PBM system. Date entered but no time, defeating the audit purpose. | IDS risk, regulatory requirement unmet |
The pharmacy point-of-sale issue is worth a closer look. When a pharmacy submits a claim that gets rejected for a coverage reason (prior auth required, non-formulary, quantity exceeded), CMS treats that pharmacy rejection as the start of the coverage determination clock if the member is at the counter. A lot of plans only count CDs that come in through their formal intake channel, which means rejected pharmacy claims never get tracked in the CD universe. CMS will compare the FA rejected claims universe against the CD universe during audits, and the gap becomes visible quickly.
Table 2: Exception Requests (CDER)
CDER tracks coverage determinations where the member or prescriber asks the plan to apply a different rule than the formulary specifies. CMS treats these as a separate universe table from standard CDs because each exception requires a prescriber's supporting statement and validates against different criteria. Same timeframes as CD (72 hours standard, 24 hours expedited), different paperwork.
The Four Exception Types
| Exception Type | What the Member is Asking For | What CMS Validates |
|---|---|---|
| Tier exception | Cover this drug at a lower copay tier than the formulary assigns | Prescriber statement on why preferred-tier alternatives won't work; consistency between requested and approved tier |
| Formulary exception | Cover a drug that isn't on the plan's formulary at all | Prescriber statement; evidence a formulary alternative was considered |
| Step therapy exception | Skip a required first-line therapy and go directly to the requested drug | Prescriber statement; whether the step therapy edit was actually on the approved formulary |
| Quantity limit exception | Bypass the formulary's quantity-per-fill limit for this drug | Prescriber statement; quantity requested matches clinical need |
The Fields That Cause the Most Trouble
| Field | What Goes Wrong |
|---|---|
| Exception Type Code | Tier exceptions coded as formulary exceptions. Quantity limit exceptions coded as step therapy. PBM internal categories that don't map cleanly to the four CMS-defined types. |
| Prescriber Statement Date | Required for every exception. Field left blank when the statement was received but never logged. Date defaulted to the case-open date instead of the actual receipt date. |
| Requested Tier / Approved Tier | For tier exceptions, both fields should be populated and tell a coherent story. Approved-tier value missing on approved cases, or approved tier matching the original non-exception tier. |
| Alternative Drug Considered | For formulary exceptions, plans should be able to show what formulary alternative was considered. Field often blank because the conversation happened verbally and was never captured. |
Where CDER goes wrong most often. Plans that don't distinguish CDER cases from regular CD cases inside their PBM system have to reconstruct the split for the universe submission. The reconstruction is where errors get introduced. Verify the case-type classification before the file goes anywhere near a submission folder, and reconcile the CDER row count against your PBM's internal exception-request reports.
Table 3: Payment Determinations (PYMT_D)
Payment determinations cover requests for reimbursement of Part D drugs the member already paid for. Most commonly this happens when a member fills a prescription outside the network, pays cash, and then asks the plan to cover the cost. The 14-day standard from 42 CFR § 423.568 applies.
The Data Source Problem
Payment determinations are almost always handled by a different team and a different system than coverage determinations. Reimbursement requests come in by mail or member portal, get keyed into a claims system, and resolve as either an approved payment or a denial letter. The PBM that handles CDs may have nothing to do with PYMT_D at all.
That means the PYMT_D table is almost always assembled from a separate source feed, with separate date formats, separate member ID conventions, and separate disposition codes. Reconciling those feeds into a CMS-compliant universe is where most PYMT_D validation issues originate.
Common PYMT_D Issues
- •Request date based on when the document was scanned, not received
- •14-day clock started over when the case was reassigned internally
- •Out-of-network claims not categorized correctly
- •Drug NDC missing because reimbursement was based on receipts, not pharmacy claim data
What Clean PYMT_D Data Looks Like
- •Receipt date matches postmark or portal submission timestamp
- •Single, continuous 14-day clock from receipt
- •NDC populated even when not strictly required by the claim form
- •Disposition codes mapped to CMS allowed values
Table 4: Redeterminations (RD)
When a CD, CDER, or PYMT_D is denied and the member or prescriber appeals, the case becomes a redetermination. This is Part D's version of the ODAG reconsideration, with one important difference: the standard clock is 7 calendar days, not 30. That window goes faster than teams realize.
Where Redeterminations Get Messy
The 7-Day Trap
The 7-day standard for Part D appeals is calendar days, not business days. An appeal received on a Tuesday is due the following Tuesday. Three of those seven days are usually a weekend. Plans with manual hand-offs between intake, clinical review, and notification routinely lose two days to the calendar before clinical review even starts.
Auto-Forward to the IRE
Same rule as ODAG: untimely appeals must be auto-forwarded to the Independent Review Entity. Same failure pattern, too. Cases that miss the 7-day window often sit in the queue for another day or two before someone forwards them, which makes the forwarding date look manual rather than automatic. Auditors notice the gap.
Who Filed the Appeal
Part D appeals can be filed by the member, the member's representative, or the prescriber. The data field has to reflect who actually filed. Plans sometimes default to “member” when prescriber-initiated appeals are common in PA cases. The misclassification doesn't usually trigger IDS by itself, but it causes inconsistencies that auditors investigate.
Linking to the Underlying Determination
Every RD should trace back to a CD, CDER, or PYMT_D in Tables 1, 2, or 3. The case ID field is what CMS uses to make that link. If the PBM assigns a new case ID at the appeal stage and doesn't carry the original ID forward, the appeal floats with no parent record. That's a cross-table consistency failure.
Table 5: Effectuations (EFF_D)
This table answers the question CMS most cares about: when the plan approved the drug, did the member actually get it? Effectuations are where many plans look strong on paper and weak in practice, because the timing data lives in the PBM's claim adjudication system and not in the UM platform that processed the determination.
Part D Effectuation Standards
Standard CD reversed in favor of the member
Expedited CD reversed in favor of the member
Favorable redetermination at the plan level
IRE-favorable decision communicated to plan
Payment effectuations (favorable PYMT_D or PYMT_D appeal)
What “Effectuated” Actually Means in Part D
For a coverage determination, effectuation means the drug is available for the member to fill. Practically, that requires the PBM's point-of-sale system to be updated so the next pharmacy claim adjudicates as approved. CMS audit findings frequently come from a gap between when the UM platform marked the case approved and when the PBM's adjudication system actually accepted the override.
What we see in validation: the effectuation date in the universe matches the UM platform's approval timestamp, but the adjudication override didn't actually post until 12 to 36 hours later. When CMS pulls the claim history during case file review, the member is still seeing pharmacy rejections after the supposed effectuation date. That gap is where findings emerge, and the universe data alone won't reveal it. Plans need to compare their UM-side effectuation dates against PBM claim history before submission.
Table 6: Grievances (GRV_D)
Part D grievances cover complaints that are not about coverage decisions: pharmacy access problems, wait times at the pharmacy counter, customer service issues, mail-order problems, and similar service complaints. The same 30-day standard as ODAG grievances applies, with a 24-hour expedited window for quality of care issues.
CDAG Grievance-Specific Pitfalls
Coverage Complaint vs. Service Complaint
A member who calls to say “I can't get my prescription because you keep rejecting it” is initiating a coverage determination, not filing a grievance. A member who calls to say “Your customer service line had me on hold for 40 minutes” is filing a grievance. Member services teams that don't distinguish carefully will route the wrong cases to the wrong queue, and CMS notices.
Network Pharmacy Access
Pharmacy access grievances (closest network pharmacy is too far, preferred pharmacy stopped stocking the drug, etc.) are a category where plans frequently undercount. Cases get logged as “network inquiries” in member services and never make it into the grievance universe.
CTM Referrals
Complaints that reach CMS through the Complaints Tracking Module need to land in the grievance universe whether or not the plan agrees they qualify as grievances. Filtering CTM cases by the plan's internal classification is a common gap.
Cross-Table Consistency in CDAG
The CDAG tables tell one story across six files. The cross-table checks that matter most:
CD and CDER to RD Linkage
Every appeal in RD should match a denied or partially denied determination in CD, CDER, or PYMT_D. If the case IDs don't carry forward, CMS can't verify the appeal had a valid underlying determination.
Favorable Outcomes to EFF_D
Every favorable CD, CDER, PYMT_D, or RD should have a corresponding effectuation. If 180 cases were approved but only 165 effectuations are in Table 5, you have either a completeness problem or 15 members who never got their drug.
FA Rejected Claims to CD
This is the CDAG-specific check that surprises plans. Pharmacy point-of-sale rejections in the FA universe should generally have corresponding CDs in the CDAG universe when the member was present at the counter. A large volume of FA rejections with no matching CDs suggests the plan isn't capturing pharmacy-triggered coverage determinations.
Member Identifier Consistency
MBI must be consistent across all six CDAG tables and against the FA universe. PBM systems sometimes carry internal cardholder IDs that don't map one-to-one to MBI. Inconsistent member identifiers are one of the most common cross-table issues we see.
Date Range Alignment
All six tables must cover the same audit review period. A CD table that runs through the end of the period but a PYMT_D table that stops two weeks short, because reimbursement processing runs on a different cycle, gets flagged.
The PBM Delegation Reality
Most Medicare Advantage Part D plans delegate large parts of CDAG operations to their PBM. The PBM handles intake, clinical review, system-of-record management, and often the universe file production itself. From CMS's perspective, none of that delegation matters. The plan owns the data.
That creates a few specific patterns we see in CDAG validation that we don't see as often in ODAG:
- 1The plan accepts the PBM's file as-is. No independent validation, no field-level review, just a hand-off into the production folder. This is the single biggest risk pattern we encounter.
- 2PBM categories don't match CMS values. The PBM's internal disposition codes work fine for their operations but were never reconciled against CMS allowed values. Universes show valid-looking dispositions that aren't actually on the CMS list.
- 3Sub-delegates the PBM uses don't feed the universe. If the PBM uses a specialty pharmacy vendor for certain drug classes, those cases may be tracked in the vendor's system without flowing back into the PBM's universe extract.
- 4The plan's own data is missing. Cases the plan's member services team handled directly (with no PBM involvement) sometimes don't make it back into the PBM's universe. The plan ends up under-reporting its own activity.
If your plan delegates CDAG to a PBM, treat the PBM's file as input, not output. Validate it against CMS specs before it goes anywhere near a submission folder. Our blog post on measuring TPA performance goes deeper on what to track over time.
What to Do Before Your Next Submission
Map your CDAG data sources end to end.
Write down which system feeds each table, who owns it, and which fields cross system boundaries. Most CDAG issues live at those boundaries.
Compare FA rejections against your CD universe.
Pharmacy point-of-sale rejections that should have triggered CDs are the most common gap we find. If the volumes are very different, investigate before CMS does.
Validate timeliness math on the calendar, not just the data.
CDAG's tight windows mean that weekend and holiday handling matters. Spot-check cases that started on a Friday afternoon.
Confirm PBM disposition codes against CMS allowed values.
Get the current CMS code list and cross-reference. Codes that have drifted are an easy IDS finding to avoid.
Reconcile effectuations against actual claim history.
An effectuation date in the universe is only meaningful if the PBM adjudication system reflects the override. Pull a sample and verify the next pharmacy claim adjudicated correctly.
Run the file through a scrubber before it leaves the building.
Whether ours or another, automated validation against CMS specs is the only way to catch the patterns described above at scale. Manual sampling will not find them.
Validate All 6 CDAG Tables Before Submission
The CMS Universe Scrubber validates every CDAG table against the current CMS specification: field formats, timeliness calculations, cross-table consistency, PBM disposition code mapping, and hidden character detection. Catch IDS-triggering errors before CMS does.