Most providers’ offices ask for a considerable amount of information during the intake process for a new medical encounter. Since this by definition eliminates the possibility of sending a minimal query as an Eligibility request, accuracy in data entry is important for a successful Eligibility transaction. Avoid cutting corners in this area.

Error Message Formatting

Eligibility Error Message Description

Eligibility Error Message	Description
`{ "field": "provider.validProviderCode", "description": "Allowed Values are: 'AD' Admitting, 'AT' Attending, 'BI' Billing, 'CO' Consulting, 'CV' Covering, 'H' Hospital, 'HH' Home Health Care, 'LA' Laboratory, 'OT' Other Physician, 'P1' Pharmacist, 'P2' Pharmacy, 'PC' Primary Care Physician, 'PE' Performing, 'R' Rural Health Clinic, 'RF' Referring, 'SB' Submitting, 'SK' Skilled Nursing Facility, 'SU' Supervising" }`	Many error messages describe simple follow up actions and show the X12 loop where the incorrect field appears. For most errors, you can just correct the JSON field (in the request body) that's listed in the response, or edit using your console workflow. For some request fields, errors list the permissible values. If a data entry mistake occurs in this field, you’ll receive this error. Since a provider will often be of one specific type, the `providerCode` value should be a commonly understood value among provider employees whose job involves claims processing. Since `providerCode` is an optional value, consider removing optional values from the request before re-sending. Depending on the data that’s needed to fully define the procedure for payer analysis, this may not be an option.

{
   "field": "provider.validProviderCode", 
   "description": "Allowed Values are: 
        'AD' Admitting, 
        'AT' Attending, 
        'BI' Billing, 
        'CO' Consulting, 
        'CV' Covering, 
        'H' Hospital, 
        'HH' Home Health Care, 
        'LA' Laboratory, 
        'OT' Other Physician, 
        'P1' Pharmacist, 
        'P2' Pharmacy, 
        'PC' Primary Care Physician, 
        'PE' Performing, 
        'R' Rural Health Clinic, 
        'RF' Referring, 
        'SB' Submitting, 
        'SK' Skilled Nursing Facility, 
        'SU' Supervising"
}

Many error messages describe simple follow up actions and show the X12 loop where the incorrect field appears. For most errors, you can just correct the JSON field (in the request body) that's listed in the response, or edit using your console workflow. For some request fields, errors list the permissible values.

If a data entry mistake occurs in this field, you’ll receive this error. Since a provider will often be of one specific type, the providerCode value should be a commonly understood value among provider employees whose job involves claims processing. Since providerCode is an optional value, consider removing optional values from the request before re-sending. Depending on the data that’s needed to fully define the procedure for payer analysis, this may not be an option.

Required Value errors

Eligibility Error Message	Description
`{ "errors": [ { "field": "provider.name", "description": "Either provider OrganizationName or LastName are required." } ] }`	If you submit a request body that’s missing a required value, you’ll receive a response similar to the following: The message also tells you which fields are permissible for identification. Here, you can provide `organizationName` or `firstName` and `lastName` for the medical provider.
`{ "provider": { "firstName": "medical", "lastName": "group", "npi": "0123456789" },`	At a minimum, for the provider object, you must provide the `npi` and `organizationName`. If the provider is an individual, the `firstName` and `lastName` are both required.
`{ "field": "AAA", "code": "71", "description": "Patient Birth Date Does Not Match That for the Patient on the Database", "followupAction": "Please Correct and Resubmit", "location": "Loop 2100C" }, { "field": "subscriber.dateOfBirth", "description": "Invalid date format. Please use the following format: yyyyMMdd." }`	When you receive the following subscriber error, ensure the `dateOfBirth` field is formatted correctly. You may see more than one error for the related issue because the wrongly formatted date will also show up as an incorrect value against the payer database.
`{ "errors": [ { "field": "controlNumber", "description": "BAD_CONTROL_NUMBER" } ] }`	This is a sample error for a request submitted with a mistake in the control number. It's a fundamental issue that must be fixed before a query can be processed.

Understanding AAA errors

Payers are considered the Information Source for all eligibility queries, and this is the standard term in the medical industry. The provider submitting an eligibility query is called the Information Receiver.

