Two Documents, Two Deadlines: Why Your ANOC Approval Workflow Shouldn't Match Your EOC Review

Every plan year, the same two documents move through the same approval chain, and one of them is being reviewed the wrong way.

The Annual Notice of Change and the Evidence of Coverage land in the production calendar together, carry the same plan data, and go to the same reviewers. Most teams route them identically. It is the obvious thing to do, and it is why the EOC review always runs late.

The regulation treats them separately. Medicare Advantage organizations must send the ANOC for enrollee receipt no later than September 30 each year, while the EOC is due to current enrollees by October 15. Those two deadlines sit in the same section of 42 CFR 422.2267, and are mirrored at 42 CFR 423.2267 for Part D sponsors.

Two delivery obligations mean two production tracks. What most workflows miss is that they are also two different review problems. An ANOC approval workflow asks whether the changes were captured correctly. An EOC review asks close to the opposite: whether anything changed that shouldn't have.

Medicare marketing and member communications teams that separate those questions finish the plan year with less rework and a cleaner record.

Table of Contents

• Why the ANOC and the EOC Are Two Different Review Problems
• How Plan-Year Review Effort Actually Multiplies
• What the Plan-Year Calendar Actually Requires
• Why File and Use Makes Your Internal Record the Compliance Artifact
• What the Approval Record Has to Show Afterward
• What ANOC and EOC Review Requires That General Approval Tools Don't Provide
• How Plan Teams Separate ANOC and EOC Review
• Is Your Plan-Year Document Review Ready?
• Frequently Asked Questions

At A Glance

Why the ANOC and the EOC Are Two Different Review Problems

An ANOC approval workflow is the internal process a health plan uses to draft, review, approve and document the Annual Notice of Change before submission and distribution; EOC document review and approval does the same for the Evidence of Coverage. Both sit ahead of any required submission and delivery, and both have to produce a defensible record. But the ANOC is a delta verification problem and the EOC is a change detection problem. Those tasks pull in opposite directions, so running both through one approval chain gives one of them the wrong kind of attention.

On the ANOC, nearly everything is new for the plan year. Premiums, cost sharing, benefit and network changes: the content is the change. Reviewers know what to look at, and the question is whether each change matches the underlying plan data and required language. The risk is a change missed, misstated, or applied to the wrong plan benefit package.

On the EOC the reverse holds. A long chaptered document carries forward largely intact, with a limited set of sections updated to reflect the same plan-year decisions. Nobody reads hundreds of pages closely at plan-year speed, so the question is which sections moved and whether anything moved that nobody authorized.

Ask a reviewer to read an EOC the way they read an ANOC and one of two things happens. They read everything and miss the deadline, or they read selectively and the selection goes undocumented.

The practical consequence: the ANOC needs routing by changed field, the EOC by changed section against the prior approved version. Those are different mechanics, not different settings.

How Plan-Year Review Effort Actually Multiplies

Plan-year review effort is the number of content variants multiplied by the number of review rounds, and most plans only count the first.

Variants. One cost-sharing change appears in the ANOC and in the relevant EOC chapter, both per plan benefit package, possibly in Spanish and other required languages, possibly varying by service area. Add the summary of benefits, the plan website and enrollment materials carrying the same figure, and one decision has propagated across dozens of assets that all have to agree with each other and with the plan data.

Rounds. The second multiplier is the one nobody budgets for. Compliance signs off on version one, marketing resolves the comments, and version two arrives. Unless the system can show compliance what moved since their review, the only safe option is to read the document again from the beginning. A document that takes three rounds to clear costs three reviews, not one review plus two spot checks, because each round restarts from an unknown state.

So plan-year review contains two different deltas and workflows usually track only one. What changed since last plan year is what the ANOC states and what an EOC review has to locate. What changed since a given reviewer last looked is a separate question, and it decides whether round two takes an hour or a week.

It compounds when a document leaves the process and comes back. Content sent out for legal or business input and returned as a new file has no relationship to the version compliance approved, so nothing can tell that reviewer which of their own resolved issues stayed resolved.

In Aproove's survey of 100 marketing leaders, 32% named adherence to state-specific regulation as their top operational challenge, and 21% said manual approvals are too slow for Annual Enrollment Period timelines.

What the Plan-Year Calendar Actually Requires

The plan-year calendar gives the ANOC and the EOC different end dates and gives the whole cycle a hard stop, which is why internal review time is the variable that gets squeezed.

Enrollees with an October 1, November 1 or December 1 effective date are handled differently: the ANOC must reach them within 10 calendar days of receipt of CMS confirmation of enrollment, or by the last day of the month before the effective date, whichever is later. Obligations vary by contract and plan type, so confirm what applies to your own contracts rather than working from a general calendar.

Two things follow. Treating the ANOC and the EOC as one deliverable forces the shorter deadline onto both. And delivery deadlines are receipt deadlines: production, print, fulfilment and mail time all sit inside them, so the internal review window closes well before the date in the regulation.

Why File and Use Makes Your Internal Record the Compliance Artifact

Under File and Use, the plan's own certification is what permits distribution, which makes the internal approval record the evidence behind that certification.

42 CFR 422.2261 sets out three routes by which marketing material may be distributed. CMS reviews and approves it. Or it is deemed approved, because CMS rendered no disposition within 45 days, or within 10 days for CMS model and standardized marketing materials. Or it is accepted under File and Use, where the organization may distribute certain designated material five days after submission, provided the organization certifies that the material meets all applicable CMS communications and marketing requirements. The HPMS Marketing Module is the system of record for materials submitted for review.

