Take those standards with a grain of salt
Over the years, we encountered many situations where hospitals and medical billing companies were using large, complex, often outdated systems. Though some of them were quite content with the existing functionality, the main problem was to make changes whenever a new industry regulation emerged. Some of the worst such situations were related to the electronic claim filing (EDI 837) and electronic remittance processing (EDI 835) implementation. For instance, a lot of companies faced a huge problem when some of the Medicare carriers stopped processing paper (HCFA) claims and required the usage of EDI 837 only. Or as a more recent example, one may consider the fact that the usage of NPI numbers became mandatory for the majority of the EDI 837 processing during the past few years.
EDI 837 specifics
HIPAA compliance requires ANSI X12 EDI standard, which is good, because it should make everyone conform to the same rules. However, the whole medical billing process is quite complex and the standard allows you to do the same thing in several different ways. For example, when sending a batch of claims through the EDI 837, you may decide to send a separate file for each group or provider, send a single file with many different transaction sets, or send a single file with all the different providers and groups defined via the EDI 837 specific billing provider HL loop. The problem may occur, for example, with certain companies not accepting your choosen solution due to their own software problems and thus forcing you to comply with their own rules.
Clearinghouses & Claim Separation
You could possibly decrease the number of these specific requirements (and thus the amount of work needed to implement it in your software) by having as less different recipients as possible. The ideal solution would be to pick a single clearinghouse and send all claims through it, but there are not that many clearinghouses which can process all payers and their services are usually very expensive. Thus the majority of our clients prefers to send files to multiple clearinghouses, which are either cheaper or free of charge (free ones are usually the government carriers like WPS for example, which handles the Medicare part B for the states of Illinois, Michigan, Minnesota and Wisconsin). This has a significant impact on the EDI 837 functionality. It means that it's up to your software to deliver the claim separation logic, which splits your data according to the different recipients and sends a separate EDI 837 file for each of them.
About EDI 835
As for the EDI 835, its processing may look simpler since there are not that many specific issues related to different payers, but it is more prone to errors because what the insurances report may not be exactly what you have in your system (by the time you get the 835 file from an insurance, your data entry personnel may have changed something, etc.). This usually requires some sort of validation process upon receiving the EDI 835 file, where its data is matched with the data from your system.
The payer specific issues, although not that common as with the EDI 837, still may appear. We've seen examples of different payers reporting secondary adjustment amounts and reason codes in a different way. We've also had clients which successfully implemented the basic EDI 835 processing in their own software, but had problems with how the interests or late filing adjustments were reported.