How to verify coverage for Medicaid patients when it changes month to month

Commercial coverage usually changes at renewal or after open enrollment. Children under 19 usually keep Medicaid for 12 months at a time. Medicaid coverage for adults can change any month. It sometimes ends mid-month, like when a patient moves to another state.

That's a problem if most of the patients you serve are on Medicaid. Many behavioral health practices, community health worker programs, and home- and community-based services providers serve mostly Medicaid patients. For these providers, last month's eligibility check may not match this month's coverage. The patient may have switched to a new plan with a new member ID. If you bill the old plan, it denies the claim.

How the One Big Beautiful Bill impacts Medicaid eligibility checks covers how often to check Medicaid coverage. This guide covers when to run each check and what to do when one comes back inactive.

When should I run my monthly Medicaid check?

Run it on the first day of the month, not the day before. Most state Medicaid payers only return coverage through the end of the current month. A check for next month usually fails with an AAA error. AAA errors are codes that explain why a check fails. The payer returns 62 (Date of Service Not Within Allowable Inquiry Period) or 63 (Date of Service in Future). For tips on when to schedule the check, see How to optimize monthly eligibility refresh checks.

But a monthly check doesn't show coverage that ends later in the month. To avoid denied claims, also run a real-time eligibility check on the day of each visit. Use the visit date as the date of service.

How do I tell if the patient was covered on a specific date?

Look at the coverage status for your date of service. An eligibility check returns coverage for the date of service in the request.

Stedi returns eligibility data in one of two response shapes, depending on the endpoint you call. Real-Time Eligibility Check JSON responses use a plans array. Batch Eligibility Check, Insurance Discovery, Real-Time Eligibility Check Raw X12, and Real-Time Eligibility Check JSON - Legacy responses use a benefitsInformation array.

In plans[].benefits.statuses, a status that starts with INACTIVE means the patient isn't covered for that service.
In benefitsInformation, a code of 6, 7, or 8 means the patient isn't covered for that service.

Don't rely on the plan end date in subscriber.dates.plan.end or planDateInformation.planEnd. Many payers use a placeholder date, like 9999-12-31, until the plan ends. For an example, see Tips for annual eligibility refreshes.

Some state Medicaid payers also return a renewal date. To learn where to find it, see Do eligibility responses include Medicaid renewal dates?

What if the managed care plan says the patient is inactive?

Check the state Medicaid payer before you run an insurance discovery check. An insurance discovery check uses a patient's demographic data to search for coverage across payers.

Many Medicaid patients get coverage through a managed care plan. A managed care plan is a health plan that contracts with the state to provide Medicaid benefits. Patients can switch between these plans, usually at the start of a month. When they do, an eligibility check to the old plan comes back inactive. To find the new plan, staff often look it up in the state Medicaid portal, one patient at a time.

You can often get the new plan from an eligibility check to the state Medicaid payer instead. Many state Medicaid payers return the patient's managed care plan in the response.

In a plans response, the managed care plan often appears in plans[].benefits.otherOrAdditionalPayer[].relatedEntities:

{
  "plans": [
    {
      "benefits": {
        "otherOrAdditionalPayer": [
          {
            "coverageLevel": "INDIVIDUAL",
            "insuranceType": "HEALTH_MAINTENANCE_ORGANIZATION_HMO",
            "service": { "system": "STC", "value": "30" },
            "relatedEntities": [
              {
                "type": "CONTRACTED_SERVICE_PROVIDER",
                "name": { "organization": "EXAMPLE HEALTH PLAN" } // Managed care plan
              }
            ]
          }
        ]
      }
    }
  ],
  ...
}

Some states use plans[].benefits.managedCareCoordinator instead, so look in both arrays. Use the entity's name, not its type. The type varies by state.

In a benefitsInformation response, the managed care plan often appears in benefitsInformation[].benefitsRelatedEntities:

{
  "benefitsInformation": [
    {
      "code": "R", // Other or Additional Payor
      "coverageLevelCode": "IND",
      "insuranceTypeCode": "HM", // HMO
      "serviceTypeCodes": ["30"],
      "benefitsRelatedEntities": [
        {
          "entityIdentifier": "Contracted Service Provider",
          "entityType": "Non-Person Entity",
          "entityName": "EXAMPLE HEALTH PLAN" // Managed care plan
        }
      ]
    }
  ],
  ...
}

