How to optimize monthly eligibility refresh checks

Jun 25, 2024

Healthcare

Your claim was denied—another patient forgot to update their insurance details after switching jobs. Now, you need to submit a new claim and wait an extra month for reimbursement, putting a strain on your business.

To prevent these kinds of delays, many healthcare customers use our Eligibility Check API to perform monthly refreshes. This is the common practice of scheduling eligibility checks for all or a subset of patients so you can proactively contact them when they lose or change coverage.

This post explains how you can optimize monthly eligibility refresh checks and avoid common pitfalls like payer throttling.

How to structure refresh checks

We recommend the following to get the most useful data from payers:

  • Dates of service: Only include the current month. Patients can gain or lose eligibility in the middle of a month, but eligibility usually starts and ends on month boundaries.

  • Service type codes: Dental providers should send a single service type code of 35 (Dental Care), and medical providers should send 30 (Health Benefit Plan Coverage), which returns eligibility for all coverage types included in the subscriber’s plan. Some payers may not support other values. Don’t include multiple service type codes because many payers will either return an error or ignore additional service type codes entirely.

Here’s an example of a refresh check for our Eligibility Check API:

curl --request POST \
  --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "Cigna",
  "encounter": {
    "beginningDateOfService": "20240601",
    "endDateOfService": "20240630",
    "serviceTypeCodes": [
      "30"
    ]
  },
  "provider": {
    "organizationName": "ACME Health Services",
    "npi": "1234567891"
  },
  "subscriber": {
    "dateOfBirth": "19000101",
    "firstName": "Jane",
    "lastName": "Doe",
    "gender": "F",
    "memberId": "123456789"
  }
}'

When to schedule refresh checks

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

You should also perform refresh checks outside your business hours. You don’t want to run into issues with payer throttling or your API’s concurrency limits while processing time-sensitive eligibility requests from customers.

Avoid payer throttling

Payers may throttle high volumes of requests for the same provider at once because they 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. 

When payers are throttling you, they typically send back payer.aaaErrors.code = “42”, which indicates that the payer is having issues. (Our docs have a complete list of payer error codes for eligibility checks and possible resolution steps that you can use for debugging.)

To avoid throttling during monthly refreshes, we recommend:

  • Only send requests with the same provider NPI ID 1-2 times every 15 seconds. 

  • 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.

Minimize waste

Don’t perform more checks than you need to. We recommend: 

  • 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.

When to follow up 

Flag responses that have benefitsInformation.code = “5”, which stands for Active - Pending investigation, or 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, as they are at a higher risk of losing coverage soon.

Start processing eligibility checks today

Monthly eligibility refresh checks can help improve the care experience for both patients and providers. With Stedi’s API-first clearinghouse, you can automate business flows like eligibility checks and claims processing using APIs that support thousands of payers

Contact us to learn more and speak to the team.

Your claim was denied—another patient forgot to update their insurance details after switching jobs. Now, you need to submit a new claim and wait an extra month for reimbursement, putting a strain on your business.

To prevent these kinds of delays, many healthcare customers use our Eligibility Check API to perform monthly refreshes. This is the common practice of scheduling eligibility checks for all or a subset of patients so you can proactively contact them when they lose or change coverage.

This post explains how you can optimize monthly eligibility refresh checks and avoid common pitfalls like payer throttling.

How to structure refresh checks

We recommend the following to get the most useful data from payers:

  • Dates of service: Only include the current month. Patients can gain or lose eligibility in the middle of a month, but eligibility usually starts and ends on month boundaries.

  • Service type codes: Dental providers should send a single service type code of 35 (Dental Care), and medical providers should send 30 (Health Benefit Plan Coverage), which returns eligibility for all coverage types included in the subscriber’s plan. Some payers may not support other values. Don’t include multiple service type codes because many payers will either return an error or ignore additional service type codes entirely.

Here’s an example of a refresh check for our Eligibility Check API:

curl --request POST \
  --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "Cigna",
  "encounter": {
    "beginningDateOfService": "20240601",
    "endDateOfService": "20240630",
    "serviceTypeCodes": [
      "30"
    ]
  },
  "provider": {
    "organizationName": "ACME Health Services",
    "npi": "1234567891"
  },
  "subscriber": {
    "dateOfBirth": "19000101",
    "firstName": "Jane",
    "lastName": "Doe",
    "gender": "F",
    "memberId": "123456789"
  }
}'

When to schedule refresh checks

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

You should also perform refresh checks outside your business hours. You don’t want to run into issues with payer throttling or your API’s concurrency limits while processing time-sensitive eligibility requests from customers.

