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 has five active 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. (A sixth table, AIP, covered Dual SNP benefit reductions but has been deprecated by CMS and is no longer collected.)
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.
Key Takeaways
- •ODAG has five active universe tables: OD, RECON, PYMT_C, EFF_C, and GRV_C. A sixth table, AIP, has been deprecated by CMS and is no longer collected.
- •CMS counts timeliness from when a request is received from any source, not when it reaches the responsible department, and evaluates it at the universe level: every case, not a sample.
- •The most consequential validation problems are cross-table: favorable decisions without matching effectuations, RECON cases without a parent OD, and inconsistent MBIs across source systems.
- •Delegated entity data is your data in the eyes of CMS. Missing TPA and vendor cases are one of the most common completeness failures.
- •Validate quarterly, not when the engagement letter arrives. Issues found during the 15-business-day submission window often cannot be fixed in time.
How the Five 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.
Tables 1–4 follow a case from initial request through resolution. Table 5 covers a separate complaint process. 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, 72 hours 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.
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 five 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.
Frequently Asked Questions
What is the ODAG universe in a CMS program audit?
ODAG stands for Organization Determinations, Appeals, and Grievances, the Part C protocol in a CMS Program Audit. The ODAG universe is a set of structured data files listing every organization determination, reconsideration, payment request, effectuation, and grievance the plan handled during the audit review period. CMS validates the files, tests timeliness at the universe level, and samples cases from them to review how real members were handled.
What are the five ODAG universe tables?
The five active tables are OD (organization determinations), RECON (reconsiderations), PYMT_C (payment/claims determinations), EFF_C (effectuations), and GRV_C (grievances). A sixth table, AIP, covered Dual SNP benefit reductions but has been deprecated by CMS and is no longer collected.
What are the key ODAG timeliness standards?
Standard pre-service organization determinations are due within 14 calendar days of receipt and expedited requests within 72 hours. Part B drug requests are due within 72 hours standard or 24 hours expedited. Standard reconsiderations are due within 30 calendar days and expedited reconsiderations within 72 hours. Grievances are due within 30 days, with a 24-hour window for expedited quality of care grievances. CMS counts timeliness from when a request is received from any source, not from when it reaches the responsible department.
What ODAG errors trigger IDS findings?
The most common triggers are missing time stamps on expedited cases, dates not in CCYY/MM/DD format, MBIs that do not match the 11-character structure, column headers that deviate from the CMS record layout, logical errors such as a decision date before the receipt date, and completeness gaps such as missing delegated entity cases. If the files still fail integrity testing after three submission attempts, CMS cites an Invalid Data Submission finding for each element it could not test.
Does delegated entity data belong in the ODAG universe?
Yes. If a TPA or other vendor processes any part of the plan’s organization determinations, appeals, payment requests, or grievances, those cases must appear in the universe, and CMS holds the plan accountable for their accuracy. Missing delegate data is one of the most common completeness failures.
Validate All 5 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.