What CMS actually looks for in a network adequacy filing.

CMS network adequacy review is not a checkbox exercise. Reviewers are looking at actual provider files, running their own time-and-distance calculations, and comparing your submission against their internal provider databases. Plans that submit without understanding the review criteria get requests for information. Plans that get too many RFIs miss deadlines.

The organizations that navigate the review cleanly have done one thing consistently: they have run their own analysis against CMS standards before submitting, not after. They know where their gaps are. They have documented exceptions. Their provider data is clean. The review is still a review — but it's not a discovery process.

Here is what the submission actually contains and what reviewers look for in each piece.

What's in a network adequacy submission

CMS requires specific data elements for each component of the submission. Incomplete files are rejected or flagged immediately. The required elements:

• Provider file. National Provider Identifier (NPI), provider name, specialty taxonomy code, practice address, phone number, accepting-new-patients flag, in-network status, and contract effective date for every in-network provider. This file is machine-readable — CMS runs automated checks against it. Format matters.
• Time-and-distance analysis by county and specialty. Driving time and straight-line distance to the nearest in-network provider, calculated for each required specialty type, in each county within your service area. CMS publishes the applicable specialty types and the threshold standards — both the driving time standard and the straight-line standard must be met.
• Adequacy attestation. A signed declaration from an authorized organizational representative — typically the CEO or COO — affirming that the network meets applicable standards. This is a legal attestation. The person signing it is personally attesting to the accuracy of the submission.
• County-level exception requests with supporting documentation. For any county and specialty combination where you cannot meet CMS standards, you must request an exception and document why.

What CMS reviews — and what triggers RFIs

CMS reviewers have access to NPPES (the National Plan and Provider Enumeration System) and other federal provider databases. Every NPI in your submission gets cross-referenced. The most common RFI triggers:

NPI validation failures. Inactive NPIs, NPIs that don't match the specialty taxonomy you filed, practice addresses that differ significantly from what NPPES shows — all of these flag. Before you submit, run every NPI in your provider file against the NPPES database and reconcile discrepancies. This is manual work, but it is the single most reliable way to avoid NPI-related RFIs.

Provider counts below adequacy thresholds. CMS publishes minimum provider-to-enrollee ratios by specialty type. If your county-level provider counts fall below those thresholds, you need a documented exception — not just a note in the filing. If CMS can count your in-network providers in a county and determine you're below the standard, they will.

Time-and-distance calculation discrepancies. CMS uses its own methodology and its own mapping tools to run time-and-distance calculations. If your numbers differ significantly from CMS's own calculations, expect a request for methodology explanation. Use the same county-level geographic centroids and driving-time methodology that CMS publishes. Don't use straight-line distance as a proxy for driving time — CMS applies both standards and they're not interchangeable.

Accepting-new-patients status. Providers flagged as not accepting new patients do not count toward adequacy for most specialty types. This matters a great deal in markets where established PCPs have closed panels. A provider in your network who isn't accepting new patients is, from an adequacy standpoint, not in your network for purposes of counting.

Contract dates that haven't taken effect. Providers whose contracts are executed but not yet effective at the submission date don't count. If you have a provider whose contract effective date is after your submission date, they are not in your network for adequacy purposes until that date arrives. Plan credentialing timelines accordingly.

Exception documentation

CMS allows exceptions for rural counties and certain specialty shortage areas. Exceptions are legitimate tools — they exist because some markets genuinely cannot support full adequacy — but they require specific documentation.

An acceptable exception file includes: dated records of good-faith outreach to providers who declined participation or didn't respond, a clear explanation of why the adequacy gap exists (shortage area designation, insufficient provider supply, etc.), and a corrective action plan with specific dates for how you intend to reach adequacy.

Exceptions are not guaranteed. CMS can reject an exception and require you to re-file or revise the network. The corrective action plan dates are taken seriously — if you commit to achieving adequacy for a specialty in a rural county by a specific date, CMS will follow up on that commitment.

One practical note on exception documentation: the outreach records need to be dated and specific. A general statement that "we attempted to recruit orthopedic surgeons in County X" is not sufficient. CMS wants to see that you reached out to identifiable providers, on specific dates, and what the outcome of each outreach effort was. Build the exception documentation as you go — recreating it at submission time from memory is much harder.

Every NPI in your submission is a data point CMS can check. Submit clean data or plan for an RFI.

Run your own adequacy analysis against CMS thresholds before you submit — not after. The time to find gaps is during the build, when you have weeks to address them, not at the submission deadline when you have days. Every network build we run includes monthly adequacy analysis from the first week of contracting. The goal is to arrive at submission with no surprises — and with exception documentation that's already written, dated, and organized.