How Eligibility Responses Work in Test vs Production

1. Are test eligibility responses mocked?

Yes. In the test environment, the Eligibility API always returns the same sample response, regardless of the payer or the member data submitted. This behavior is intentional and is designed to allow you to:

• Verify connectivity

• Validate authentication

• Build and test your request formatting and response parsing logic

The test environment is not intended to simulate real-world payer behavior.

This is also documented in the API Quickstart Guide (see the Eligibility section).

To see real payer behavior—such as different responses by payer, patient, or benefit type—you must move to a production account.

2. How should “unsuccessful” or “not eligible” scenarios be handled?

Because the test environment always returns the same successful sample response, you will not encounter true “no active coverage” or “member not found” scenarios while testing.

In production, determining whether a patient is eligible is not a simple yes/no decision. Your integration logic should evaluate the returned benefit data, including:

• Coverage status

• Plan effective and termination dates

• Benefit types

• Copays, coinsurance, and deductibles

Eligibility decisions should be made based on:

• The date of service (is coverage active on that date?)

• The type of service being checked (e.g., office visit, behavioral health, telehealth)

• Any limitations or exclusions listed in the response

A payer may return:

• Explicit messages such as “insured not found” or “coverage terminated”

• Valid coverage data that does not include benefits relevant to the requested service type

For this reason, your application should interpret the benefit details, not rely solely on the presence or absence of an error flag.

3. What is the difference between error, elig, and elig.error in the API response?

Below is a simplified structure of the Eligibility API response:

JSONJSON
<span class="hljs-punctuation">{</span>
  <span class="hljs-attr">"result"</span><span class="hljs-punctuation">:</span> <span class="hljs-punctuation">{</span>
    <span class="hljs-attr">"error"</span><span class="hljs-punctuation">:</span> <span class="hljs-string">"..."</span><span class="hljs-punctuation">,</span>
    <span class="hljs-attr">"elig"</span><span class="hljs-punctuation">:</span> <span class="hljs-punctuation">{</span>
      <span class="hljs-attr">"error"</span><span class="hljs-punctuation">:</span> <span class="hljs-string">"..."</span><span class="hljs-punctuation">,</span>
      <span class="hljs-attr">"..."</span><span class="hljs-punctuation">:</span> <span class="hljs-string">"benefit data"</span>
    <span class="hljs-punctuation">}</span>
  <span class="hljs-punctuation">}</span>
<span class="hljs-punctuation">}</span>

result.error

• Indicates an error at the Claim.MD system level

• Common causes include:

  • Missing or invalid data

  • Enrollment or payer minimum requirement failures

  • Malformed requests or internal processing errors

  • Unresponsive or unusable payer EDI responses

If result.error is populated, the request should be treated as failed, and you may want to retry or display a technical error to the user.

result.elig

• Indicates that Claim.MD successfully reached the payer and parsed a response

• Contains benefit data (when available) and payer-originated messages

result.elig.error

• Comes directly from the payer’s EDI system

• May include messages such as:

  • “Insured not found”

  • “Subscriber not found”

  • “Member ID not found”

  • “Coverage terminated”

These messages are important, but they are not the sole indicator of eligibility. Even if result.elig.error is empty, benefit data must still be reviewed to determine whether coverage applies to the requested service.

Recommended Production Logic Flow

1. If result.error is present, treat the response as a system or transport error.

2. Else if result.elig.error is present, handle the response as a payer-level failure or “no coverage/member not found” scenario.

3. Else, evaluate the benefit data in result.elig to determine whether coverage is active and applicable.

For payer-side message codes, refer to the Eligibility Code Reference (PDF).

Test vs Production Recap

Test Environment

• Returns one static, successful sample response

• Used to:

  • Validate authentication

  • Confirm request formatting

  • Build and test parsing logic and UI behavior

Production Environment

• Returns live responses from payers

• Includes:

  • Real “member not found” and “no coverage” scenarios

  • Full benefit structures used for eligibility determinations