The Eligibility Transactions

Top  Next

The Health Insurance Portability and Accountability Act (HIPAA) of 1996 prescribed the 270 and 271 X12 EDI transactions for the transmittal of eligibility data. Checking the eligibility of insurance coverage is an essential operation in health care. Doctors should know by the time they see a patient whether the patient is covered, if there are co-payments to be collected and whether coverage for a certain diagnosis is included.

The 270 EDI transaction is the request for eligibility information. Typically a provider would take the patient information and then compose the request message. He would then expect a 271 EDI response message. EDI transactions that begin with a '2' are real-time transactions. That means that the response is expected within 20 seconds.

HIPAA implemented this differently at first and did not mandate real-time responses for any transaction. Having  the response by 7 am the following day was acceptable. The Accountable Care Act (aka Obamacare) tightens this requirement.

Nevertheless, in planning your HIPAA solution you should strive for real-time execution of the 270/271 as well as the 276/277 claim status information.


What is a response?

The basic functionality between 270 and 271, between the request and the response is important to understand. Though request and response should be linked, this is often not possible and a generic answer is returned.

Here are some different scenarios:

Manual Mode:

1: Provider has a generic request asking for service type code 30. (health plan coverage) This seems to be the encouraged version by the implementation guide. We can give a

 a) Quick response with service type code 30 and optional dates

 b) Rejection for different reasons

 c) Detailed response listing all available benefits

2: Provider is specific and has a detailed request. Maybe he/she specifies procedure codes and diagnosis and has inquires about several benefits employing multiple loops 2110D or 2110C. This is the idealized case on the request. If the request is the same for several service type codes, they can be repeated within EQ_01. For the response we can have several scenarios:

 a) Quick response. Yes, you can even on the most detailed request just give a quick response and get away with it

 b) Rejection        

 c) No matter how complex the request, you create your standard response, listing all available benefits

 d) Each loop 2110C/D in the request is answered in detail with a loop 2110C/D in the response. The EB_03 segment of the response mirrors the EQ_01 segment of the request.

         i) Single service type code in EQ_01 <-> Single service type code in EB_03, one request loop answered by one response loop

         ii) Single loop with Multiple service type codes in EQ_01 <-> answered by multiple service type codes in EB_03, one request loop answered by one response loop

         iii) Single loop with Multiple service type codes in EQ_01 <-> answered by multiple loops 2110C/D, each service type described as needed


The HIPAA Eligibility responder is able to serve all these scenarios, but, we should be clear that case 2.d.ii and 2.d.iii can get infinitely complicated and complex and should be avoided. 


The quick response is the easy way out. We support it for sure.


The most common case in the industry is 1.c and 2.c; No matter what the request, simple or complex, the response lists all the available benefits and their limitations as specific as possible.


Case 2.d.i is possible for a trained and dedicated  case worker to provide a very specify response with the HIPAA Eligibility Responder but it will take time to get efficient and gain a deep understanding of the process.


We spent  a lot of thought on the matching of EQ_01 to EB_03 (Service Type Codes) requirements. We won’t limit the software to this case alone. EB_03 does not have to match EQ_01 and you should be able to change the Service Type Code. The EQ_01 value is pre-loaded on the response form into combo box. We can have requests with multiple EQ loops but we won't have to answer them all.



No matter what the request, simple or complex, the response lists all the available benefits and their limitations as specific as possible.

This motto will be the case in the Auto-Process especially. The computer cannot make diagnosis and procedure specific decisions.

One of my objectives for the development of the HIPAA Eligibility Responder is to provide an automated process with an easy configurable interface, so that these real-time transactions can be automatically returned within seconds.


You might have seen the database menus. That’s part of this development and the following is for your information.

The HIPAA Eligibility Responder will query a database table “ACTIVE.MEMBERS”  where the covered members and dependents are listed. Just 10 fields or so to uniquely identify the member and match the request with certainty. This members table is linked to the defined benefits. It will be updated daily by the Administrator.


HIPAA Eligibility Responder reads the request
finds the subscriber and/or patient if different and gets a link to the benefits.
Then it returns all defined benefits or returns a rejection :AAA rejection code when the member is not found for example.


There are three ways to link to benefits:

1.Our users have to pre-define benefits  and the ActiveMembers table has a  field that contains a list of those benefits
2.The member ID is the foreign key to the DefinedBenefits table  and each member’s benefits are populated together with their defined benefits in an upload
3.The ActiveMembers file has one 255 byte field which contains an EDI string with the benefits. Customer has to write his own logic to formulate benefits in the 271 format. All business logic is under the customers control within a stored procedure that returns either AAA or the benefit segments.