Electronic Medical Record (EMR) vendors may offer insource or outsource billing teams an additional piece of add-on software (as another fee) they claim will give the ability to bill insurance payers. Sold as an integrated solution that can "streamline" the practice and “increase revenue”, in reality it is rarely more than a limited third-party clearinghouse integration they have a financial business relationship with.
At a minimum, getting visit data from an EMR converted into an electronic claim to submit to the payer is just the beginning of a much larger commitment they are signing their prospects up for. Next time going into a sales presentation, ask the following questions to understand the additional commitment such a "streamlined billing process" will be inflicted upon a practice:
Unbeknownst to the healthcare organization, they have just signed up to manage all electronic enrollments, track down fax numbers and mailing addresses of all payers, and committed in developing a robust tracking system that manages all inbound and outbound correspondence against every claim ensuring it falls within timely limits payers impose.
Also known as an Electronic Data Interchange (EDI) 837 connection, many types of payers from automobile to worker's compensation insurance likely will not have an electronic connection with the third-party clearinghouse the EMR vendor has integrated with. Even if there exists an electronic connection to the payer, additional documentation from medical records to rendering provider W9s may be requested by the payer to complete the claim that in almost all cases cannot be sent electronically. Most billing modules will have the ability to generate a paper CMS-1500 or UB-04 claim, but printing, mailing, tracking, proving delivery to the payer, and follow-up processes are a few of the horrors that awaits the team.
Unbeknownst to the healthcare organization, they have signed up to both enroll the practice with every payer that supports electronic payment information passing as well as data recording every single mailed or faxed Provider Explanation Of Benefits (PEOB) for payers that don't.
Also known as an EDI 835 connections, an even larger number of payers will not have the ability to send back this document after they have processed the claim. Instead, they will mail or fax back the PEOB which is the paper equivalent of the electronic document. These paper responses will need to be manually sorted, posted, and processed by the team.
Unbeknownst to the healthcare organization, they have signed up to develop and run the incredibly challenging process of interpreting vague rejection codes and mailed denial reasons by correcting, responding, appealing, appealing again, appealing again again, filing a complaint with a regulatory body, and even suing payers.
After a claim gets transmitted to the clearinghouse who will then forward it to the payer, it will go through a pre-adjudication processing step that may result in a rejection and a post-adjudication processing step that may result in a denial. Although every payer behaves a bit differently depending on what adjudication software they are running, typically a rejection is a validation step to ensure they can find the member on file and that the billed services are valid. If the claim fails this preprocessing step, it will return a rejection in the form of an EDI 999 or an EDI 277CA depending on the rejection. Most EMR billing modules will give only the absolute bare minimum, if at all, what to do with a rejection response. If the claim fails the post-processing step, it will return a denial in the form of an EDI 835 or through the mail as described earlier. Depending on the nature of the denial, further documentation may need to be provided, an appeal may need to be generated after analyzing the problem, or a lawsuit may need to be filed typically in arbitration. It is almost guaranteed a billing module will offer very little if any support for the hundreds of denial reasons that may be returned.
Unbeknownst to the healthcare organization, they have just signed up to develop a chargemaster and interpret every in-network contract that may be in place for adjudication analysis. Additionally, they have also just signed up to manually data enter potentially hundreds of PEOB sheets every day.
Before sending any claims to a payer, a plan must be developed that incorporates what will be billed and what is expected to be paid given many factors including what payer the claim is going to (and if they are in-network or out-of-network), each procedure, each particular rendering provider, each place of service, among others factors that uniquely determine the payment rate. Also known as a chargemaster, once established, each line item that gets adjudicated by the payer will need to be compared against these predefined metrics to understand if there exists an underpayment and if further action is required. In the highly unlikely chance their billing module supports creating a chargemaster that is also capable of running a payment analysis against the adjudication result, how will these be applied for many out-of-network payers that may send their adjudication decisions in the mail (or by fax)? Will the billing module automatically detect, generate, and recommend the next steps needed to resolve the underpayment? Or will the team need to do manual follow-ups that require research and development, printing, mailing, and faxing?
Unbeknownst to the healthcare organization, they have just signed up to become master business analysts and negotiators as well as accounting for and sending payment checks that may need to be sent back to the payer due to an error on their end.
Payers screw up. A lot. Most of the time they try to structure their processes so mistakes result in their benefit but sometimes it sways in the practice's favor and they come knocking down the door to get their money back. This can prove especially difficult if a practice has already spent or distributed the funds to their partner staff. Only a team with impeccable accounting practices that can quickly be queried will be able to effectively appeal these types of clawbacks. Even so, strong negotiation practices need to take place to ensure cashflow is not disrupted in the event of a legitimate overpayment claim. If things are working properly, the practice should already be aware of payer overpayments due to proper chargemaster analysis and be expecting the inevitable audit that they will be performing.
Unbeknownst to the healthcare organization, they have just signed up to follow-up with every payer for every claim they have not heard a response after sending it electronically or through the mail and to either send it again, legally prove it was sent, research the correct payer address it may need to be sent, appeal, complain, and/or sue.
For one reason or another, claims that may be sent to a payer may never get a response at all. This could be the result of a misconfiguration with their adjudication software that simply cannot generate a response from the given claim, a mail delivery issue with the ever-amazing United States Postal Service (USPS) either failing to send the claim to them or receiving their response back to the team, a response getting mailed to a different location the payer may have had on file, some other human error, or a break in the space-time continuum and it totally vanished. Many times a resubmission will result in the payer denying the subsequent follow-up claim due to timely filing delays from the first submission that will require a process that is able to legally prove it was sent to them. Other times the timely-filing proof may come in the form of an electronic proof of transmission form that needs to be generated and attached to the resubmitted claim in the form of an appeal packet - something very few billing modules support. For either reason, a process will need to be developed to handle this inevitable situation.
Unbeknownst to the healthcare organization, they have just signed up to post every payment from a payer back to the bank account ledger to ensure payments have actually arrived as well as constantly tracking and following up with Electronic Fund Transfer (EFT) requests directly with the payer.
Similar to the issues described with no responses above, this situation occurs when a payer responds either electronically or by paper statement (that needs to be data entered by the team) claiming they have made payment but for whatever reason the practice has never received the money. Although payer payments through Automated Clearing House (ACH) rails tend to be very reliable as payers typically have banking partners that are able to receive their EDI 835 documents and create an EFT payment from it, most problems arise where EFT enrollment has not taken place or is not available and checks are mailed or virtual credit cards are faxed. These tend to get lost for reasons described above and only a developed process that utilizes an accounting system capable of posting ERAs or paper EOBs against the banking ledger will resolve this.
Unbeknownst to the healthcare organization, they have just signed up to do patient collections just to track down payments that may have been mailed directly to the patient even when an assignment of benefits have been signed and no patient responsibility exists.
Certain out-of-network payers refuse to honor assignment of benefit agreements their members make directly with the provider which will result in benefit payments getting sent directly to the member (I suspect this is punishment for not being in-network with them but I digress). Typically represented in an adjustment code (but not always), recouping this will require developing a direct invoicing system and customer service skills in order to explain and collect why the money needs to be returned. A variety of payment methods including check and card are basically required nowadays which will require spinning up or seeking out patient invoicing systems and posting that back to the claim.
Unbeknownst to the healthcare organization, they are walking into a trap by trying to use an underdeveloped reporting suite that will not be able to answer most business questions.
The vast majority of billing modules in the marketplace today were developed before modern business intelligence (BI) software was mainstream and will result in headaches and disappointment for your team. Hiring technical resources will likely be required in order to build and maintain a data pipeline from the billing module into a more robust BI tool.
Integrated billing modules that are bolted on to EMRs are relics of old-school software development practices that were trying to solve everything. This monolithic approach had its heyday back when APIs and data interoperability between specialized systems were but a faint fairy tale echoed by the dial-up tone of a 56k modem. Nowadays, healthcare data is being liberated from the EMR through law and through the marketplace where vendors are now choosing to better focus their products on patient care while allowing other specialized software systems to work with theirs to do more specialized tasks such as revenue cycle management.
Enter's Revenue Cycle Management platform and service handles all these situations and many more for the practice using our holistic and technology driven approach to healthcare revenue cycle management that goes well beyond what any EMR's billing module may offer.
Through a quick and easy standards-based integration process we develop with the EMR of your choice, a direct data feed can be quickly established that will pipe the necessary data into our software and automatically process the entire process.
Don't be fooled - there is little benefit these days from your EMR's "streamlined billing module" for your in-house or outsourced teams.