In 1996 the US Federal Government passed the Health Insurance Portability and Accountability Act (HIPAA) which among other goals sought to regulate speech and the way providers talk to their payers and vice versa. What resulted was a industry-insider developed electronic specification that was forced upon every actor to adopt it. Like all technology laws that are now over 20 years old, they lag behind the latest technology practices since innovation has been outlawed as an unintended consequence. What results is a situation where only the most determined and entrenched players, many of whom sit on the committee who builds and manages the specification, are able to work with it. Below is but a smattering of grievances that truly compound the problems with healthcare:
Imagine a scenario where one must bill their home insurance company hundreds of thousands of dollars for a fire loss but are unable to attach any supporting documentation to the items and services they are seeking reimbursements for. Imagine further that the home insurance company is required by law to initially accept this woefully inadequate government-mandated claim form they are unable to use to make a coverage decision and are then forced to weeks later seek additional information through the post office. This describes the initial claim submission process in healthcare. Although the specification did contemplate attaching “Paperwork” items to a claim, in practice it’s merely a list of control numbers and communication methods that are supposed to accompany the claim like a fax or a letter in the mail. Think of it like sending an email that prohibits attachments but in the body of the message there is a footnote saying that a piece of mail will be arriving next week with the attachment. Our experience reveals most payers ignore these or are otherwise unable to correlate the electronically submitted claim to the physical paperwork that was mailed or faxed.
If one wishes to communicate to a payer using the mandated specification, they are going to be paying a lot of money for it. The committee which develops and maintains the specification required to perform basic functions like submitting a claim or checking on a member’s eligibility is also the one who sells it. A quick look on X12.org’s website reveals that purchasing the HIPAA documentation and schema pack, along with the separately bundled but required acknowledgement package, will run a single developer license over $10,000 dollars. If one wishes to make money with their usage of their specification or would like additional developers to work on the project, expect to pay much more money.
As opposed to a human-friendly data format, the EDI ASC X12 specification is a human-hostile one where someone unfamiliar with the schema is unable to make any sense of what is getting transmitted over the line. Even those who are proficient in this format and the specification it is implementing will encounter many challenges troubleshooting it and likely will require another piece of software to parse it for them. Originally developed back in the 1970’s, this data format was designed to reduce bandwidth and lower the memory requirements of implementing systems of that era using it. The advent of far more powerful computer systems have resulted in more human-friendly data formats such as the nearly ubiquitous JavaScript Object Notation (JSON) or even an XML WSDL. Continuing the usage of this standard limits the number of people willing and able to work with it and contribute to the healthcare industry.
Speaking of things developed in the 1970’s, the File Transfer Protocol (FTP) is a network protocol used in this industry to transfer data between a provider’s health system and a payer’s. Fortunately clearinghouse vendors have stepped up to add a wrapper around this process by concealing this behind a modernized REST endpoint (hopefully). However, weaknesses with this implementation are expressed through the clearinghouse's technology when transmitted claims are successfully received by the clearinghouse but no response is returned from the payer. Many times provider systems have to just “guess” if the payer has acknowledged the transmission and if they have not after a couple days the preceding practice is to just send it again and hope they pick it up this time. Yes, it’s that bad and a contributing culprit is the transfer protocol.
When transmitting an electronic document to a payer, there exists a national standard of payer ids which are supposed to directly correlate with the payer whom the practice is trying to communicate with. However this is not always the case due to what can only be speculated as problems with existing payer systems getting acquired by other ones and the inability from a technical level of getting everything all under the umbrella of the acquiring entity’s infrastructure. I’ve been told to not name names, but just because a member’s card indicates “Healthcare Co, Inc.” could easily mean several different potential payer ids that it could be sent to. Additionally, some payer systems will require providers to send certain documents (such as an eligibility check) to one payer id and send other documents (such as a claim) to a completely different payer id.
Clearinghouses are third party vendors that create a simple unified wrapper around every payer’s endpoint to present a single endpoint where data can flow. So instead of having to manage 1000 different payer endpoints, a clearinghouse can be leveraged to provide 1 endpoint that direct traffic behind the scenes to the correct payer endpoint. However, lest we forget, HIPAA was supposed to enact a data standard where interoperability between systems was achieved, essentially eliminating the need for speciality vendors to manipulate data to make them compatible with various systems. In practice, unfortunately, each system that implements the wildly complicated specification does so in slightly different ways rendering that effort null and void, harkening the way for awkward middle-man clearinghouses to continue to exist and flourish.
As mentioned above, each system that uses the mandated specifications do so in slightly different ways. Some opting to ignore large swaths of the guidance entirely for reasons that truly confound me, some portions they chose to omit are incredibly important for things to work correctly. For example, when submitting a claim typically one will include control numbers so that when the payer completes its adjudication of the claim the response can be correlated back to the originally sending documentation. This causes problems for a practice who will then need to find other more exotic methods of posting the response back to the originally submitted claim.
High availability is something that does not exist within the healthcare payer infrastructure. We have found that there are certain maintenance periods with many payers running certain types of software where the entire system shuts down for maintenance. For certain document transmissions this isn’t the end of the world such as claim submissions as the clearinghouse will usually attempt to send it again at a later time when it is open. But other transactions, such as real-time eligibility checks to see if a given patient has active coverage, it is a critical component to every practice.
Prior to the mandate that these documents be transmitted electronically there existed paper claims that practices would fill out and mail/fax to the payer. These documents, contrary to what the law required, are used constantly for appeals and follow-ups to this day (see issue #1 in this list). The problem with them is that these paper documents both omit and include data from the electronic specification. When a practice is forced to “drop to paper” because the electronic specification failed for some reason, data is lost. This typically happens when there are multiple payers in a coordination of benefits (CoB).
Most payers require some sort of authentication process take place prior to giving a practice the ability to transmit data to them. Many modern approaches to this classic problem have been solved using a single sign-on (SSO) method where a trusted source who holds the necessary info passes it along to the implementing application (sign in with facebook is a good example). In healthcare, we are not as lucky. Filling out the enrollment paperwork, mailing or faxing it, and waiting for a response to only being denied and starting over is just the beginning of the horrors that are in this process. Many times it includes having to go to multiple websites to get the payer set up, calling the payer to get updates as to where the application is at, and tracking down the original person who set up the enrollment account years ago are other complicating pain points. It can take months to get things set-up all while there are claims that are waiting to be transmitted and approaching their timely-filing limits.
After a claim has gone through a payer’s adjudication system they will always send the results of it to the provider (as well as the patient) detailing what was covered and what wasn’t. Technically described as an EDI 835 document, all payer systems we have encountered can only send this to one digital recipient. Imagine a scenario where a practice needs to switch to a different billing provider. After doing so, the new billing provider is not receiving these EDI 835 documents because the previous biller is still receiving them. Only after enrollment is completed will there be any hope of stopping this. Once stopped, the practice will now need to track down what was sent incorrectly to the old company and get it corrected. This is why Enter offers a $1M cash flow protection program to ensure the cash flow of a practice is stable while switching takes place.
Many times there exist reasons why a claim that was submitted to a payer needs to be amended or changed in some way. Some of the largest in the payers in the country do not support sending what is technically described in the specification as a replacement. If an electronically transmitted claim needs to be changed or edited in some way, an adjudication result will first need to be received and then a paper corrected claim sent by fax or mail will need to be sent and followed-up on.
Many times a patient will be covered by multiple insurance plans as a result of their spouse, their work, the person who rammed them with their car, a supplemental plan, workers compensation policy, the list goes on and on. When electronically transmitting a claim, all relevant parties are included in the claim. According to the specification, there are two options available. The first option is that the provider will be responsible for sending the claim to the primary payer, receiving a response, then sending everything to the secondary payer, receiving a response, and then sending everything again to the tertiary payer, and receiving a response, repeat as necessary. The other option is to tell the first payer that when they have completed adjudicating the claim, they are to forward it automatically on behalf of the provider to secondary, who will then forward it automatically on behalf of the provider to tertiary. In practice, it simply doesn't matter which option is selected. The payers are going to do what they are going to do which causes unique claim workflow problems.
Just because a payer offers an electronic connection doesn’t mean it offers all the electronic documents as mandated by HIPAA. It is very typical to encounter a payer that may offer eligibility checks but will not offer the ability to receive claims. Others may offer to receive claims electronically but will not send payment information electronically when claim adjudication completes. Many payers will require a hybrid approach of both electronic and paper solutions to get the job done.
Ultimately, only a dedicated team with specialty software that addresses the many pitfalls that are encountered with electronic submissions will ever stand a chance at successfully billing insurance for all that they owe. Enter is here to take away this burden and let practices to get back to serving patients.
Sign Up for Our Newsletter
Discover the latest in RCM