Some states use an entry with a code of MC (Managed Care Coordinator) instead, so look for both codes. Use the entity's entityName, not its entityIdentifier. The entityIdentifier varies by state.

Other states put the plan name in the active coverage entry or in a message.

Once you have the current plan, run a follow-up check against that plan for plan-specific benefits. The plan may assign the patient a different member ID. In some states, like Pennsylvania, the state Medicaid payer holds the eligibility record, not the plan. If the plan can't find the patient, rely on the state Medicaid payer's response.

If the state Medicaid payer also says the patient is inactive, run an insurance discovery check.

Should I use insurance discovery for Medicaid patients?

Yes, but use it as the next step, not the first check.

If you think the patient has Medicaid, we recommend you check the Medicaid payer for the patient's state first. An eligibility check to the right payer is faster, cheaper, and more reliable than an insurance discovery check.

You may not need a member ID for that check. Many state Medicaid payers can find a patient by Social Security number (SSN). Each state sets its own rules. Most states pair the SSN with the patient's date of birth or full name. Some states, like Arkansas, don't support SSN searches. Send the full nine-digit SSN in subscriber.additionalInformation.ssn, not in the member ID field. For batch checks and the legacy JSON endpoint, use subscriber.ssn.

Insurance discovery is the next step when:

The state Medicaid payer says the patient is inactive. The patient may have other coverage, like an employer plan.
You don't know whether the patient has Medicaid, or which state covers them.
Eligibility checks fail with AAA 75 (Subscriber/Insured Not Found) and you can't fix the patient's demographic data.

Insurance discovery can't search every payer. For example, it doesn't search Medi-Cal, California's Medicaid program. If you think the patient has Medi-Cal, check Medi-Cal directly.

For the best insurance discovery results, include:

The patient's state. Insurance discovery uses it to find regional and state-specific payers. A ZIP Code alone isn't enough, and you don't need a full address.
The patient's SSN, if you have it. Payers use it to match the patient. The last four digits can also help.
The provider's Medicaid Provider IDs. State Medicaid programs assign these IDs to enrolled providers. They aren't required, but they can improve insurance discovery results for some payers. To add them, email enrollments@stedi.com with a CSV of National Provider Identifiers (NPIs) and Medicaid Provider IDs.

What else is different about Medicaid eligibility checks?

Most state Medicaid payers don't require transaction enrollment for eligibility checks, but some do. Transaction enrollment registers a provider with a payer for specific transaction types. To see whether a payer requires it, search the Stedi Payer Network. Payers that require it show Supported, enrollment required in the Eligibility checks column.

Some Medicaid payers also require extra information. For example, Medi-Cal requires the provider's Medi-Cal Provider Identification Number (PIN) on every eligibility check. Send it in provider.additionalInformation.personalIdentificationNumber. For batch checks and the legacy JSON endpoint, use portalPassword. Without a valid PIN, the payer returns AAA 41 (Authorization/Access Restrictions). Each provider has a different PIN, so collect it when you onboard the provider.

Most Medicaid payers don't support dependent eligibility checks. Children usually have their own member ID. Send them as the subscriber, even if a parent also has Medicaid. Some state Medicaid payers support checks for newborns under 12 months old. For details, see Medicaid dependents.

What does the full workflow look like?

At intake: Collect the patient's name, date of birth, state, and SSN. Collect the member ID if the patient has one.
On the first day of each month: Run a batch eligibility check for every active patient. Send each check to the patient's payer on file.
For patients inactive at a managed care plan: Check the state Medicaid payer to find the current plan. Then check that plan.
For patients inactive at the state Medicaid payer: Run an insurance discovery check with the patient's state and SSN.
On the day of each visit: Run a real-time eligibility check with the visit's date of service.

In the Stedi portal, Agentic Discovery automates part of this workflow. It retries failed eligibility checks with corrections, then runs an insurance discovery check if it still can't find coverage.

Get started with Stedi

If you're building eligibility workflows for Medicaid patients, Stedi can help.

To get started, sign up for a free sandbox account. It takes less than two minutes. No credit card is required.

When you're ready, upgrade to production on our pay-as-you-go plan. There are no monthly minimums or setup fees. You only pay for the transactions you use.

Twitter LinkedIn