Risk Adjustment

RAPS vs EDPS (encounter data)

~9 min readBy Pelica Health teamPublished August 28, 2026Updated August 28, 2026Reviewed by Catherine Zhao

Short answer

RAPS and EDPS are the two systems Medicare Advantage organizations have used to send risk adjustment diagnoses to CMS. RAPS took an abbreviated record, five data elements per diagnosis cluster, and the plan decided in advance which diagnoses to send. EDPS takes the whole encounter in the X12 837 format, the same way a claim is filed, and CMS decides what qualifies. CMS blended the two from 2016 through 2021 and has calculated Part C risk scores entirely from encounter data and fee-for-service claims since payment year 2022.

What RAPS was

The Risk Adjustment Processing System took a stripped-down record. For each diagnosis a plan wanted counted, it sent a diagnosis cluster of five data elements: the beneficiary's health insurance claim number, the provider type, the from date, the through date, and the ICD diagnosis code. Nothing else. No procedure codes, no rendering provider, no dollars, no place of service.

That design put the plan in charge of filtering. A plan looked at its own claims, decided which diagnoses came from a risk-adjustment-eligible source, and submitted only those. CMS received a curated list and largely took it as given.

Data elements in a RAPS diagnosis cluster: HIC number, provider type, from date, through date, diagnosis code.

100%

Share of the Part C risk score CMS has calculated from encounter data and FFS claims since payment year 2022.

Feb 1, 2027

PY2026 final submission deadline. After a final deadline CMS processes deletes only.

What EDPS is

The Encounter Data System takes the full encounter. Plans submit in the HIPAA 5010 X12 837 professional or institutional format, the same transaction a provider uses to bill a claim, with hundreds of data elements instead of five. CMS announced the move in 2012 and started collecting encounter data alongside RAPS.

Two names get used interchangeably and it helps to keep them apart. EDS is the whole system. EDPS is the back-end processing engine that edits, prices, and stores what the front end accepted. In practice most operators say EDPS for both.

The important change is not the format. It is who filters. Under EDPS the plan sends everything and CMS applies the risk adjustment filtering logic itself, then reports the result back on the MAO-004. Submitted and recognized became two different numbers, and reconciling them became a permanent job.

The phase-in, year by year

CMS did not flip a switch. It blended encounter-based and RAPS-based risk scores over six payment years, and the share moved backward once, in 2018, when CMS finalized 15 percent after proposing more.

Payment year	Encounter data share	RAPS share	Note
2016	10%	90%	First year of blending
2017	25%	75%
2018	15%	85%	CMS finalized a lower share than proposed
2019	25%	75%	RAPS inpatient diagnoses supplemented the encounter side
2020	50%	50%	Encounter side used the 2020 CMS-HCC model, RAPS side the 2017 model
2021	75%	25%
2022	100%	0%	Part C risk scores from encounter data and FFS claims only

By the 2022 rate announcement CMS was explicit: with the 2020 CMS-HCC model fully phased in, the Part C risk score used for payment relies entirely on MA encounter data and fee-for-service claims as the sources of diagnoses. RAPS inpatient records, which had propped up the encounter-based score in 2019 and 2020, were dropped.

One piece of housekeeping trails the policy. CMS submission deadline memos still name RAPS data alongside EDS data, and CMS told plans in a February 2023 report change that RAPS data were no longer required to calculate risk scores. If your operating documents still describe a dual submission process, they are describing 2021.

Where the two worlds differ

	RAPS	EDPS
What you send	A diagnosis cluster: five data elements	A full 837 professional or institutional encounter
Format	CMS proprietary flat file	HIPAA 5010 X12 837
Who decides eligibility	The plan, before submitting	CMS, by applying filtering logic after submission
Front-end responses	RAPS return file with error codes	TA1, 999, and 277CA
Back-end responses	None	MAO-001 duplicates, MAO-002 processing status, MAO-004 diagnosis filtering
Answer to "did the diagnosis land?"	The RAPS return file accepted the cluster	The MAO-004 lists it as risk-adjustment eligible
Data volume per diagnosis	Five fields	Hundreds of fields
Status today	Not used to calculate risk scores	The sole plan-submitted source

"Did the diagnosis land?" is a different question now

Under RAPS the answer was close to binary. You sent a cluster, the return file accepted or rejected it, and an accepted cluster meant an accepted diagnosis, because you had already done the filtering.

Under EDPS the same question takes four files and two systems. The encounter has to clear the front end, which means a clean 999 and an acceptance on the 277CA. Then it has to clear the back end, which is where the MAO-002 reports encounter and service-line status and the MAO-001 flags duplicates against what CMS already stored. Only then does the MAO-004 say whether each diagnosis on that accepted encounter is eligible for risk adjustment.

Every one of those checkpoints can drop a diagnosis on its own. An encounter can clear the 277CA cleanly and still have half its diagnoses filtered on the MAO-004. That is the operational cost of moving filtering from the plan to CMS, and it is why a plan that reconciles on submitted diagnoses rather than recognized ones consistently overstates its own risk score.

Deadlines and sweeps

Encounter data only counts if CMS accepts it before the submission deadline for the payment year in question. CMS runs three scores per payment year and publishes the deadlines in an HPMS memo.

