8 tips for annual eligibility refreshes

Many patients change health plans on January 1.

If you’re a provider, that means any insurance eligibility data from last year might now be wrong.

Providers need current eligibility data to get paid. Old data leads to denied claims, delayed payments, and lost revenue.

That's why many providers run eligibility checks on all or a chunk of their patients at the start of the year. These bulk checks, called eligibility refreshes, catch coverage changes before they cause problems.

But when everyone runs checks at once, payers struggle to keep up. Here are 8 tips for running successful annual refreshes.

1. Don’t trust insurance data from before January

Many providers skip eligibility checks if they’ve verified the patient’s insurance in the last 30 days. That's fine most of the year but not in January.

If your most recent eligibility data is from last year, run a fresh eligibility check. It’ll prevent claim issues later.

Checking coverage in December
Most payers won’t return eligibility data for service dates beyond the end of the current month. We recommend waiting until January to ensure accurate results.

Don’t rely on plan end dates
Many payers include a plan end date in their eligibility responses. In JSON eligibility responses, this date is in the plan or planEnd field.

Don’t rely on this end date to predict whether a patient’s coverage will change. It’s common for payers to use a placeholder date, like 12/31/9999, until the plan actually ends. The safest approach is to assume any plan could change at the start of the year and recheck eligibility in January.

2. Don’t run refreshes for traditional Medicare patients

Patients often age into Medicare coverage, and it almost never changes from year to year. Refreshes aren’t needed.

The Centers for Medicare & Medicaid Services (CMS), the agency that runs Medicare, also doesn’t allow eligibility checks that aren’t tied to real claims. If they see too many checks without claims, they may cut off a provider’s access or take other action.

3. Retry eligibility checks that return AAA 42 errors

AAA errors tell you what went wrong with a failed eligibility check. AAA error 42 (Unable to Respond at Current Time) means the payer is down. It doesn’t mean that your request was wrong, and it’s not related to Stedi. No one can get through to the payer.

Many payer systems get overloaded on January 1 and at the start of most months. Expect to see more AAA 42 errors.

If you get an AAA 42 error, keep retrying the check. Most payer outages last less than 30 minutes. Stedi doesn't charge for checks that return AAA 42 errors - so retrying costs nothing.

For retry strategies, check out our docs.

4. If you’re running several thousand checks at once, try our batch eligibility endpoint

You can use our Real-Time Eligibility Check API endpoint for both one-off checks, like when a patient is at the front desk, and bulk checks, like refreshes. It’s a simple, flexible setup.

But if you're running thousands of time-insensitive checks at once and building custom logic to handle them, look into using our Batch Eligibility Check endpoint. It handles queuing and retries automatically.

For details, see When to use batch eligibility checks.

5. Clean up your patient database before running a refresh

You can save time and money by removing inactive patients from your eligibility refresh. If a patient hasn’t had a visit for years, a fresh eligibility check won’t be useful.

6. If you can, wait a day or two after January 1

Most Stedi customers run their annual or monthly eligibility refresh right after 12 AM Pacific Time on January 1. This works, but it’s also when payer systems are under the heaviest load. You may get more AAA 42 errors.

Even after January 1, some payers may take 1-2 days to load new member data into their systems. If you run checks too early, you might not get data for patients with new payers.

If you can wait until January 2 or 3, we recommend it. It gives most systems time to catch up, and you’ll get cleaner responses.

7. Update your patient data after the refresh

Update your patient records with the member ID, name, and date of birth from returned successful eligibility responses. For example, from a JSON eligibility response’s subscriber object:

{
  "subscriber": {
    "memberId": "123456789",
    "firstName": "JANE",
    "lastName": "DOE",
    "dateOfBirth": "19000101",
  },
  ...
}

Use the same data to run eligibility checks for the patient in the future. It makes it much more likely you’ll get a successful response.

8. Flag patients with lost or changed coverage

If a refresh check shows a patient has lost or changed coverage, reach out to them to get their updated insurance information before their next appointment.

For example, the following JSON eligibility response returns a benefitsInformation object with code = “6”(Inactive) for Service Type Code (STC) 30 (Health Benefit Plan Coverage). That means the patient no longer has active coverage with the payer:

{
  "benefitsInformation": [
    {
      "code": "6",                // Inactive coverage
      "serviceTypeCodes": ["30"], // General medical
      ...
    },
    ...
  ],
  ...
}

Get more tips

If you’re planning your annual eligibility refresh, reach out. We can help you build a refresh strategy that minimizes errors and recovers failed checks.