AAA errors report on missing or invalid information from various parts of the submitted 270 Eligibility request. It's the standard error reporting system for all Eligibility transactions. AAA errors generate from seven different sections of eligibility queries:

Information Source level - Errors in this category indicate problems or mistakes in reaching the query's specified recipients, such as the Interchange/clearinghouse ID (ISA06), or the payer (ISA08). The correct Interchange ID is important because the transaction you're submitting is used by both you, as the query sender, and the ultimate receiver of the query, who is the payer that will verify the insurance coverage. There might be a mistake in the Payer field, and the Interchange can't locate it in the payer network.
Request Validation - Reports system errors such as more patient queries than the submitter is allowed to send; the query is being sent by a provider that isn't authorized to submit requests to the payer; the Payer is experiencing network problems or otherwise unable to receive and process the submission; and other causes.
Information Receiver - Problems are detected in the request content defining the query sender - the Information Receiver of hoped-for insurance verification from the payer. You've got incorrect information in the Provider object, or possibly a missing PayerID.
Subscriber Request - There is incorrect content in the Subscriber object. A nicely detailed and extensive list of possible errors arises from this category. A significant one involves Invalid /Missing Subscriber/Insured Name which usually denotes the patient in the request doesn't have active insurance with the payer. Out of network messages come from this category.
Subscriber Request Validation - The request contains subscriber information that caused problems with processing it, such as incorrect dates, or in some cases the payer requests more data.
Dependent Request - There's incorrect or missing content for the dependent in the eligibility request. Many of the same error types you see for subscriber information also see usage here.
Dependent Request Validation - The request contains dependent information that caused problems with processing it, such as incorrect dates. In some cases the payer requests more data.

Eligibility Error Message	Description
`"errors": [ { "field": "AAA", "code": "T4", "description": "Payer Name or Identifier Missing", "followupAction": "Resubmission Allowed", "location": "Loop 2100A" } ] }` `"errors": [ { "field": "AAA", "code": "43", "description": "Invalid/Missing Provider Identification", "followupAction": "Please Correct and Resubmit", "location": "Loop 2100B" } ] }`	The first error example is a Request validation error, showing the code `T4` with the explanation that the request is missing correct payer information whether it's the correct payer `name` or the correct `payorId`. Because the submitter (who is, of course, the Information Receiver) has authorization to do business with the payer, the message `Resubmission Allowed` signals that the provider can fix the problem and try again. The second error reports that correct Provider information is missing in the request. It is an error from the Information Receiver Request Validation AAA category. (Consult Page 243 of the ASC X12 Consolidated 270/271 Implementation Guide.)

Eligibility Error Message

Description

    "errors": [
        {
            "field": "AAA",
            "code": "T4",
            "description": "Payer Name or Identifier Missing", 
            "followupAction": "Resubmission Allowed",
            "location": "Loop 2100A"
        }
    ]
}

    "errors": [
        {
            "field": "AAA",
            "code": "43",
            "description": "Invalid/Missing Provider Identification",
            "followupAction": "Please Correct and Resubmit",
            "location": "Loop 2100B"
        }
    ]
}

The first error example is a Request validation error, showing the code T4 with the explanation that the request is missing correct payer information whether it's the correct payer name or the correct payorId. Because the submitter (who is, of course, the Information Receiver) has authorization to do business with the payer, the message Resubmission Allowed signals that the provider can fix the problem and try again.

The second error reports that correct Provider information is missing in the request. It is an error from the Information Receiver Request Validation AAA category. (Consult Page 243 of the ASC X12 Consolidated 270/271 Implementation Guide.)

999 Errors

In the event of a 999 error, the error.code will be set to the 999 and the following information is mapped.

segment	element	field
IK	301	error.field Segment: %s
IK	302	error.location the segment Loop: %s, Segment Position: %s
IK	303	error.location the loop Loop: %s, Segment Position: %s
IK	304	error.description
IK	40101-103,402,403,404	error.followupAction Element Position in Segment: %s, Component Data Element Position in Composite: %s, Repeating Data Element Position: %s, Data Element Reference Number: %s, Implementation Data Element Syntax Error: %s, Copy of Bad Data Element: %s
IK	501	response.transactionSetAcknowledgement
IK	502	response.implementationTransactionSetSyntaxError