Initial run. Dates of service from July 1 through June 30 of the following year, deadline the following September, paid the January after that. The PY2027 initial run covers July 1, 2025 through June 30, 2026 with a deadline of September 4, 2026.
Mid-year run. A full calendar year of dates of service, deadline the following March.
Final reconciliation run. The same calendar year, deadline roughly a year later. PY2026 final closes February 1, 2027.

Data submitted after 8 p.m. ET on a deadline is not in that run. Data submitted between runs falls into the next one. The final deadline is the one that is genuinely final: under 42 CFR 422.310(g) CMS will not make additional payments for diagnoses received after it, and processes deletes only. A correction filed late can lower a risk score. It can no longer raise one.

Common mistakes after the transition

Reporting on submitted RAF instead of recognized RAF. The submitted number is what you sent. The MAO-004 number is what CMS will pay on, and the gap between them is the actual work queue.
Filtering before submission, out of RAPS habit. Under EDPS, holding back encounters you assume CMS will reject just removes your own chance to see the reject code and fix the source.
Stopping at the 277CA. Acceptance into the encounter system is not risk-adjustment eligibility.
Treating chart review records like an independent channel. Chart review records ride the same acknowledgment chain, get the same filtering, and appear on the same MAO-002 and MAO-004 as everything else.
Reconciling annually. A rejection found after the final deadline is not recoverable, no matter how well documented the chart is.

How Pelica handles encounter submissions

Pelica's Risk Adjustment Copilot keeps one record per diagnosis and follows it the whole way: submitted, acknowledged on the 277CA, processed on the MAO-002, filtered on the MAO-004, then priced on the MMR and detailed on the MOR. Recognized RAF is the number the copilot reports, not submitted RAF, and every open rejection carries the deadline it has to beat. Plans and IPAs run this across 350,000+ members, and a new deployment is live in two weeks.

Related terms

277CA is the front-end acknowledgment that tells you an encounter was accepted into the system at all. MAO-004 is the file that decides which diagnoses on that encounter are risk-adjustment eligible. RAF covers how accepted diagnoses become a risk score, and V28 covers the model those diagnoses are scored against.

Sources

Frequently asked questions

Common questions about RAPS, encounter data submissions, and how the transition changed risk adjustment operations.

What is the difference between RAPS and EDPS?

RAPS accepted an abbreviated diagnosis cluster of five data elements: the beneficiary's health insurance claim number, provider type, from date, through date, and diagnosis code. EDPS accepts the full encounter in the X12 837 format, the same transaction used to bill a claim, with hundreds of data elements. The deeper difference is who filters. Under RAPS the plan decided which diagnoses were risk-adjustment eligible before submitting. Under EDPS the plan submits everything and CMS applies the filtering logic, then reports the result on the MAO-004.

Does CMS still use RAPS data for risk scores?

No. CMS phased encounter data into risk scores from 2016 through 2021 and has calculated Part C risk scores entirely from encounter data and fee-for-service claims since payment year 2022, when the 2020 CMS-HCC model was fully phased in. CMS told plans in a February 2023 reporting change that RAPS data were no longer required to calculate risk scores, though CMS submission deadline memos still name RAPS alongside encounter data.

What are the five RAPS data elements?

A RAPS diagnosis cluster carried the beneficiary's health insurance claim (HIC) number, the provider type, the from date of service, the through date of service, and the ICD diagnosis code. There were no procedure codes, no rendering provider, no dollar amounts, and no place of service, which is why plans had to decide eligibility themselves before submitting.

How do you know a diagnosis was accepted under EDPS?

It takes four files. The 999 confirms the submission file was well formed. The 277CA confirms the encounter was accepted into the encounter system rather than rejected at pre-adjudication. The MAO-002 reports encounter and service-line processing status on the back end. The MAO-004 is the one that says whether each diagnosis on an accepted encounter is eligible for risk adjustment. An encounter can clear the 277CA and still have diagnoses filtered out on the MAO-004.

Why did CMS move from RAPS to encounter data?

RAPS gave CMS only what plans chose to send: five fields per diagnosis, filtered by the plan. Encounter data gives CMS the complete 837 record, which lets CMS apply its own risk adjustment filtering logic, compare Medicare Advantage utilization against fee-for-service, and audit what supports a diagnosis. CMS announced the move to the 5010 X12 837 format in 2012 and collected both systems in parallel during the phase-in.

What is the deadline for submitting risk adjustment data?

CMS runs three risk score calculations per payment year and publishes the deadlines in an HPMS memo. The PY2027 initial run covers dates of service from July 1, 2025 through June 30, 2026 with a submission deadline of September 4, 2026. The PY2026 final reconciliation run closes February 1, 2027. All deadlines are 8 p.m. ET. After a final deadline, 42 CFR 422.310(g) bars additional payment for diagnoses received late, and CMS processes deletes only.

Submitted RAF and recognized RAF are two different numbers.

Pelica follows every diagnosis from submission through the 277CA, MAO-002, and MAO-004 to the MMR, reports the recognized number, and puts the submission deadline on every open rejection. Plans and IPAs run it across 350,000+ members.

Book a Demo → See the Risk Adjustment copilot