Skip to main content
InsureLytix
Customers
Free readiness checkBook a demo
InsureLytix

Provider directory, FHIR Plan-Net, and network adequacy analytics for U.S. Medicare Advantage plans. CMS-compliant by default.

InsureLytix Inc. · Dover, Delaware

hello@insurelytix.com

Product

  • Provider search
  • FHIR Plan-Net API
  • Network gap analytics
  • All modules

Solutions

  • New & launching plans
  • Small & regional plans
  • Provider-led going payer
  • D-SNP plans
  • Medicare Advantage
  • All solutions

Resources

  • Compliance hub
  • Compliance readiness check
  • Customer stories
  • Blog
  • Network adequacy guide
  • FHIR Plan-Net checklist

Company

  • About
  • Contact
  • Security
  • Sign in

Legal

  • Privacy
  • Terms
  • Cookies
  • Accessibility
HIPAA-aligned CMS-0057-F FHIR R4 Plan-Net Section 508 / ADA
© 2026 InsureLytix Inc.. All rights reserved.
Back to blog
Compliance·9 min read

A practical guide to 42 CFR §422.116 network adequacy filing

What CMS actually checks, where plans typically fail, and how to build a HSD table that survives an audit — without padding the network.

Published April 22, 2026 · InsureLytix Editorial

What §422.116 is, in one paragraph

Section 422.116 of Title 42 sets the network-adequacy criteria a Medicare Advantage plan must meet to operate in a county. It uses time-and-distance standards by specialty and county type (Large Metro, Metro, Micro, Rural, CEAC), a minimum provider count, and — for D-SNPs and certain MA contracts — additional access standards. CMS verifies through the Health Service Delivery (HSD) table you upload to HPMS.

Where plans actually fail

  • Specialty taxonomy mismatches — a 'family practice' vs 'family medicine' string drifts and a county silently goes from adequate to critical.
  • Distance computed as Euclidean instead of road-network. A provider 'within 30 miles as the crow flies' may be 55 minutes by road in mountainous CEAC counties.
  • Stale geocodes. A practice moves; the lat/lng is six months old; the member shows up to a vacant building.
  • Population denominators using all-age BRFSS data inflated by 3–5× over what the 65+ population actually looks like in that county.

The HSD table CMS wants

The HSD table is one row per provider × specialty × county-of-service. The fields CMS scores are well documented; the failures come from the data behind those fields, not the field schema.

Two anti-patterns to avoid

  • Reporting from a different system than the one members search. If the member-facing directory and the HSD upload disagree, the auditor will find both.
  • Treating gap analysis as a compliance artifact rather than an operational metric. Plans that close gaps continuously have nothing to defend in an audit.

How we approach it

InsureLytix's gap engine is the same dataset as the member-facing search. County × specialty × disease coverage is computed on every provider data refresh, weighted by realistic care pathways, and exported as the HSD table — not a derived view, the same numbers.

Ready when you are

Want to talk to the people who built this?

The blog is short. The conversation is longer. We come prepared with your stack in mind.

Book a 30-min demoRun the free readiness check