Frequently Asked Questions - IV. CAQH CORE Eligibility & Benefits Data Content Rule

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule vEB.1.0 is the most current version of the Eligibility & Benefits Data Content Rule.

 

  1. Is a health plan required to respond back with the health plan name in EB05 element of all EB segments sent back in the response?
  2. Can an X12 271 Response to an explicit X12 270 Inquiry containing one of the CORE-required Service Type Codes (STCs) provide information about STCs beyond the requested CORE-required STC?
  3. What patient financials are health plans required to provide in an X12 271 Response to an X12 270 Inquiry?
  4. Are health plans/information sources prohibited from returning such an STC grouping in the X12 271 Response?
  5. Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans to support date ranges in an X12 270 Inquiry?
  6. Why are some Service Type Codes (STCs) identified as “discretionary” in the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule? What information must a health plan return in response to the “discretionary” STCs?
  7. Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans to address the situation where a patient’s benefit coverage changes from the time of the X12 270 Inquiry to the date of service?
  8. When does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans/information sources to return health plan base and remaining deductible?
  9. As a health plan, are we required to respond to explicit benefit inquiries? We do not currently return patient financial responsibility information, i.e., co-pay and deductible, for several behavioral health-related benefits/services that are required.
  10. As a health plan, does the rule require that we return patient financial responsibility (i.e., co-pay and deductible) in the X12 271 Response if we currently do not do so?
  11. If a health plan chooses not to respond with co-payment to one of the optional codes (e.g., 35-Dental, 88-Pharmacy, Or AL- Vision), does this mean it should still respond with coinsurance and deductible for these optional codes?
  12. Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule specify that the range of dates applicable to deductibles that may be returned in an X12 271 eligibility response must be for a full year?
  13. Why does the rule require health plans to return patient remaining deductible information only for the current time period?
  14. Can CAQH CORE provide more detailed definitions for the 51 CORE-required Service Type Codes (STCs) beyond what is provided in the CAQH CORE Eligibility & Benefits Data Content Rule, Table 1.3.2.3, CORE-Required Service Types for an Explicit Inquiry?
  15. What are the requirements for health plans to return eligibility and benefit data for benefits that are not directly administered by the health plan (e.g., pharmacy benefits, vision services, etc.)?
  16. In reviewing the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule , I could not find any statement on how hyphenated or apostrophized last names should be handled, e.g., O'Donnell-Griswold? Should it be just Odonnell?
  17. Some beneficiaries may have two last names e.g. beneficiaries in Puerto Rico in which a married woman will keep her last name and add “de” as the prefix to her husband’s last name. How does CAQH CORE propose the handling of patient last name here?
  18. With regard to –Character Strings To Be Removed During Name Normalization, what recommendations does CAQH CORE have for instances where the last name contains concatenated last name + suffix?
  19. If a health plan receives the subscriber ID number and the subscriber last name in the X12 270 Inquiry, does the health plan have to use the subscriber last name or can they ignore the subscriber last name when processing the X12 270 Inquiry?
  20. Can a health plan/information source return a AAA error segment that contains only the first error condition detected or must it return as many AAA segments as there are errors in the X12 270?
  21. Is the receiver of the X12 271 Response expected to be able to detect all AAA segment error conditions reported by the vendor/health plan and display them to an end user?
  22. When a health plan’s search criteria detects errors during its subscriber/dependent verification editing process, does the Eligibility & Benefits Data Content Rule AAA Error Code Reporting requirement specify in what loop the error should be reported?
  23. Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement require a health plan to validate date of birth?
  24. Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement require that entities use specific AAA03 error codes for specific errors?
  25. Does this rule require specific search or match criteria logic to be used when validating member demographic data?
  26. Is a health plan or information source required to return an X12 271 Response with the specified AAA error codes for each test script specified in the test suite?
  27. How does a health plan identify the correct error condition description to return when multiple error conditions are mapped to the same code?
  28. What must the receiver of the X12 271 Response display when receiving multiple AAA error codes?
