MAO-004 for the coder
The list of what was documented and did not count, with reasons. Worked monthly, it turns a vague sense that conditions are leaking into a short list of provider types, service types, and encounter formats to fix.
Guide · Data
Medicare Advantage payer files, explained: what the MAO-004, MOR, and MMR contain, and what the plan sends on top.
A working guide for data stewards, analysts, and practice administrators: the three CMS files that turn a documented diagnosis into a paid risk score, the files the health plan adds on top of them, when each one arrives, which question each one answers, and where the data breaks between them.
By Jonan Portal Alvarez, Chief Executive Officer, Alara Healthcare (management services) · Updated September 10, 2026 · About 10 minutes
Start here
How a diagnosis becomes money
Every payer file is an answer to one question in this chain. Knowing which question is the whole trick.
- 1
A clinician documents a condition in a visit
The diagnosis goes on the claim or encounter with the date of service, the provider, and the place of service. Nothing in the chain can repair what is missing here.
- 2
The plan submits the encounter to CMS
Medicare Advantage organizations send encounters to the Encounter Data System. The practice never touches this step, but everything downstream depends on it happening, and on time.
- 3
CMS says whether the encounter was accepted
The MAO-002 processing status report comes back with each encounter accepted or rejected and the error codes for the rejects. A rejected encounter carries no diagnoses anywhere.
- 4
CMS says whether each diagnosis counts
The MAO-004 encounter data diagnosis report lists every diagnosis pulled from accepted encounters and flags it allowed or disallowed for risk adjustment, with the reason. This is where a documented condition quietly stops counting.
- 5
CMS runs the model and credits conditions
Three times per payment year the risk adjustment system scores every member. The Model Output Report, the MOR, lists the conditions CMS credited after hierarchies, with the demographic pieces of the score.
- 6
CMS pays the plan, and the plan pays you
The Monthly Membership Report, the MMR, carries each member's risk score and what CMS paid for the month, with adjustment records whenever a past month changes. Under a risk contract, your capitation or surplus is calculated from this file, one way or another.
The CMS files
The three files CMS produces
| File | Who sends it, how often | What it contains | The question it answers | What to watch |
|---|---|---|---|---|
| MAO-004, the encounter data diagnosis report | CMS to the plan, monthly, as encounters are processed. Reaches the practice through the plan. | One row per diagnosis per accepted encounter: the encounter reference, the dates of service, the provider type, the diagnosis code, and an allowed or disallowed flag with the reason. Chart review additions and deletions appear here too. | Did the diagnosis we documented count for risk adjustment? | Disallowed reasons cluster: an ineligible provider type, a service that is not face-to-face, a deleted chart review. Each cluster is a process to fix, not a code to resubmit. |
| MOR, the model output report | CMS to the plan, monthly, reflecting the latest model run: initial, mid-year, or final. Separate reports for the Part C and Part D models. | One row per member per run: the model segment used, the demographic factors, the disease interactions, and a flag for every condition category CMS credited after hierarchies were applied. | Which conditions does CMS think this member has, for this payment year? | It is credited conditions, not documented ones. A condition you documented can be absent because it was disallowed, submitted late, or trumped by a more severe condition in the same hierarchy. Last year's MOR is this year's recapture denominator. |
| MMR, the monthly membership report | CMS to the plan, monthly. Under a risk contract the practice or MSO usually receives it, or a plan-built statement derived from it. | One row per member per month plus adjustment rows: enrollment dates, the risk factor type that names the model segment, the Part A and Part B risk scores, the Part D score, Medicaid, institutional, hospice, and end-stage renal disease flags, and the payment amounts, with reason codes for every adjustment. | What was this member worth this month, and why did last month change? | Adjustment rows restate past months. Summing without netting them double counts, and a member who left keeps producing rows until the retroactive termination clears. |
MOR for the analyst
The answer key for the year: the conditions CMS credited, member by member. Compared with your documentation it shows what CMS knows that you did not document, which is usually an outside provider, and what you documented that CMS never credited, which sends you back to the MAO-004.
MMR for the administrator
The money, and the reason it moved. Every risk score change, retroactive enrollment, and status flag shows up here as a payment adjustment with a reason code. The financial summary a practice trusts is one that reconciles to this file.
The plan's files
What the plan sends on top
The CMS files describe money and credited conditions. They do not say who your patients are, what care happened, or what is still missing. The plan's own files do that, in layouts the plan chooses, on schedules the plan keeps, and they are where most of the day-to-day work lives.
| File | What it is | Cadence and lag | What it feeds | What breaks |
|---|---|---|---|---|
| Enrollment roster and attribution file | Who is enrolled and which provider each member is assigned to, with the plan's member identifier, effective dates, and the product. | Monthly. Departures are learned one roster late. | The panel. Every per-member figure on the platform starts here. | Working from the scheduling system's patient list instead of the roster, and plan member identifiers that do not match the Medicare identifier on the CMS files. |
| Claims extracts: professional, institutional, pharmacy | Paid and denied claims for the attributed members, with diagnoses, procedures, providers, places of service, and amounts. | Monthly or weekly, with a lag of weeks to months as claims are adjudicated. Pharmacy runs faster than medical. | Utilization and cost, quality numerators, suspects, outside-provider closures. | Reading a low count for last month as low utilization when it is claims that have not landed, and layouts that change without notice. |
| Quality gap files | For each member and measure, what the plan's data says is not yet compliant. | Monthly or quarterly, as of the plan's last load. | The HEDIS workbench and the Stars scoreboard. | Re-sending a gap the plan is still reconciling, and gap counts compared across files that use different measure sets. |
| Risk gap and suspect files | The plan's own view of conditions to recapture and conditions it suspects, sometimes with evidence, sometimes with only a code. | Monthly to quarterly. | One input to the gap list, ranked with your own evidence beside it. | Treating the plan's suspect as a finding. The plan's list and yours will differ, and the clinician decides. |
| Year-end risk report | The plan's summary of each member's risk score and credited conditions for the payment year, usually derived from the MOR. | Annually, after the final run. | The baseline for next year's recapture denominator when the MOR itself is not shared. | Treating it as the MOR. It is a plan-built summary, and its date and model run should be stated on the file. |
| Financial statements | Capitation or funding statements, medical expense reports with an incurred-but-not-reported estimate, and settlement or surplus statements. | Monthly or quarterly, on the contract's schedule. | The profit and loss and the loss ratios. | Two loss ratios read on one scale, and a statement that does not reconcile to the MMR. |
Lab results, vitals, and EHR encounter extracts come from clinical systems rather than the plan, on their own schedules, and feed the quality measures and the suspects. What Data Management does with all of them
The calendar
When each file arrives, and what period it is about
More questions that begin with this number looks wrong end up being this question: which stretch of the calendar is the figure about?
Every month
The MMR, the MOR reflecting the latest run, the MAO-004 for encounters processed since the last one, the roster, and a claims extract. The month they describe is not the month they arrive: a January MMR is about January, a January claims file is mostly about November and December.
Before the payment year starts
The initial model run scores every member on diagnoses from the middle of the prior year back. The MOR from this run is the first answer key for the year, and the January MMR pays on it.
Mid-year
The mid-year run rescores on a full prior calendar year of diagnoses. Risk scores move, the MMR carries adjustment rows for the months already paid, and the MOR changes under you without anything about the member changing.
After the following January
The final run closes the payment year once the last submission deadline passes. Final adjustments land on the MMR months later. Only now is the year's revenue actually the year's revenue.
Quarterly and annually
Financial statements on the contract's schedule, the year-end risk report after the final run, and the plan's gap files on whatever cadence the contract names. The delivery calendar is the only place a missing file can be noticed, because nothing is late if nothing was expected.
The honest part
Where the data breaks
Six failures account for most of the bad numbers. None of them is a payer error, and all of them are visible if someone is looking.
Adjustment rows counted twice
The MMR restates past months when anything changes. A revenue figure built by summing rows without netting the adjustments overstates the year, and it is the most common reason a practice's number and the plan's settlement disagree.
The MOR read as the chart
The MOR is what CMS credited, after filtering and hierarchies. Using it as the list of what the member has misses conditions that were documented and disallowed, and it credits outside providers whose work you cannot rely on next year.
Identifiers that do not match
The CMS files use the Medicare beneficiary identifier. The roster uses the plan's member number. Claims use both, or neither. Names and birth dates arrive with different spellings, and the same person becomes two members until someone resolves them.
A layout that changed without notice
A payer adds, renames, or drops a column, and a pipeline that guesses loads the wrong data into the right field. The correct response is to stop and ask, and to version the layout so both shapes are understood.
A file that arrived but was not read
A file in the inbox has been seen, not read. Half of a delivery can load and the other half fail on a bad row, and the completion share stops moving. Arrival, readability, and correctness fail independently and need separate checks.
Periods mixed in one comparison
A gap count as of the plan's last load against a claims file two months behind, or a mid-year MOR against last year's final. Before treating a difference as an error, check that the two figures are about the same stretch of calendar. They usually are not.
Tools versus operations
Three questions, asked separately
Every figure on every screen depends on the same three questions, and they fail independently: did the file arrive, was it readable, and is what it says correct. A practice that asks them as one question finds out about problems at reconciliation. A practice that asks them separately finds out the morning after the delivery.
What Data Management does
- Shows every file the moment it lands, with duplicate detection and a batch history, so arrival is proven rather than assumed.
- Versions each file type and stops to ask when a payer changes a layout, with a two-panel mapping editor and sample values instead of a guess.
- Reports what was read, row by row, and what failed, so a stuck completion share is diagnosed rather than waited on.
- Grades correctness with a continuous check engine, an A to F report card, freshness against each source's promise, and identity resolution that queues ambiguous pairs for a human decision.
- Keeps the delivery calendar of what each source owes, and the contract terms the financial figures are scored against.
What it does not do
- Obtain the files. The MMR, the MOR, and the MAO-004 reach the practice only if the contract says they do. Ask for them by name.
- Fix a source that sends wrong data. It catches it, grades it, and names the steward. The steward still has to call the payer.
- Decide what a disallowed diagnosis should have been. That is a documentation and submission process, owned by people.
- Make two files about different periods agree. It labels the period on every figure so the reader can see they should not.
Onboarding is a configuration change, not a coding project: Alara Healthcare's data service sets up the sources, the file types, the column mappings, the locations, and the roles, and the first screens fill after the first full delivery. Data & EMR integration services
The people
Who owns which file
Data steward
Owns the sources: the delivery calendar, the file types, the layout changes, the identity decisions, and the grade. When a number is questioned, the steward says which file it came from and whether that file can be trusted.
Population health analyst
Reads the MOR against the documentation, builds the recapture denominator, reconciles the roster to the panel, and states the period on every figure that leaves the team.
Coder or documentation specialist
Works the MAO-004 disallowed list into process fixes, and confirms closures against what the plan accepted rather than what the chart says.
Practice administrator or MSO leader
Reconciles the financial statements to the MMR, keeps the contract terms current, and writes the file list into the next contract so the practice receives what it needs to manage the risk it holds.
Questions people ask
Questions about payer files
What is the difference between the MOR and the MMR?
The MOR is the model output report: which conditions CMS credited to each member for a payment year, after filtering and hierarchies, with the demographic pieces of the score. The MMR is the monthly membership report: each member's risk score and what CMS paid for the month, with adjustment rows when a past month changes. One explains the score. The other pays it.
Why is a condition we documented missing from the MOR?
Walk the chain backward. If the encounter was rejected, it is on the MAO-002 with an error code and never carried a diagnosis. If the encounter was accepted but the diagnosis was disallowed, the MAO-004 says why: an ineligible provider type, a service that was not face-to-face, a deleted chart review. If the diagnosis was allowed, it may have been submitted after the run, or trumped by a more severe condition in the same hierarchy, which is not a loss.
Do we receive these files directly from CMS?
No. CMS sends them to the Medicare Advantage organization. A practice or MSO under a risk contract receives them, or statements derived from them, through the plan, and only if the contract provides for it. Ask for the MMR, the MOR, and the MAO-004 by name when the contract is written or renewed. A plan-built summary is better than nothing and worse than the file.
Why do the member identifiers not match across files?
The CMS files carry the Medicare beneficiary identifier. The plan's roster and gap files carry the plan's own member number, and claims may carry either. Resolving the same person across them is identity resolution, and it has to be done before any per-member figure is trusted. The platform resolves most pairs on its own and queues the ambiguous ones for a decision.
Why did last month's payment change this month?
Because something about a past month changed: a risk score after a model run, a retroactive enrollment or termination, a Medicaid or institutional status flag. The MMR carries the change as an adjustment row with a reason code, and the year's revenue is only final months after the final run. A financial summary that cannot show the adjustment rows cannot explain the change.
How much lag should we expect on claims?
Weeks to months. Medical claims are adjudicated and extracted on the plan's cycle, so last month's utilization is incomplete for two or three months. Pharmacy runs faster. A low count for a recent month is claims that have not landed until proven otherwise, which is why every figure should say which period it is about.
What do we need to give Alara to start?
The files a risk contract already produces: the roster and eligibility, the gap files and the year-end risk report, the CMS files where the contract shares them, claims extracts, EHR encounter extracts, lab results and vitals, and the financial statements. Bring a sample layout of each to the demo. Onboarding is a configuration change: sources, file types, column mappings, locations, and roles.
Bring one month of files to the demo.
A roster, a claims extract, and the MOR if you have it. We will show where each one lands, what it feeds, and what the quality grade says about it.