The ODAG Universe: A Table-by-Table Guide for Compliance Teams
Sevana Health Team
February 23, 2026
If your plan gets audited by CMS, there's a good chance ODAG will be part of it. Organization Determinations, Appeals, and Grievances is one of the most frequently audited protocols, and for good reason: it covers the core of how your plan handles member requests for services, appeals of denied requests, and grievances about care or service quality.
The ODAG protocol requires up to six separate universe tables, each capturing a different stage of the member rights process. Getting any one of them wrong can trigger an IDS finding or an audit condition.
This guide walks through each table: what it captures, the fields that matter most, and the mistakes we see most often when validating files.
A note on scope: This guide covers the Part C ODAG protocol. Part D has its own parallel protocol (CDAG) with similar but distinct tables and rules. We'll cover CDAG in a future post.
How the Six Tables Fit Together
Before diving into each table, it helps to understand how they relate. The ODAG tables trace the lifecycle of a member's interaction with your plan:
OD (Organization Determinations)
Member requests a service. Plan makes an initial decision.
RECON (Reconsiderations)
Member appeals a denied OD. Plan takes a second look.
PYMT_C (Payment/Claims)
Member or provider requests payment for a service already received.
EFF_C (Effectuations)
Plan carries out an approved determination. Did the member actually get the service?
GRV_C (Grievances)
Member files a complaint about quality, access, or service. Separate from the OD/appeal process.
AIP (Applicable Integrated Plan)
D-SNP specific: tracks reductions, suspensions, and terminations of integrated plan benefits.Note: CMS has suspended collection of this table for 2026.
Think of it this way: Tables 1–4 follow a case from initial request through resolution. Table 5 covers a separate complaint process. Table 6 covers a D-SNP-specific scenario. Each table has its own fields, timeliness rules, and validation requirements, but they share a common structure and many of the same data quality challenges.
Table 1: Organization Determinations (OD)
This is the foundation table. Every pre-service request, every Part B drug request, and every other organization determination your plan processes during the audit review period goes here.
What CMS Is Looking For
Timeliness
- •Standard pre-service: 14 calendar days from receipt
- •Expedited: 72 hours from receipt
- •Part B drugs: 24 hours (expedited) or 72 hours (standard)
- •Extensions: up to 14 additional days with proper documentation
Decision Quality
- •Was the correct regulatory standard applied?
- •Were denial letters compliant with notice requirements?
- •Was clinical review performed by a qualified reviewer?
Key Fields and Common Mistakes
| Field | What Goes Wrong | Impact |
|---|---|---|
| Receipt Date/Time | Missing time stamps on expedited requests. Using date received by plan instead of date received from any source (member, provider, pharmacy). | IDS risk — timeliness cannot be calculated |
| Expedited Indicator | Cases processed on an expedited timeline but flagged as standard, or vice versa. Inconsistency between the indicator and the actual timeframes in the data. | Audit finding — wrong timeliness standard applied |
| Decision Date | Using the date the decision was entered into the system rather than the actual clinical decision date. Backdating decisions after the fact. | IDS risk — inflates compliance rates |
| Extension Fields | Extension notification date left blank when an extension was taken. Extension reason not matching allowed CMS values. | Audit finding — extension validity questioned |
| Verbal Notification Date | Populated for cases where no verbal notification actually occurred. Left blank for expedited denials that require verbal notice. | IDS risk — data integrity failure |
The receipt date issue deserves special attention. CMS counts timeliness from when the request is received from any source — not when it reaches the utilization management department. If a provider faxes a request on Monday and your intake team doesn't log it until Wednesday, Monday is the receipt date. Getting this wrong systematically will make your timeliness rates look better than they are, and auditors will catch it during case file review.
Table 2: Reconsiderations (RECON)
When a member or provider appeals a fully or partially denied organization determination, it becomes a reconsideration. This table tracks the plan's second-level review.
What Makes This Table Tricky
The IRE Auto-Forward Rule
If your plan doesn't complete a reconsideration within the required timeframe (30 days standard, 7 days expedited), the case must be auto-forwarded to the Independent Review Entity (IRE). Your universe needs to show this happened. We frequently see plans that missed the auto-forward deadline with no evidence the case was sent to the IRE — a clear compliance failure.
Linking Back to the OD
Each reconsideration should trace back to a specific organization determination. CMS will cross-reference your RECON and OD tables. If a case appears in RECON but the corresponding OD isn't in Table 1 (or vice versa for denied cases with no appeal), that raises questions about universe completeness.
Dismissed vs. Withdrawn
Plans sometimes confuse these. A dismissal is a plan action (e.g., the appeal doesn't meet filing requirements). A withdrawal is a member action. The distinction matters because dismissed cases still need to meet processing requirements, and CMS checks whether dismissals were appropriate.
| Field | What Goes Wrong |
|---|---|
| Appeal Receipt Date | Using the date the case was assigned to a reviewer rather than the date the appeal was received by the plan. |
| IRE Forwarding Date | Blank for untimely cases. Or populated with a date that's weeks after the deadline, suggesting the auto-forward process isn't actually automated. |
| Outcome | Inconsistencies between the disposition code and the actual case outcome. Partially favorable decisions coded as fully favorable or fully adverse. |
Table 3: Payment/Claims (PYMT_C)
This table covers payment determinations — requests for reimbursement after a member has already received a service. It's the post-service counterpart to the pre-service OD table.
Why Plans Struggle Here
Payment determinations often live in a different system than pre-service authorizations. The OD and RECON data typically comes from your utilization management platform, but payment data comes from your claims system. Merging these into a CMS-compliant universe file introduces a whole category of data mapping challenges.
Common Data Mapping Issues
- •Claims system uses internal member IDs instead of MBIs
- •Date fields stored in different formats across systems
- •Decision categories in the claims system don't map cleanly to CMS disposition codes
- •Timeliness calculated from claim receipt date vs. request date
What Clean Data Looks Like
- •MBI used consistently (11-character format)
- •All dates in CCYY/MM/DD format
- •Disposition codes match CMS allowed values exactly
- •60-day clean claim timeline accurately reflected
The 60-day standard for clean claims (per 42 CFR § 422.568) is straightforward in regulation but messy in practice. Plans need to distinguish between the date a claim is received and the date it becomes a “clean claim” (all required information present). CMS measures from the latter, but many plans track from the former.
Table 4: Effectuations (EFF_C)
This is the table that asks: did the member actually get what was approved?
When a determination or appeal results in a favorable or partially favorable outcome, the plan must effectuate it — authorize the service, process the payment, or provide the benefit. CMS tracks whether this happened and whether it happened on time.
Effectuation Timeliness Standards
Reversed standard OD (plan reverses its own denial)
Reversed expedited OD
Favorable reconsideration (from date of decision)
Payment effectuations after a favorable determination
The Effectuation Blind Spot
In our experience, this is the table where plans have the least visibility. The reason is organizational: the team that makes the determination (UM department) is often not the same team that effectuates it (provider services, claims, pharmacy). Hand-off failures between departments are the single biggest source of effectuation timeliness issues.
What we see frequently: The effectuation date in the universe is the date someone entered the authorization into the system, not the date the member was actually notified or the service was arranged. CMS cares about when the member got the benefit, not when internal paperwork was completed.
Table 5: Grievances (GRV_C)
Grievances are fundamentally different from the other ODAG tables. They're not about coverage decisions — they're complaints about quality of care, access to providers, waiting times, customer service, or any other aspect of the member's experience.
Key Differences from OD/Appeals
| Aspect | OD/Appeals | Grievances |
|---|---|---|
| Subject | Coverage and payment decisions | Quality, access, and service complaints |
| Timeliness | Varies by type (14 days, 72 hours, etc.) | 30 days standard; 24 hours for expedited quality of care |
| Appeal rights | Multiple levels of appeal including IRE | No appeal rights — resolved at plan level |
| Common source | UM/authorization system | Member services, CTM complaints, provider calls |
Where Grievances Go Wrong
Misclassification
The most common issue isn't a data field error — it's that the case shouldn't be in this table at all. A member calling to complain that their prescription was denied isn't filing a grievance — they're likely initiating an appeal. Plans that route these cases to the grievance queue instead of the appeals queue create compliance problems in both tables.
Incomplete Capture
Grievances come from multiple sources: member services calls, written complaints, CTM (Complaints Tracking Module) referrals from CMS, and even social media in some plans' operating procedures. If your grievance universe only pulls from your formal grievance tracking system, you may be missing cases that were handled informally or routed through other channels.
Expedited Grievance Timeliness
Quality of care grievances that involve an ongoing treatment or an active health crisis must be resolved within 24 hours. The time stamp on receipt is critical here. If your system only captures the date (not the time), you can't demonstrate 24-hour compliance.
Table 6: AIP (Applicable Integrated Plan)
This table applies only to Dual-Eligible Special Needs Plans (D-SNPs) that are Applicable Integrated Plans. It tracks reductions, suspensions, and terminations of integrated plan benefits.
2026 status: CMS has suspended collection of ODAG Table 6 (AIP) for the 2026 audit cycle. However, D-SNP plans should maintain the capability to produce this data, as CMS may reinstate the requirement in future audit years.
Even with the suspension, D-SNP plans should be tracking this data internally. The underlying regulatory requirements around integrated plan benefit decisions haven't changed — CMS is just not collecting the universe table during audits right now.
Cross-Table Issues: Where Everything Connects
Some of the most consequential validation problems aren't within individual tables — they're between them. CMS auditors look at the ODAG universe as an integrated set of data, not six isolated files.
OD → RECON Consistency
Every case in the RECON table should have a corresponding denied or partially denied OD in Table 1. If a reconsideration appears with no matching OD, it suggests cases are missing from one table or the other.
Favorable Decisions → EFF_C
Every favorable or partially favorable outcome in OD, RECON, or PYMT_C should have a corresponding effectuation record. Plans that show 200 favorable decisions but only 150 effectuation records have a completeness problem.
Member ID Consistency
The same member's MBI must be consistent across all tables. If your OD table uses one MBI format and your claims-sourced PYMT_C table uses another, CMS can't link cases across tables. This is especially common when data comes from different source systems.
Date Range Alignment
All tables must cover the same audit review period. We've seen plans submit an OD table covering January–December but a PYMT_C table that only has data through November because the claims extract ran on a different schedule. CMS will flag this.
Data Quality Fundamentals That Apply to Every Table
Regardless of which ODAG table you're working with, certain data quality issues trigger IDS findings across the board:
Format Issues
- •Dates not in CCYY/MM/DD format
- •MBI not matching 11-character structure
- •Column headers not matching CMS spec exactly
- •Extra columns or missing required columns
Hidden Characters
- •Leading/trailing spaces in field values
- •Tab characters from copy-paste operations
- •Line feeds or carriage returns within cells
- •Non-breaking spaces from Word or PDF sources
Logical Errors
- •Decision date before receipt date
- •Notification date before decision date
- •Cases outside the audit review period
- •Future dates in historical data
Completeness
- •Required fields left blank
- •Missing data from delegated entities
- •“N/A” or “None” in fields that require actual values
- •Entire case types omitted (e.g., Part B drug requests)
Practical Takeaways
If you're responsible for ODAG universe file preparation, here's what matters most:
Know your source systems.
Map which system feeds each table. OD and RECON typically come from UM platforms. PYMT_C comes from claims. GRV_C may come from a CRM or member services system. Each mapping point is a potential failure point.
Validate before you need to.
Don't wait for an engagement letter. Run validation quarterly at minimum. The issues you find six months before audit are fixable. The ones you find during the 15-day submission window often aren't.
Check cross-table consistency.
Individual table validation is necessary but not sufficient. The six tables need to tell a consistent story. Favorable decisions need matching effectuations. Denied ODs with appeals need matching RECON records.
Don't forget your delegates.
If a TPA or vendor handles any part of your OD, appeals, payment, or grievance processing, their data is your data in the eyes of CMS. Build delegate data into your validation process from the start.
Pay attention to timeliness calculation details.
CMS evaluates timeliness at the universe level, not just a sample. Every case counts. Make sure you understand the specific timeliness standard for each case type in each table, including how extensions, weekends, and holidays factor in.
Validate All 6 ODAG Tables Before Submission
Our CMS Universe Scrubber validates every ODAG table against CMS specifications — field formats, timeliness calculations, cross-table consistency, and hidden character detection. Catch IDS-triggering errors before CMS does.