Is a health plan required to respond back with the health plan name in EB05 element of all EB segments sent back in the response?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:44
Is a health plan required to respond back with the health plan name in EB05 element of all EB segments sent back in the response?

No. Since the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule does not explicitly identify which EB segments are to carry the health plan name, it could appear on all or some of the EB segments returned. Therefore, the health plan should include the name of the health plan (when available) in EB05 ONLY when EB03=30 Health Benefit Plan Coverage and not return it redundantly on every other EB segment returned. If there are variances in the health plan name for other service type codes returned, the appropriate name should be returned.

Back to Top
Can an X12 271 Response to an explicit X12 270 Inquiry containing one of the CORE-required Service Type Codes (STCs) provide information about STCs beyond the requested CORE-required STC?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:44
Can an X12 271 Response to an explicit X12 270 Inquiry containing one of the CORE-required Service Type Codes (STCs) provide information about STCs beyond the requested CORE-required STC?

Yes. The CAQH CORE Operating Rules represent a floor and not a ceiling. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule do not limit a health plan’s X12 271 Response to only the explicit inquiry STC (Table 1.3.2.3). If the explicit inquiry STC is on the list of CORE-required STCs, the CAQH CORE Rules require that health plans include in their X12 271 Response the required information for that STC. Additionally, the X12 271 Response can include information about other STCs. For a STC that is not required by the CAQH CORE Rules, the  X12N v5010 270/271 TR3 requires that health plans respond with the generic inquiry response.

 
Back to Top
What patient financials are health plans required to provide in an X12 271 Response to an X12 270 Inquiry?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:46
What patient financials are health plans required to provide in an X12 271 Response to an X12 270 Inquiry?

For health plans and information sources, the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require that an X12 271 Response to an X12 270 Inquiry include:

  • Patient financials for co–insurance, co–payment, and base and remaining deductibles
  • Patient financial responsibility for both in–network and out–of–network, if the financial amounts are different
Back to Top
Are health plans/information sources prohibited from returning such an STC grouping in the X12 271 Response?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:46
As the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule does not require that the X12 271 Response to an X12 270 Inquiry include a specified grouping of Service Type Codes (STCs), are health plans/information sources prohibited from returning such an STC grouping in the X12 271 Response?

No. CAQH CORE Operating Rules represent a floor and not a ceiling. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule does not preclude a health plan from returning additional STCs in the X12 271 Response. A health plan can return additional STCs to ensure that the provider has the level of detail required to meet its specific business needs.

Back to Top
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans to support date ranges in an X12 270 Inquiry?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:48
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans to support date ranges in an X12 270 Inquiry?

No. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule does not require support for an inquiry with date ranges. Entities can make individual determinations on whether to support this type of inquiry. The CAQH CORE Eligibility & Benefits Data Content Rule does require that health plans, vendors, and clearinghouse support the X12 270 Inquiry requests for benefit information at least 12 months into the past and up to the end of the current month. This requirement would include returning benefit information for the current plan period if such a request were received.

Back to Top
Why are some Service Type Codes (STCs) identified as “discretionary” in the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule? What information must a health plan return in response to the “discretionary” STCs?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:49
Why are some Service Type Codes (STCs) identified as “discretionary” in the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule? What information must a health plan return in response to the “discretionary” STCs?

For certain STCs, the patient financial data is not required to be returned for some benefits as they are considered carve outs, too general, or are related to sensitive benefits (e.g., behavioral health). The health plan name (if available within its own system), the coverage status of the specific benefit, and the eligibility dates must be returned regardless of whether the health plan or information source is exercising its discretion to not return patient financial responsibility. The discretionary STCs are:

1 – Medical Care

35 – Dental

88 – Pharmacy

A6 – Psychotherapy

A7 – Psychiatric – Inpatient

A8 – Psychiatric – Outpatient

AI – Substance Abuse

AL – Vision (Optometry)

