The HIPAA Claim Status Responder

 Top  Next

The status of claim, whether it has been paid, rejected, pended, adjudicated or lost is of eminent importance in the commerce between a health care provider and an insurance company paying for the services of their policy holders. Providers need to be assured that they have a proper cash flow and that problems with claims are quickly identified, rectified and the claims resubmitted. That is the reason why a considerable part of the staff in a hospital or doctors office does billing. If a provider misses payment on a particular claim or has questions regarding the adjudication they will have to contact the payer and ask for the status.  Traditionally this has been handled by telephone operators or voice response systems with fax back options. And all too ofter this consists of being on hold large parts of the day to get information on a particular claim. This is time consuming and pushed many doctors to the point of giving up the solo practice.

 

HIPAA (Health Insurance Portability and Affordability Act) was conceived to bring administrative simplification into the provider-payer relationship and was intended to lower the costs of doing business for payers and facilitate the communications between payer and provider. The HIPAA legislation of 1996 addressed this critical bottleneck of commerce and prescribes the 276/277 EDI transaction set as format for electronic transmissions of claim status requests and responses. The law prescribes this particular transaction set as a mandatory transaction, this means that covered entities have to use it when asked to in order to convey claim status information electronically. Unfortunately 12 years after the HIPAA transaction sets were mandated we have still only spotty performance by payers in their ability to produce meaningful claim status responses.

With the Affordable Care Act, aka Obama Care the CORE Phase II requirements were adopted and it has become obligatory for health plans to provider such claim status responses within seconds using SOAP or MIME communications protocol and as long as this act is not repealed we will see increasing compliance with law by payers and the need for every payer to participate in the electronic exchange of claim status information.

 

The HIPAA Claim Status Responder gives payers the ability to produce 277 responses to 276 requests

Here its working mechanism in short:

•A provider requests the status of a particular claim and creates a 276 EDI file.
•The file is transmitted via a clearing house, an FTP server or a SOAP or MIME Server
•The HIPAA Claim Status Responder reads each individual request and
oSearches the HIPAA Claim Master database for the claims with added status information
oSearches a set of Tables that just contains the necessary information for the response
oAllows to manually create the response
•The response is packaged into a 277 EDI file
•Returned to the provider

 

Together with the EDI Exchange module all EDI protocols requirements will be handled such as the Functional Acknowledgment (999), encryption and FTP transport and in conjunction with the HIPAA RealTime Server even CORE Phase II compliance and all the requirements of the ACA can be fulfilled.

Tying in a claim systems into the HIPAA Claim Status Responder for automatic responses is a straight forward job.

 

1.The claims are coming into the system with the HIPAA Claim Master and are stored in the claim header and detail table. Extra fields are added to those tables to store the status of the claim. The HIPAA Claim Status Responder looks for the claims, looks for the status information and returns it back. If there is no status information a default status is given, if the claim is not found another code is returned. A nightly process updates the table.

 

2.The claim status information is stored in independent tables that just contain the necessary fields of the claim. A nightly process updates the table.

 

3.Manual response. Compose the response in a screen by looking up the claim in a legacy system and transferring the information into the claim status response. If the volume of 276 requests is low or even non-existent, then it would be sometimes unwise to spend money and resources on the automatic handling of claim status requests.