Monthly refresh checks

You may want to conduct monthly eligibility checks for your entire patient population or a subset of patients, such as those who have active care plans or who have future services scheduled. This approach allows you to proactively reach out to patients when they lose or change coverage, preventing surprises and billing delays.

This page contains best practices for optimizing your monthly eligibility refresh checks and avoiding common pitfalls like payer throttling.

​

Request contents

We recommend the following when structuring batch checks:

• Dates of service: Dates of service should include only the current month. While it is possible for a patient to gain or lose eligibility in the middle of a month, eligibility usually starts and ends on month boundaries.
• Service type codes: Medical providers should set encounter.serviceTypeCodes to a single value of 30 - Health Benefit Plan Coverage, and dental providers should set it to 35 - Dental Care. Other values may not be supported by some payers. Don’t include multiple service type codes because many payers will either return an error or ignore additional codes entirely.

​

When to send requests

Wait until at least 3:00 AM local time on the first day of the month to begin monthly eligibility checks. This approach allows for delays in payer system updates and time zone differences. It also avoids the large volume of requests that occur from many organizations scheduling their refresh checks to begin at midnight.

Avoid sending batches of refresh checks during your business hours, since you may inadvertently exceed your Stedi account’s concurrency limit and leave none available to perform eligibility checks in response to real-time customer requests.

​

Avoid throttling

Payers expect to receive requests at a “human scale”, such as a member entering insurance information into a website or presenting their insurance card at a doctor’s office. They may throttle high volumes of requests for the same provider (NPI ID) at once. Stedi’s eligibility check API also has a default rate limit of 5 concurrent requests per account.

​

Throttling indicators

Monitor responses for the following codes:

• HTTP status code 429, which indicates that Stedi is throttling because you reached your account concurrency limit
• payer.aaaErrors.code = “42”, which indicates that the payer is having issues

​

How to avoid throttling

Follow these guidelines:

• Don’t hit payers with the same NPI ID more than 1-2 times every 15 seconds unless it’s necessary to process your batch in a reasonable timeframe.
• Use an exponential backoff algorithm to wait progressively longer periods before sending another request to the same payer. This approach differs from “live” eligibility checks where we recommend immediate retries because a patient might be waiting on the results.
• Wait a few hours to retry if the first day of the month falls on a weekend and all requests to a particular payer are failing. Some payers have scheduled downtime, usually on weekends.
• Interleave requests to multiple payers in a round-robin style. For example, instead of sending all requests to payer #1 and then all requests to payer #2, send one request to payer #1, then one request to payer #2, and then go back to payer #1. Many payers impose real-time transaction rate limits on particular sources or NPIs, so interleaving requests across payers reduces the risk of hitting those limits.

​

Minimize waste

We recommend the following to optimize your monthly eligibility checks:

• Periodically purge or archive records for inactive patients. It’s a waste to perform eligibility checks on patients who have died or who haven’t scheduled an encounter for several years.
• Remove or deactivate patients that are no longer eligible. The payer indicates ineligibility by setting benefitsInformation.code = “6” (Inactive) in the response.

​

Follow up as needed

Check for benefitsInformation.code = “5”, which stands for Active - Pending investigation, or a response containing a benefitsDateInformation.premiumPaidToDateEnd before the current date. Some payers may still show active coverage while the subscriber is behind on premium payments.

You may want to conduct additional checks on these patients because they have an elevated risk of losing coverage soon.