Contents of the Eligibility Response

What does eligibility information look like when you receive it from the payer? Find out here.

The Eligibility response provides the complete status of the requested patient's medical insurance. It can provide details of medical coverage for dozens of medical specialties, or it can simply confirm that the patient has current medical insurance (or otherwise). In this topic, we'll describe the types of information you can expect to find in this body of information; where you can expect to find it, what the medical benefits look like, and how the Eligibility response describes medical benefits for medical services.

Identification and Policy Confirmation

This topic describes the Eligibility response by each JSON object it contains. You can send as little or as much provider and subscriber information as needed to get a successful result. Check the topic Using “Bare Minimum” Eligibility requests if you want to simplify sending Eligibility requests for routine submission work.

The Eligibility response leads off with information from the transaction set header (controlNumber) and identifies the service provider that's submitting the Eligibility request.

JSON Eligibility Object Description
   {
        "controlNumber": "000000001",
        "reassociationKey": "000000001",
        "tradingPartnerServiceId": "9496",
        "submitterTransactionIdentifier": "7894445309"
        "provider": {
            "providerName": "happy_doctors_group",
            "entityIdentifier": "Provider",
            "entityType": "Non-Person Entity",
            "npi": "0123456789"
        },















The header attributes (controlNumber, `reassociationKey, tradingPartnerServiceId, and submitterTransactionIdentifier) derive from the ISA/IEA envelope and the BHT segment for the transaction. These elements don't have a loop and are required for all Eligibility API transactions. The submitterTransactionIdentifier is a value that CHC Support can use for troubleshooting purposes.

The provider object describes the submitting provider's information. The entityIdentifier attribute describes the information receiver that sent the Eligibility request, in this case a Provider. They'll typically be receiving the patient's insurance information as the response to their request. The entityType will always be either a Person or a Non-Person Entity. In this example, the submitting provider's NPI follows.

NOTE: The provider object and its accompanying information describe what's called the information receiver in the EDI standard documentation.

The Subscriber Object

The subscriber object contains the standard identification info and the subscriber's demographic information.

JSON Eligibility Object Description
    },
    "subscriber": {
        "firstName": "johnOne",
        "lastName": "doeOne",
        "gender": "M",
        "entityIdentifier": "Insured or Subscriber",
        "entityType": "Person",
        "dateOfBirth": "18800102",
        "ssn": "111111111",
        "provider": {}
    },
    "subscriberTraceNumbers": [
        {
            "traceTypeCode": "1",
            "traceType": "Current Transaction Trace Numbers",
            "referenceIdentification": "000000001",
            "originatingCompanyIdentifier": "9EMDEON999"
        }
    ],

The subscriber object is required when the subscriber is the patient.

The subscriberTraceNumbers link the 271 response to the 270 request. It is an optional request feature that, if used, requires its corresponding use in the 271 response. The trace numbers are used when the 270 request is processed in real time, which is the vast majority of Medical Network API transactions.






The Payer Object: Identifying the Payer

This object describes the insurance payer (and information source) for the policy. It also describes the payer type that underwrites the policy.

JSON Eligibility Object Description
    "payer": {
        "entityIdentifier": "Payer",
        "entityType": "Non-Person Entity",
        "name": "Unknown",
        "payorIdentification": "9496"
    },
    "planInformation": {
        "socialSecurityNumber": "111111111"
    },
    "planDateInformation": {
        "plan": "20150219-20160818"
    },










The Payer will typically be a Non-Person Entity. If the entityType is a Non-Person entity, the object containing these values doesn't need the first name. It requires only the Last Name/Organization Name, which the API reports as name for the corporate name of the payer. The API also inserts the payer's payorIdentification as the last field. This element contains the Payer ID value that uniquely denotes each individual payer in the United States healthcare system.

The planDateInformation object describes the insurance coverage dates. It consists of two dates: first, the Plan Begin Date (or the date from the preceding 18 months since the plan took effect, whichever is more recent); the second is the eligibility submission date. You can find out more about this requirement on Page 20 of the ASC X12 Consolidated 270-271 Guide.

NOTE: The payer object and its accompanying information describe what's called the information source in the 270/271 standard documentation.

The planStatus Object

After the content describing the subscriber, the provider and the payer, the planStatus object describes the core status information for the subscriber’s insurance coverage:

JSON Eligibility Object Description
"planStatus": [
    {
       "statusCode": "1",
       "status": "Active Coverage",
       "planDetails": "QMB",
       "serviceTypeCodes": [
       "30"
       "88"
       "BV"
       "BU"
       "BT"
       ...
        ]
    }
],

PlanStatus describes the key details of the patient's insurance coverage. QMB denotes a Qualified Medicare Beneficiary. The main element in Plan Status is a list of codes, called Service Type Codes (serviceTypeCodes). Each code is associated with a medical specialty, or service. Under Plan Status, the list of Service Type Codes shows the medical services that are covered by the patient's insurance. The benefitsInformation object (see below) separately provides the details of each medical service's coverage.

NOTE: Many Eligibility responses will simply confirm an active insurance policy by sending "30" as the only listed service code. Any other listed codes are optional for the payer response. The submitter can request more details about other covered benefits.

The benefitsInformation Object - Navigating Insurance Codes

BenefitsInformation comprises a key part of the Eligibility response. It describes the covered medical benefits, in further detail, to which the patient is entitled. It also includes information about who may be responsible for paying some medical costs, including patient responsibility and any second or third payers who may be involved. All of this information will be shown for either the subscriber or a dependent of the subscriber. For deeper information on how benefits information is structured, including looping elements, see Page 295 of the ASC X12 Consolidated 270-271 Guide.

JSON Eligibility Object Description
{
    "benefitsInformation": [
        {
            "code": "1",
            "name": "Active Coverage",
            "coverageLevelCode": "IND",
            "coverageLevel": "Individual",
            "serviceTypeCodes": [
                "30"
            ],
            "serviceTypes": [
                "Health Benefit Plan Coverage"
            ],
            "insuranceTypeCode": "QM",
            "insuranceType": "Qualified 
                    Medicare Beneficiary",
            "planCoverage": "QMB",
            "benefitsDateInformation": {
                "benefit": "20160818-20171130"
            }
        },
        {
            "code": "R",
            "name": "Other or Additional Payor",
            "coverageLevelCode": "IND",
            "coverageLevel": "Individual",
            "serviceTypeCodes": [
                "30"
            ],
            "serviceTypes": [
                "Health Benefit Plan Coverage"
            ],
            "insuranceTypeCode": "WA",
            "planCoverage": "MEDICARE PART A",
            "benefitsDateInformation": {
            "plan": "20160818-20171130"
        }
        {
            "code": "R",
            "name": "Other or Additional Payor",
            "coverageLevelCode": "IND",
            "coverageLevel": "Individual",
            "serviceTypeCodes": [
                "30"
            ],
            "serviceTypes": [
                "Health Benefit Plan Coverage"
            ],
            "insuranceTypeCode": "MB",
            "insuranceType": "Medicare Part B",
            "planCoverage": "MEDICARE PART B",
            "benefitsDateInformation": {
                "plan": "20160818-20160818"
            }
        }
    },







You will often see multiple segments under benefitsInformation. Each segment represents a medical coverage benefit. Example: a chiropractic visit will have a different benefit structure from a Primary Care visit. Each has their own benefits structure and their own distinct segment in the Eligibility response body. The information receiver decides if they want individual benefits shown in the response.

The first two values in each segment, code and name, identify the top-level benefit information. When you see codes A, B, C, G, J or Y, the current object is describing a patient responsibility (coinsurance, co-payment, deductible and so on).

The coverageLevelCode is IND for Individual. For readability, the API's JSON response provides the coverageLevel descriptive value for this code (individual). It shows who is covered by the policy; the entire family (FAM), Employee Only (EMP), or other options.

The serviceTypeCodes may list and describe up to 99 individual service benefits for a single inquiry. If the response only gives a confirmation of general coverage benefits (using the code 30), you'll see an example similar to this one. Here, a patient's Medicare coverage describes the top-level Medicare payer, with Medicare Part A and Part B as other or additional payers for the subscriber.

The insuranceTypeCode is also a code pair with insuranceType in our API. Our API describes the code (such as MA, for Medicare Part A) as a second attribute. It describes the product type of the insurance, such as Medicare Part A/Part B, Long-Term Care, Auto Insurance Policy, and many others.

ServiceTypes also appear in this block of information, showing how benefits coverage applies to each medical service. In this example, the phrase Health Benefit Plan Coverage corresponds to Code 30.

    "benefitsDateInformation": {
        "plan": "20160818-20160818"
    }

Finally, benefitsDateInformation describes the insurance coverage dates. Its data consists of two dates: the first is the Plan Begin Date (or the date from the preceding 18 months from the current submission date, whichever is more recent); the second is the eligibility submission date.

The serviceTypeCode value of 30 is a common value in Eligibility queries. It identifies in-effect coverage for the broad array of typical medical services covered by the plan. In this case, it's Medicare, which is the classic broad-coverage payer in the United States. It provides coverage for a large collection of medical services. Payers will often confirm medical insurance coverage by sending a response listing only the 30 value in the benefitsInformation loop.

Insurers/payers can also give more granular information about benefits coverage.

A quick Insurance Type Codes search in the X12 Eligibility Consolidated 270/271 Guide gives you the full serviceTypeCode list, spanning several pages. In order to use this document, you must have an active X12 subscription.

Benefits, Time Periods, and Coverage Amounts

Every Service Type segment has more or less the same format:

JSON Eligibility Object Description
    "serviceTypes": [
        "Skilled Nursing Care"
    ],
    "insuranceTypeCode": "MA",
    "insuranceType": "Medicare Part A",
    "timeQualifierCode": "7",
    "timeQualifier": "Day",
    "benefitAmount": "164.5",
    "benefitsDateInformation": {
        "admission": "20170101-20171231"
    }




Note the repetition of insuranceTypeCode. Here, it's called out to identify the insurance coverage for each individual service. This value can differ from the umbrella insuranceTypeCode value; in this case the umbrella insurance code is QM for a qualified Medicare beneficiary, and the service's insuranceTypeCode is MA for Medicare Part A.

The timequalifierCode shows the benefit billing period, which is Daily, using 7 as the EDI value. (This value does NOT define a weekly time span.) Our API provides the timeQualifier description, which is day, so benefit coverage is tracked daily.

The benefitAmount is added based on the timeQualifier, so the daily benefit amount of the Skilled Nursing Care service is $164.50.

Results when a subscriber is not covered by an associated plan

What about cases where a subscriber/patient doesn't have a medical plan?

The following message appears when a subscriber doesn't have active coverage from a medical plan:

JSON Eligibility Object Description
{
    "errors": [
        {
            "field": "subscriber",
            "description": "Invalid/Missing 
                            Subscriber/Insured Name",
            "followupAction": "Please Correct 
                            and Resubmit",
            "location": "Loop 2100C"
        },
        {
            "field": "AAA",
            "description": "Transaction contained 
                            a AAA rejection"
        }
    ]
}
The Eligibility response shows a `Missing Subscriber` result, indicating that they’re not covered by an insurance policy. The example above shows that the subscriber object contains the error in the request.

Mistakes and typos in other fields in the subscriber object may trigger this error, so check all fields submitted in the subscriber object to make sure another issue did not trigger this result.




Metadata (for Troubleshooting)

Change Healthcare Medical Network APIs support a troubleshooting feature called metadata. API users don't need to enable this capability; it is automatic and has no effect on information in any medical transaction. If you encounter any issues with a transaction and need to work with CHC technical support, give the content provided in the `meta` object to the CHC representative.


JSON Response Object Description
{
   "meta": {
       "submitterId": "999898",
       "senderId": "Xxxx.Xxxxxx",
       "billerId": "009998",
       "traceId": "900773a9-c0ba-6aa2-
                   0f61-cfcc30a0200f",
       "outboundTraceId": "7894445309",
       "applicationMode": "prod"
   },







Upon request, give this entire object to CHC support for troubleshooting. All values listed in the meta object are automatically taken from the API request header or from the secure token, with the exception of the outboundTraceId, which is taken from the request header at the beginning of the transaction set (BHT segment, BHT03 element), as the submitterTransactionIdentifier header field.

In the meta object, CHC uses OutboundTraceId for point-to-point tracing and the clearinghouse returns it to the submitter for their use whenever needed.

When they appear, consider the IDs in the metadata object as a hierarchy from less specific to most specific: submitterId as least specific; the senderId denoting the API customer; and billerId as the customer medical department that is responsible for the billing. ApplicationMode describes the operating environment, which for API customers will either be Production ("prod") or Sandbox.


Did this page help you?