When you can't meet adequacy: CMS exceptions, explained
You have a service area you want to enter, a filing deadline bearing down, and a map that stubbornly refuses to cooperate. In one county the specialists you need are already locked up by a competitor. In another, the only cardiologist within the time and distance standard retired last year. You know the network is thin in a few spots, and you are staring at the CMS network adequacy exception request, wondering whether it is your escape hatch.
It can be. But an exception is a narrow door, and CMS built it that way on purpose. If you walk in treating exceptions as a shortcut around a hard build, you will lose the request, the market, or both. Treated correctly, the exception is a precise instrument for the handful of counties where the providers genuinely are not there to contract. This is how it works, when CMS grants it, and how to keep it in its place as a last resort inside a real build.
What a network adequacy exception actually is
Medicare Advantage organizations must demonstrate that their contracted network meets CMS network adequacy criteria before they can enter or expand a service area. Those criteria are codified at 42 CFR 422.116, and they are enforced through two mechanical tests. First, the time and distance standard: for each measured specialty, at least 90 percent of the beneficiaries in a given county must be able to reach at least one contracted provider or facility of that type within a published maximum travel time and distance. Second, a minimum-number standard for how many of each specialty you must contract. CMS varies both by county type, from large metro to counties designated as extreme access, because a standard that fits Manhattan cannot fit rural Montana.
You prove all of this by uploading Health Service Delivery (HSD) tables into the Network Management Module of the Health Plan Management System (HPMS), where CMS runs an automated review against reference files. You submit two tables: one for contracted providers, covering the provider specialty types CMS measures, and one for contracted facilities, covering the facility specialty types. Only providers and facilities with a fully executed contract belong on those tables.
A network adequacy exception request is what you file when your network cannot pass the automated test for a specific specialty in a specific county, and you believe there is a legitimate reason CMS should approve the network anyway. It is not a waiver of the standard. It is a request to CMS to accept your network as adequate despite a gap, on the strength of evidence that the gap reflects the real health care market, not a gap in your effort.
The three-part test CMS applies
CMS does not grant exceptions on sympathy. It applies a structured test, and a request that does not speak to all three parts is a request that fails. To approve an exception, CMS looks for the following.
- The current access to providers and facilities is different from what the HSD reference file and provider supply data assume. In plain terms: the providers CMS thinks are available in that county are not actually available to contract, or do not exist in the numbers the reference file expects.
- Other factors demonstrate that beneficiary access under your network is consistent with or better than the original Medicare pattern of care in that area. This is the heart of it. CMS wants to see that Original Medicare beneficiaries in that county already travel the same distances, cross the same county lines, or use the same referral pathways your network relies on.
- Approving the exception is in the best interests of beneficiaries. The network you are proposing, gap and all, must still serve members well and not leave them stranded.
The patterns that actually win exceptions
Underneath that three-part test, requests tend to fall into recognizable fact patterns. Knowing which pattern you are in tells you what evidence to gather.
The first is no providers available. The specialty simply does not practice in that county, or the few who do are so few that no plan could meet the standard. This is common in extreme-access and rural counties. Here your argument is that CMS's own pattern-of-care data will show Original Medicare beneficiaries leaving the county for that service, and your network mirrors that reality.
The second is providers exist but are unusable. A provider is present in the county but cannot be counted. They may refuse to contract with any Medicare Advantage plan, be exclusively contracted to a competitor, have closed their panel, not actually deliver the measured service despite their taxonomy, or be retired or deceased while still appearing in a reference file. The unusable-provider pattern is where good documentation matters most, because CMS's reference file will show the provider as available and you have to affirmatively rebut it.
The third is a pattern-of-care argument. Even where the automated test fails, you show that access under your network matches how care is actually delivered and consumed in that region under Original Medicare. Referral flows cross county lines, a regional center of excellence draws the whole area, and your contracted network follows those same real-world pathways.
How to document and justify the request
An exception request is a persuasive document backed by evidence, and CMS reviewers see a great many weak ones. The winning requests share a structure.
Start by naming the exact county and specialty type and stating the specific standard you cannot meet. Vagueness reads as evasion. Then rebut the reference file directly. If your argument is that providers are unusable, list them by name and NPI and give the concrete reason each cannot be counted: panel closed as of a date, exclusive to a named competitor, service not actually rendered, retired, deceased. Attach the proof of your contracting effort. Reviewers want to see that you tried and were refused, not that you filed an exception instead of picking up the phone.
Next, make the pattern-of-care argument with data, not adjectives. Where do Original Medicare beneficiaries in that county actually go for this service? If they already travel to the adjacent county, and your network contracts the provider they travel to, you are asking CMS to accept a network that matches reality. Close by tying it back to the beneficiary's best interest: describe the access members will have, the travel involved, and any supports you are putting in place.
- The precise county, specialty type, and standard at issue
- A named, NPI-level rebuttal of the providers CMS's reference file counts as available
- Evidence of genuine contracting outreach and the responses you received
- Pattern-of-care data showing how Original Medicare beneficiaries obtain the service today
- A clear statement of the resulting member access and why it serves their interests
Timing, rounds, and the moving deadline
Network adequacy is not a one-time gate; it is a review that happens on CMS's calendar, and the exception process rides on that calendar. Historically, exception requests were confined to a limited window tied to the application and HSD submission cycle, which meant a late-discovered gap could cost you a full year. CMS has been widening that window: for the CY2027 contract year, exception requests may be submitted during all of the HSD review rounds rather than a single narrow slot.
That is a meaningful improvement, but do not let it lull you. More rounds to file in is not more time to build a network. The reference files, the standards, and the specialty definitions change year over year. CMS added Outpatient Behavioral Health as a facility specialty type in the CY2025 Final Rule, which means a county that passed one year can fail the next because the yardstick moved. Treat the exception window as a safety net for genuine gaps, not as float in your project plan.
Why exceptions belong at the end of the build, not the start
Here is the strategic point that matters more than any procedural detail. An approved exception does not build you a network. It tells CMS your network is acceptable despite a hole. The member in that county still faces the gap. If your growth plan quietly depends on exceptions to clear a swath of counties, you have not solved your access problem; you have deferred it, and you have concentrated regulatory risk on the counties you understand least.
There is also the matter of the review itself. Every exception is a subjective judgment by a CMS reviewer, and a network built to lean on many of them is a network built on outcomes you do not control. Compare that to a network where you have contracted the providers who are actually there. That network passes the automated test, needs no reviewer's blessing, and gives your members real access. The exception is what you file for the two or three counties where, after a genuine build, the providers simply are not there to contract.
How we approach it
We treat the exception request as the last five percent of a network build, never the first. That means we run the county-by-county HSD analysis early, so you know precisely where you pass, where you are close, and where the market cannot support the standard, long before a deadline forces the question. In the close-but-failing counties, we contract, because most apparent gaps close with focused outreach to the providers who are already there.
In the counties that genuinely cannot support the standard, we build the exception request the way CMS wants to read it: the named providers, the rebutted reference file, the documented outreach, and the pattern-of-care data that shows your network matches how Original Medicare beneficiaries in that county already get their care. Done this way, the exception stops being a gamble and becomes what it was designed to be: a precise tool for the handful of places where the map, not your effort, ran out.
Ready to start?
Two weeks. A build plan worth running.
Fixed fee, no commitment past the diagnostic. You walk out with a plan — whether you run it with us or not.
Schedule the diagnostic