MH – Mental Health

Back to Top
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans to address the situation where a patient’s benefit coverage changes from the time of the X12 270 Inquiry to the date of service?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:49
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans to address the situation where a patient’s benefit coverage changes from the time of the X12 270 Inquiry to the date of service?

No. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule does not require that the X12 271 Response contain final coverage information which is not subject to change. The X12 271 Response data is current as of the date of the X12 271 Response. There is no guarantee that the information reported in any given X12 271 Response will not change. Changes to coverage can occur due to factors outside the control of the health plan. Any X12 271 Response received from a health plan should not be construed to be a guarantee that the health plan will reimburse the provider for health services if a claim is submitted.

Back to Top
When does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans/information sources to return health plan base and remaining deductible?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:50
When does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule require health plans/information sources to return health plan base and remaining deductible?

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule requires that X12 271 Responses to both generic and explicit X12 270 Inquiries include patient financial responsibility for co-pay, co-insurance, and health plan base and remaining deductible for each Service Type Code (STC) returned with exceptions for discretionary reporting. The Rules require health plans to return the dollar amount for both the base and remaining deductible for all CORE-required STCs listed in Table 1.3.2.3. The health plan may, at its discretion, elect not to return patient financial responsibility information (deductible, co-payment or co-insurance) for nine discretionary STCs. Appendix 1 in Section 6.1 specifies all the CAQH CORE STCs and identifies for which codes return of patient financial responsibility information is mandatory or discretionary.

Back to Top
As a health plan, are we required to respond to explicit benefit inquiries? We do not currently return patient financial responsibility information, i.e., co-pay and deductible, for several behavioral health-related benefits/services that are required.

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:51
As a health plan, are we required to respond to explicit benefit inquiries? We do not currently return patient financial responsibility information, i.e., co-pay and deductible, for several behavioral health-related benefits/services that are required.

Yes. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule requires that entities, at a minimum, return the coverage status for each specific benefit (service type code) included in a X12 270 Inquiry that is required in response to an explicit inquiry (Table 1.3.2.3). Even if you are exercising discretion to not return patient financial liability information for one of the listed “discretionary” service types, you must return the health plan coverage status for that code in the EB01 segment in the 2110C or 2110D loop, as appropriate.

Back to Top
As a health plan, does the rule require that we return patient financial responsibility (i.e., co-pay and deductible) in the X12 271 Response if we currently do not do so?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:52
As a health plan, does the rule require that we return patient financial responsibility (i.e., co-pay and deductible) in the X12 271 Response if we currently do not do so?

Yes. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule requires that a health plan must return patient financial responsibility information for co-insurance, co-payment, and both base and remaining deductible (including in and out-of-network variance, if applicable) for each Service Type Code returned in the X12 271 Response.

Back to Top
If a health plan chooses not to respond with co-payment to one of the optional codes (e.g., 35-Dental, 88-Pharmacy, Or AL- Vision), does this mean it should still respond with coinsurance and deductible for these optional codes?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:53
If a health plan chooses not to respond with co-payment to one of the optional codes (e.g., 35-Dental, 88-Pharmacy, Or AL- Vision), does this mean it should still respond with coinsurance and deductible for these optional codes?

No. If your organization chooses to respond with active/inactive only, then your organization should not return any of the patient liability types. As detailed in the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule Subsections, 1.3.2.4 and 1.3.2.5, the health plan may choose not to provide the patient liability information for certain service types and instead return active/inactive information only. However, if the health plan chooses to return patient liability information, it must do so for all three required patient liability types (co-payment, co-insurance and deductible) as applicable to the product.

Back to Top
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule specify that the range of dates applicable to deductibles that may be returned in an X12 271 eligibility response must be for a full year?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:54
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule specify that the range of dates applicable to deductibles that may be returned in an X12 271 eligibility response must be for a full year, or can the range of dates be for less than a full year?

No. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule does not restrict the range of dates applicable to deductibles to be a full year. The CAQH CORE Rule requires that a begin date applicable to deductibles must be returned for the health plan coverage and that alternatively a range of dates may be returned. The range of dates is determined by the health plan and may be less than or greater than a full year. See Table 1.3.2.6.1.

Back to Top
Why does the rule require health plans to return patient remaining deductible information only for the current time period?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:55
Why does the rule require health plans to return patient remaining deductible information only for the current time period, when health plans are required to return the other patient benefit information for a date up to 12 months in the past or the end of the current month?

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule requires health plans to provide patient benefit coverage information in response to an X12 270 Inquiry either up to 12 months in the past or up to the end of the current month.

Health plans are not required to return remaining deductible for past time periods as it would not be feasible for a health plan to attempt to reconstruct what the remaining deductible may have been for a date in the past. Similarly, it would not be possible for health plans to project what the remaining deductible may be on a future date.

Back to Top
Can CAQH CORE provide more detailed definitions for the 51 CORE-required Service Type Codes (STCs) beyond what is provided in the CAQH CORE Eligibility & Benefits Data Content Rule, Table 1.3.2.3, CORE-Required Service Types for an Explicit Inquiry?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:56
Can CAQH CORE provide more detailed definitions for the 51 CORE-required Service Type Codes (STCs) beyond what is provided in the CAQH CORE Eligibility & Benefits Data Content Rule, Table 1.3.2.3, CORE-Required Service Types for an Explicit Inquiry?

A CAQH CORE Operating Rule cannot change or modify the meaning or definition of any X12 standard or code. To assist the industry with a common understanding of some of the CORE-required STCs, CAQH CORE developed supplemental descriptions. These supplemental descriptions are for guidance only to aid in a common industry understanding of the STCs, as noted in the footnote #2 in Table 1.3.2.3 of the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule. Clarification or interpretation of the definition of a Service Type Code can be obtained from X12 via its online X12 Interpretation Portal.

Back to Top
What are the requirements for health plans to return eligibility and benefit data for benefits that are not directly administered by the health plan (e.g., pharmacy benefits, vision services, etc.)?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:56
What are the requirements for health plans to return eligibility and benefit data, including coverage status and patient financial information, for benefits that are not directly administered by the health plan (e.g., pharmacy benefits, vision services, etc.)?

Health plans that have carved out certain benefits to another entity may not have the patient financial data available to respond to an X12 270 Inquiry. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule identifies certain benefits as discretionary for reporting patient financial responsibility for carved out benefits.. This does not preempt the requirement for a health plan to return the other required data in the X12 271 Response (i.e. health plan name, status, etc.).

Back to Top
In reviewing the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule , I could not find any statement on how hyphenated or apostrophized last names should be handled, e.g., O'Donnell-Griswold? Should it be just Odonnell?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:57
In reviewing the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule , I could not find any statement on how hyphenated or apostrophized last names should be handled, e.g., O'Donnell-Griswold? Should it be just Odonnell? Or is this addressed in another CAQH CORE Rule?

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule Last Name Normalization requirement DOES require the removal of both the apostrophe and the hyphen in the O’Donnell-Griswold example cited. The normalized name would be ODONNELLGRISWOLD. Section 2.2.7 lists the X12-designated “special characters” of the “Basic Character Set” and the list includes both the apostrophe and the hyphen. Section 2.3.2.3. of the rule then says “remove the special characters specified in §2.3.2 in the name element.”

Back to Top
Some beneficiaries may have two last names e.g. beneficiaries in Puerto Rico in which a married woman will keep her last name and add “de” as the prefix to her husband’s last name. How does CAQH CORE propose the handling of patient last name here?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 14:58
We have a situation in which some beneficiaries may have two last names as in the case of beneficiaries in Puerto Rico in which a married woman will keep her last name and add “de” as the prefix to her husband’s last name (e.g., Maria Garcia DeSanchez). How does CAQH CORE propose the handling of patient last name in this situation?

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule Last Name Normalization requirement does not address this specific scenario. Since the characters “De” are not included in the specified set of character strings to be removed, any validation of the last name performed by the health plan would naturally be against what was submitted in the Last Name data element in the X12 270 Inquiry against what the health plan maintains in its eligibility system. This is outside the scope of the CAQH CORE Rule.

