By now everyone in Healthcare is aware of the Health Insurance Portability and Accountability Act (HIPAA) of 1996, HIPAA Electronic Data Interchange (EDI) Transactions and Code Sets, the American National Standards Institute (ANSI) 4010, and 5010.  The EDI standards and definitions have certainly made it a lot easier to exchange certain types of data between organizations, but what happens when the standard transmissions are not always standard?  What I really mean by this is, although a standard exists, there seems to be a lot of flexibility built into it and room for interpretation, such that two claims for the same service from different providers don’t always look the same.  Likewise, remittance advice from the payers varies from payer to payer.   Although there are differences, sometimes significant ones, they are all considered standard, for the most part anyway.

Dealing with these differences can sometimes be daunting.  From the provider side, you may have a system that always outputs 837s (i.e., claims) in a similar format; however, some payers may have different requirements.   On the remittance advice side, no two payers seem to produce a similar 835.  Some provider financial systems allow for these differences, some don’t.  Some providers use an EDI interface system (sometimes referred to as a claim scrubber) that may provide the ability to customize claims for certain providers and the ability to normalize inbound 835s.  Some clearing houses will provide this service for you.  However, with all this being said and all these options, many times providers are just plain stuck when it comes to certain payers; resorting to sending paper claims to certain payers, posting cash manually from paper remittance advice from other payers, or paying huge fees for conversion processes.

On the remittance side, you will find such things as:

·         Multi-facility 835s not being handled appropriately by your financial system.

·         Secondary remittances causing credit balances.

·         Denials causing accounts to zero out instead of leaving a balance for follow-up.

·         Zero payments being broken out into separate “no pay” checks requiring you to post each one in a separate batch instead of one batch containing all the zero pays.

·         New segments magically creeping into your 835s that your system can’t handle

·         Remapping of reason codes and group codes.

·         Etcetera.

Forefront has developed a tool set to allow us to easily deal with these types of issues and more.  Some of the services we can provide are:

·         Pre-processing of 835s normalize the data.

·         Splitting into multiple 835s for different systems or facilities.

·         The creation of 835s from flat files and spreadsheets.

·         The creation of 835s from paper remittance advice.

·         Denials tracking and reporting.

·         And more.

Similarly we’ve seen issues with 837s that need addressed too, although not as prevalent.  We’ve seen cases where data coming from ancillary systems needs to be populated into claims for which most core financial systems have no way of accommodating.  Forefront’s tool kit also enables us to easily handle these types of situations too.

Related Articles: