Standards Documents

Enter a search term to find standard and specification articles.

5010 Eligibility Inquiry and Response Standard v3.2

UHIN STANDARDS COMMITTEE

Approved

 

UHIN STANDARDS COMMITTEE

Version 3.2

5010 Eligibility Inquiry and Response Standard

 

 

The Eligibility Inquiry and Response Standard is compatible with all HIPAA requirements.

 

Purpose:  The purpose of this Standard is to detail the Standard transactions for the transmission of health care eligibility inquiries and responses in the state of Utah.

 

Applicability:  This Standard applies to all electronically submitted eligibility inquiries and responses, sent in batch or real-time, in the state of Utah after January 1, 2013. This Standard may be adopted voluntarily prior to that date.

 

Generally a health insurance payer will be the Information Source and a health care provider will be the Information Receiver but other types of entities may fill those roles.  For example, it is possible that payers may do eligibility inquiries of other payers.  In that case the payer doing the inquiry becomes the Information receiver and the payer holding the benefit information becomes the Information Source.  Likewise, payers may elect to contract out their eligibility operations to external entities (which would then become the Information Source), or payers may elect to be linked to other payer’s eligibility systems.  For the purposes of this Standard, in the interests of keeping the language of this Standard simple, a payer is considered to be the Information Source and a provider is considered to be the Information Receiver but this Standard recognizes that other arrangements may exist.

 

Detail:

The purpose of this Standard is to set out minimum data sets that providers will submit and payers will return on eligibility transaction exchanges.

 

  1. Standard Eligibility Transactions:

The Utah Standard for electronic eligibility inquiries is the HIPAA ASC X12 005010X279A1 270 and 271 Eligibility Benefit Inquiry and Response transactions.

 