Back to Top
With regard to –Character Strings To Be Removed During Name Normalization, what recommendations does CAQH CORE have for instances where the last name contains concatenated last name + suffix?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:01
With regard to –Character Strings To Be Removed During Name Normalization, what recommendations does CAQH CORE have for instances where the last name contains concatenated last name + suffix? For example, with the patient’s name comes in as JAMES C POMP II, the last name may be stored as “POMPII”. How can we tell if the last name should be “Pomp” or “Pompii.” In some cases the last names may be concatenated with suffixes and not easily identifiable.

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule  Last Name Normalization requirement includes the character string “II” in the set of specified character strings to be removed during normalization (Section 2.3.2.2). Additionally, the rule in Section 2.3.2.1 defines how to normalize the last name: “To normalize the submitted and stored last name: Remove all of the character strings specified in §2.3.2.2 when they are preceded by one of the punctuation values specified in §2.3.2.3 and followed by a space or when they are preceded by one of the punctuation values specified in §2.3.2.3 and are at the end of the data element And remove the special characters specified in §2.2.7 in the name element.. If the last name as submitted and as stored is not delimiting the suffix using one of the specified punctuation values or store the suffix separately, the normalization logic will not remove the character string “II”. The CAQH CORE Rule does not specify HOW an entity must store a last name, but does make recommendations on this issue in these Sections.

Back to Top
If a health plan receives the subscriber ID number and the subscriber last name in the X12 270 Inquiry, does the health plan have to use the subscriber last name or can they ignore the subscriber last name when processing the X12 270 Inquiry?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:02
If a health plan receives the subscriber ID number and the subscriber last name in the X12 270 Inquiry, does the health plan have to use the subscriber last name or can they ignore the subscriber last name when processing the X12 270 Inquiry?

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule  Last Name Normalization requirement does not require that a health plan use the patient’s last name in its search and match logic to locate an individual within its systems.  When the last name is not used in the health plan’s search and match logic – the rule does not apply – and if the health plan receives the patient's unique ID number in an X12 270 Inquiry, it may use or ignore the name or other demographic data about the individual if not needed or used to uniquely locate that individual in the plan’s systems.

 

Back to Top
Can a health plan/information source return a AAA error segment that contains only the first error condition detected or must it return as many AAA segments as there are errors in the X12 270?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:03
Can a health plan/information source return a AAA error segment that contains only the first error condition detected or must it return as many AAA segments as there are errors in the X12 270?

A health plan/information source is required to return a AAA segment for each error condition that it detects in a X12 270 Inquiry, as described in Section 3.3 of the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement.

Back to Top
Is the receiver of the X12 271 Response expected to be able to detect all AAA segment error conditions reported by the vendor/health plan and display them to an end user?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:03
Is the receiver of the X12 271 Response expected to be able to detect all AAA segment error conditions reported by the vendor/health plan and display them to an end user?

Yes. The receiver of the X12 271 Response, i.e., the system that originated the X12 270 Inquiry, is required to detect all combinations of error conditions from the AAA segments in the X12 271 Response, as defined in Table 3.3.5 Error Reporting Codes & Requirements of the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement, and to display to the receiving system’s end user text that uniquely describes the specific error condition(s) and data elements returned by the health plan in the X12 271 Response.

