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

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.

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.

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

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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.

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.

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.