Avoid payer throttling

Payers may throttle high volumes of requests for the same provider at once because they 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. 

When payers are throttling you, they typically send back payer.aaaErrors.code = “42”, which indicates that the payer is having issues. (Our docs have a complete list of payer error codes for eligibility checks and possible resolution steps that you can use for debugging.)

To avoid throttling during monthly refreshes, we recommend:

  • Only send requests with the same provider NPI ID 1-2 times every 15 seconds. 

  • 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.

Minimize waste

Don’t perform more checks than you need to. We recommend: 

  • 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.

When to follow up 

Flag responses that have benefitsInformation.code = “5”, which stands for Active - Pending investigation, or 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, as they are at a higher risk of losing coverage soon.

Start processing eligibility checks today

Monthly eligibility refresh checks can help improve the care experience for both patients and providers. With Stedi’s API-first clearinghouse, you can automate business flows like eligibility checks and claims processing using APIs that support thousands of payers

Contact us to learn more and speak to the team.

Your claim was denied—another patient forgot to update their insurance details after switching jobs. Now, you need to submit a new claim and wait an extra month for reimbursement, putting a strain on your business.

To prevent these kinds of delays, many healthcare customers use our Eligibility Check API to perform monthly refreshes. This is the common practice of scheduling eligibility checks for all or a subset of patients so you can proactively contact them when they lose or change coverage.

This post explains how you can optimize monthly eligibility refresh checks and avoid common pitfalls like payer throttling.

How to structure refresh checks

We recommend the following to get the most useful data from payers:

  • Dates of service: Only include the current month. Patients can gain or lose eligibility in the middle of a month, but eligibility usually starts and ends on month boundaries.

  • Service type codes: Dental providers should send a single service type code of 35 (Dental Care), and medical providers should send 30 (Health Benefit Plan Coverage), which returns eligibility for all coverage types included in the subscriber’s plan. Some payers may not support other values. Don’t include multiple service type codes because many payers will either return an error or ignore additional service type codes entirely.

Here’s an example of a refresh check for our Eligibility Check API:

curl --request POST \
  --url https://healthcare.us.stedi.com/2024-04-01/change/medicalnetwork/eligibility/v3 \
  --header 'Authorization: <api-key>' \
  --header 'Content-Type: application/json' \
  --data '{
  "controlNumber": "123456789",
  "tradingPartnerServiceId": "Cigna",
  "encounter": {
    "beginningDateOfService": "20240601",
    "endDateOfService": "20240630",
    "serviceTypeCodes": [
      "30"
    ]
  },
  "provider": {
    "organizationName": "ACME Health Services",
    "npi": "1234567891"
  },
  "subscriber": {
    "dateOfBirth": "19000101",
    "firstName": "Jane",
    "lastName": "Doe",
    "gender": "F",
    "memberId": "123456789"
  }
}'

When to schedule refresh checks

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

You should also perform refresh checks outside your business hours. You don’t want to run into issues with payer throttling or your API’s concurrency limits while processing time-sensitive eligibility requests from customers.

Avoid payer throttling

Payers may throttle high volumes of requests for the same provider at once because they 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. 

When payers are throttling you, they typically send back payer.aaaErrors.code = “42”, which indicates that the payer is having issues. (Our docs have a complete list of payer error codes for eligibility checks and possible resolution steps that you can use for debugging.)

To avoid throttling during monthly refreshes, we recommend:

  • Only send requests with the same provider NPI ID 1-2 times every 15 seconds. 

  • 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.

Minimize waste

Don’t perform more checks than you need to. We recommend: 

  • 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.

When to follow up 

Flag responses that have benefitsInformation.code = “5”, which stands for Active - Pending investigation, or 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, as they are at a higher risk of losing coverage soon.

Start processing eligibility checks today

Monthly eligibility refresh checks can help improve the care experience for both patients and providers. With Stedi’s API-first clearinghouse, you can automate business flows like eligibility checks and claims processing using APIs that support thousands of payers

Contact us to learn more and speak to the team.

Share

Twitter
LinkedIn

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.

Backed by

Stedi is a registered trademark of Stedi, Inc. All names, logos, and brands of third parties listed on our site are trademarks of their respective owners (including “X12”, which is a trademark of X12 Incorporated). Stedi, Inc. and its products and services are not endorsed by, sponsored by, or affiliated with these third parties. Our use of these names, logos, and brands is for identification purposes only, and does not imply any such endorsement, sponsorship, or affiliation.