See the Washington Publishing Company web site (http://www.wpc-edi.com) to purchase a copy of the 270/271 implementation guide in Adobe Acrobat.

 

2.Addenda:

Utah will implement the Errata corrections for the Eligibility implementation guides.

 

3. All examples given in this Standard are intended to be used only as illustrations of possible approaches.  Implementers are not required to follow the examples.

 

4. This Standard applies to the HIPAA transactions for covered entities.  Payers who carry other lines of business (e.g., property and casualty) have the leeway to implement this Standard at their discretion.

 

5.This standard requires minimum compliance with CORE rules 154, 258, 259 and 260.  These rules can be accessed at:  http://www.caqh.org/COREv5010.php.

 

6.A trace number (2000C or 2000D TRN) is required on both the 270 Request and 271 Response.

 

7.   For the purposes of this Standard:

  • the word “payer” is used to indicate the larger parent organization of the health insurance payer;
  • the words “plan”, “policy”, and “group” (when used in the payer context) are used to indicate specific benefit groups offered by the payer;
  • the word “group” (when used in the provider context) is used to indicate the larger parent organization of the health care provider; and
  • the words “warm body”, “individual site”, or “individual provider” are used to indicate specific providers or locations offered by the group.

 

 

 

 

 

 

 

 

 

I. PROVIDER-PAYER MINIMUM INQUIRY/RESPONSE DATA STANDARD:

 

Provided that the X12 005010X279A1 Implementation guide requirements are met, payers can respond with more information if they wish.

 

Search Options Based on the front matter of the 270 Implementation Guide Sections 1.3.8:

 

Required Patient Search Options

If the patient is the subscriber, the maximum data elements that can be required by an information source to identify a patient in loop 2100C are:

Patient’s Member ID (or the HIPAA Unique Patient Identifier once mandated for use)

Patient’s First Name

Patient’s Last Name

Patient’s Date of Birth

If all four of these elements are present the information source must generate a response if the patient is in their database. All information sources are required to support the above search options. If the patient is a dependent of a subscriber, the maximum data elements that can be required by an information source to identify a patient in loop 2100C and 2100D are:

Loop 2100C

Subscriber’s Member ID (or the HIPAA Unique Patient Identifier once mandated

for use)

Loop 2100D

Patient’s First Name

Patient’s Last Name

Patient’s Date of Birth

If all four of these elements are present the information source must generate a response if the patient is in their database. All information sources are required to support the above search option if their system does not have unique Member Identifiers assigned to dependents.

 

Required Alternate Search Options

Patient is Subscriber

If the patient is the subscriber, the maximum data elements that can be required by an

information source for a Required Alternate Search Option to identify a patient in loop

2100C are:

 

Member ID/Date of Birth/Last Name Search Option

Loop 2100C

Patient’s Member ID Number

Patient’s Date of Birth

Patient’s Last Name

 

Member ID/Name Search Option

Loop 2100C

Patient’s Member ID Number

Patient’s First Name

Patient’s Last Name

 

Patient is Dependent

If the patient is a dependent of a subscriber, the maximum data elements that can be

required by an information source for a Required Alternate Search Option to identify a

patient in loop 2100C and 2100D are:

 

Member ID/Date of Birth/Last Name Search Option

Loop 2100C

Subscriber’s Member ID Number

Loop 2100D

Patient’s Date of Birth

Patient’s Last Name

Member ID/Name Search Option

Loop 2100C

Subscriber’s Member ID Number

Loop 2100D

Patient’s First Name

Patient’s Last Name

 

Optional Alternate Search Options

In the absence of all of the above pieces of information, such as in an emergency situation or if the patient has forgotten to bring their identification card, a 270 may be sent with as many of the above pieces of data that are available as well as any of the other items identified in the transaction (such as Social Security Number, subscriber’s name when the patient is not the subscriber, relationship to insured). The information source should attempt to look up the patient if there is a reasonable amount of information present. An information source may outline additional search options available in their trading partner agreement; however under no circumstances may they require the use of a search option that differs from the ones outlined above.

 

Insufficient Identifying Elements

In the event that insufficient identifying elements are sent to the information source, the information source will return a 271 identifying the missing data elements in a AAA segment.

 

Multiple Matches

In the event that multiple matches are found in the information source’s database (this should be due only to utilizing a search option other than the required search option), it is recommended that the information source should not return all the matches found. In this case, the information source must return a 271 identifying duplicates found in an AAA segment, and in another AAA segment identify the missing data elements necessary to provide an exact match.

 

Third Party Payers/Coordination of Benefits

Other payer Information is required to be sent to the requesting entity when known.  The payer name as minimum should be sent.  It is the responsibility of the inquirer to verify the coverage with the other payer.

 

 

 

 

 

 

 

Providers systems must have the ability to detect or display all information sent in the 271.  If the information sent in the 271 response will affect data content in subsequent transactions for this subscriber or dependent, it is recommended the provider use the information returned.

 

If possible send the link to the Benefit Summary document for the plan if it resides on the payer’s web site.  This could be sent in the MSG segment of the EQ Loop. Codified information should never be sent in the MSG Segment of the transaction.

 

Required service type codes are detailed in CORE rule 260 section 6.1.  This rule can be found at:  http://www.caqh.org/pdf/CLEAN5010/260-v5010.pdf.

Additional service type codes required by this standard are detailed in Table 1.  Payers must provide a specific benefit response for all codes required by CORE rule 260 and those additional codes found in Table 1.  Payers may use the III Segment to further define the place of service for these service types.

 

Table 1

 

EQ01/ EB03 Code

 

Code Name

CC

Surgical Benefits – Professional (Physician)

DM

Durable Medical Equipment

54

Long Term Care

56

Medically Related Transportation

59

Licensed Ambulance

98

Professional (Physician) Visit – Office

PT

Physical Therapy

 


II. RECOMMENDATIONS:

 

The points in this section are recommendations for payers to consider in setting up their eligibility systems.

 

  1. Benchmark: It is recommended that whatever information is given over the phone in eligibility responses by the payer is also given in the 271 for general benefit inquiries (see Levels 0, 1, and 2 above).  Payers should work to assure that similar information is given in both the electronic and manual eligibility systems.  If payers give more information in their manual systems, providers will be inclined to use those systems over the electronic systems.

 

  1. Multiple Matches: If an inquiry results in more than one subscriber/dependent match in the payer’s eligibility system, the payer should reply that multiple matches have been found and the provider needs to supply either additional or corrected information.  Payers should not give coverage information on the multiple matches.  Providers are encouraged to give as much information as possible on the patient and subscriber to reduce the incidence of multiple matches. 

 

Example:

Use the AAA in the 2100C or 2100D loop

AAA*Y**68~

AAA01 = Y (Y would be used because the request is valid but is being rejected for the reason indicated in AAA03)

AAA03 = 68 (Duplicate Patient ID Number).  The message here is that the information SOURCE found more than one patient matching the information in the INQUIRY.  AAA03 could = 76 (Duplicate Subscriber/Insured ID Number) if the duplication was with the subscriber information.

 

In the case of multiple matches:

Use multiple 2100 AAA segments.  In the example below, the problem lies with the patient name.

 

AAA*Y**68*(this indicates that multiple matches have been found)

AAA*Y**15~ (this indicates that data was missing or invalid)

AAA*Y** 65*C~  (this indicates that the Patient Name is missing or invalid in the original inquiry Code 65 = Missing/Invalid Patient Name. AAA04 (code C) indicates that the payer wants the provider to correct and resubmit the inquiry with Patient name.

 

The payer could indicate problems with IDs (AA03 could = 72 Invalid/Missing Subscriber/Insured ID, or 43 Invalid/Missing Provider Identification, etc) or a host of other types of problems. 

 

  1. Window of Eligibility Data Availability:  The window of eligibility data availability should equal that of the claim filing deadline for the payer.  If a payer has a claim filing deadline of 12 months, then 12 months of eligibility data should be maintained in the on-line eligibility system.

 

  1. Window of Eligibility Inquiry Date Spans.  Payers should develop a policy of the maximum date span range for eligibility inquiries. The maximum date span indicates the longest inquiry date span which the payer will consider a valid date span.  For example, a payer may consider a single month (30 days) to be the maximum date span for a valid eligibility inquiry.  Payers should communicate this policy to providers.

 

  1. Eligibility Date Spans. It is recommended that payers provide more than one separate response when inquiries span benefit periods.

 

  1. Contract/Outsourced Payer The name as minimum should be sent for chiropractic, dental, vision and mental health benefits etc. when the payer outsources the benefit.

 

See Part II and Part III for more complete inquiry and response examples.

 

 

History: (MM/DD/YY)

 

Original V2

A* 2.1

A* 2.2

A* 2.3

A* 2.4

ORIGINATION DATE

12/08/99 

9/2003

03/12/03 

5-06-05 

1/2008

APPROVAL DATE

04/11/02 

09/09/02

5/12/04 

05/02/07

05/02/08

EFFECTIVE DATE

05/11/02 

10/09/02 

6/12/04 

06/02/07

06/02/08

 

 

V3

A* 3.1

A* 3.2

 

 

ORIGINATION DATE

04/14/09

4/4/2011

9/18/2012

 

 

APPROVAL DATE

12/02/09

5/18/2011

2/6/2013

 

 

EFFECTIVE DATE

01/02/10

6/18/2011

3/6/2013

 

 

 

* A = Amendment

 

 

 

 

 

 

Leave a Reply

You must be logged in to post a comment.