Back to Top
When a health plan’s search criteria detects errors during its subscriber/dependent verification editing process, does the Eligibility & Benefits Data Content Rule AAA Error Code Reporting requirement specify in what loop the error should be reported?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:04
When a health plan’s search criteria detects errors during its subscriber/dependent verification editing process, does the CAQH CORE Eligibility & Benefits Data Content Rule AAA Error Code Reporting requirement specify in what loop (subscriber or dependent) the error should be reported?

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement identifies 17 error conditions, some of which may occur in the subscriber loop and others which may occur in the dependent loop. Section 3.3 of the AAA Error Code Reporting requirement states that “when a health plan detects any of the specified error conditions it must return an appropriate AAA segment for each error detected and return other data elements as specified.” Thus, the health plan would determine the loop in which to return the appropriate AAA error codes required by the CAQH CORE Rule.

Back to Top
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement require a health plan to validate date of birth?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:05
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement require a health plan to validate date of birth?

No. This rule does not require a health plan (or information source) to validate a date of birth; however, when a date of birth is validated and errors are found, the receiver of the X12 270 Inquiry is required to return an X12 271 Response as specified in the rule.

Back to Top
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement require that entities use specific AAA03 error codes for specific errors?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:06
Does the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement require that entities use specific AAA03 error codes for specific errors?

Yes. The rule specifically identifies the AAA03 error codes that must be returned for each error condition, which may occur in either or both of the Subscriber or Dependent loops (refer to Rule Section 3.3 and the Error Reporting Codes & Requirements Table 3.3.5 of the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule  AAA Error Code Reporting requirement).

Back to Top
Does this rule require specific search or match criteria logic to be used when validating member demographic data?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:07
Does this rule require specific search or match criteria logic to be used when validating member demographic data?

No. The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule  AAA Error Code Reporting requirement does not require a health plan/information source to use any specific search and match criteria or logic.

Back to Top
Is a health plan or information source required to return an X12 271 Response with the specified AAA error codes for each test script specified in the test suite?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:07
Is a health plan or information source required to return an X12 271 Response with the specified AAA error codes for each test script for the CAQH CORE Eligibility & Benefits (270/271) Data Content Rule AAA Error Code Reporting requirement specified in the CORE Certification test suite?

No. Due to the variability in search and match logic and the data elements used by health plans and information sources, some health plans and information sources may match the member in the X12 270 Inquiry test case rather than return the expected AAA error code in the X12 271 Response. An entity seeking CORE Certification can successfully pass the test for this rule by generating at least one X12 271 Response with an AAA Error Code for at least one of the Certification test scripts.

Back to Top
How does a health plan identify the correct error condition description to return when multiple error conditions are mapped to the same code?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:08
How does a health plan identify the correct error condition description to return when multiple error conditions are mapped to the same code?

The CAQH CORE Eligibility & Benefits (270/271) Data Content Rule  AAA Error Code Reporting requirement, Section 3.2.1, What the Rule Applies To, notes that the rule defines a standard way to report errors that prevent health plans (or information sources) from responding with the eligibility information for the requested patient or subscriber. The rule requires use of a unique error code, wherever possible, for a given error condition so that the re-use of the same error code is minimized. Where this is not possible, the goal (when re-using an error code) is to return a unique combination of one or more AAA segments along with one or more of the submitted patient identifying data elements such that the provider will be able to determine as precisely as possible what data elements are in error and take the appropriate corrective action. The CAQH CORE Rule does not require error condition descriptions to be returned.

Back to Top
What must the receiver of the X12 271 Response display when receiving multiple AAA error codes?

Submitted by dasteriadis@caqh.org on Wed, 07/28/2021 - 15:09
What must the receiver of the X12 271 Response display when receiving multiple AAA error codes?

Section 3.3.2, Basic Requirements for Receivers of the X12 271 Inquiry, identifies basic requirements for the “receiver” of the X12 271 Response. These requirements include that the “receiver” must “display to the end user text that uniquely describes the specific error condition(s) and data elements returned by the health plan in the v5010 271.” The receiver may exercise discretion regarding the actual text to be displayed as long as the wording of the text displayed accurately represents the AAA03 Error Code and the corresponding Error Condition Description without changing the meaning and intent of the error condition description.

Back to Top