The implication is direct. Under File and Use, nobody outside the plan has examined the material before it goes out. The plan attested that it complies, and if that attestation is ever tested, the only thing standing behind it is the plan's own documentation of how the material was reviewed and by whom.

That reframes what an approval workflow is for. It is not overhead between the writers and the mail house. It is the compliance artifact.

What the Approval Record Has to Show Afterward

The questions asked about a plan-year document afterward are specific, and chronology does not answer them. Which version of the EOC chapter did compliance approve? Did the approved language reach the printed document? Who authorized the change that appeared after sign-off? An activity log shows that files moved and approvals were clicked. A decision record shows which version a reviewer saw, what had changed in it, on what authority they decided, and how their issues were resolved.

Delivery timing is monitored directly, and the deadline carries a penalty. In April 2014, CMS imposed a civil money penalty of $49,510 on Commonwealth Care Alliance after finding that 4,951 members had not received the 2014 combined ANOC/EOC by September 30, 2013. The notice describes the mechanism behind it: CMS runs an annual analysis of ANOC and EOC timeliness, with plans reporting actual mail dates in HPMS. That action dates from when the two documents were mailed together, and they are now delivered separately, but the dates are still reported. Among the marketing leaders Aproove surveyed, 27% called maintaining audit trails a persistent problem.

What ANOC and EOC Review Requires That General Approval Tools Don't Provide

The requirement most approval tools cannot meet is not review speed. It is producing the evidence as a byproduct of routing, rather than assembling it afterward.

The dependency runs in one direction. A tool that treats a document as a single file can route it, collect comments on it and stamp it approved, but it cannot route by section, because it has no sections. A system that cannot route by section cannot record by section either, so the evidence of what compliance actually examined has to be rebuilt later from comments and timestamps. That is why audit readiness resists being retrofitted, and why the record is the hard part rather than the reviewing.

How Plan Teams Separate ANOC and EOC Review

Plan teams that handle the plan year well build two approval chains rather than one, each matched to the question its document raises. This is a pattern seen across regulated customers rather than a single documented deployment.

Aproove supports that separation through atomic extraction, which breaks a document into structured components so each piece can be identified, compared, routed and recorded on its own rather than as an undifferentiated file. Two different review models then run on the same platform:

• Smart version comparison identifies what changed between any two versions in a document's lineage, including a reviewer's own last approved version rather than only the preceding one, so round two opens on what moved.
• Master file comparison compares a document against a prior approved master, which is what surfaces an unintended edit in a long EOC.
• Page-level smart review narrows review to the sections that moved, so reviewers are directed rather than trusted to sample.
• Decision-based workflow routing sends each changed component to the reviewer whose authority covers it, with different rules per document type.
• Layered access control keeps legal, compliance, brand and business reviewers in one document without seeing each other's remit.
• AI review agents pre-flag risk against the requirements the plan defines (required disclaimers, prohibited phrasing, benefit figures that should match plan data), so reviewers open a briefed document.
• Built-in auditability captures version, reviewer, authority and outcome as the decision is made.

Aproove supports the internal process of preparing, reviewing, approving and documenting plan-year content ahead of any required submission or distribution. Where AI is involved it operates inside defined workflow permissions and records: it flags language against the plan's own requirement set, summarizes what changed between versions and briefs reviewers. It does not clear content and it does not decide whether a risk is acceptable. The agent flags; the human decides. For where AI fits across a Medicare review cycle, see AI in Medicare marketing reviews.

Is Your Plan-Year Document Review Ready?

Work through these operationally rather than as a compliance checklist. They describe process maturity, not legal requirements.

• For any approved ANOC change, can you name the person who verified it against plan data and the version they verified?
• Does your EOC review identify changed sections against the prior approved master, or rely on reviewers knowing where to look?
• Are the ANOC and the EOC routed through separate workflows, with separate reviewers and separate deadlines?
• If a File and Use certification were questioned, could you show the review that supports it without reconstructing it?
• When a benefit figure changes, can you list every asset and variant that states it and confirm each one was reviewed?
• On a second-round review, can a reviewer see what changed since their own last approval, or do they start again?

Any question you cannot answer from a system is a question currently answered from memory.

Frequently Asked Questions

What is an ANOC approval workflow?
An ANOC approval workflow is the internal process a health plan uses to draft, review, approve and document the Annual Notice of Change before submission and distribution: content assembly from plan data, compliance and legal review, resolution of reviewer issues, final approval, and the record of how approval was reached.

When are the ANOC and the EOC due to members?
Under 42 CFR 422.2267, Medicare Advantage organizations must send the ANOC for enrollee receipt no later than September 30 each year, and provide the EOC to current enrollees by October 15 of the prior year. Parallel requirements for Part D sponsors appear at 42 CFR 423.2267. Different rules apply to enrollees with October 1, November 1 or December 1 effective dates, and obligations vary by contract and plan type. Confirm what applies to your own contracts.

Should the ANOC and the EOC use the same review process?
No. An ANOC review verifies that a known set of changes was captured accurately. An EOC review has to establish which sections of a long, largely stable document changed, and confirm that nothing changed without authorization. Those tasks need different routing and different evidence.

What does File and Use mean for internal approvals?
Under 42 CFR 422.2261, material accepted under File and Use may be distributed five days after submission, provided the organization certifies that it meets all applicable CMS communications and marketing requirements. Because the plan makes that certification itself, the plan's internal approval documentation is the evidence supporting it.

Why does compliance re-read the whole document on every round?
Because most systems can only show the difference against the immediately preceding version, not against the version that reviewer last approved. Without that, a reviewer cannot tell which of their own resolved issues stayed resolved, so re-reading is the only safe option. Review effort then scales with variants multiplied by rounds rather than variants alone.