<< Click to Display Table of Contents >> Navigation:  Working with Responses > Eligibility Transactions

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.

 

The 270 eligibility request transaction is designed to let a provider transmit patient information that clearly identifies a particular patient and inquires about the policy coverage of the services in question. Multiple benefits can be requested and diagnosis codes can be included. A payer's EDI system would parse out the request, look up the membership records, find its eligibility status and transmit it back with the 271 eligibility response transaction listing existing coverage.

 

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.

 

Auto-Processing:

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.