Expert Advice, Articles & Blogs XiFin EXCELLENCE

11 Real-World 5010 Issues and How to Resolve Them

January 1, 2012

The 5010 conversion has been a challenge for both small and large provider organizations. Payors have also met with difficulties in preparing to receive and process 5010 claim submissions.It would be naive to think that a change of this magnitude would not present a variety of challenges. The key to success is your ability to identify, investigate and resolve those issues and ensure you have the resources available to do those things. CMS can and will audit claims submitted during the enforcement delay from January until March, 2012. The longer you take to get 5010 in production, the greater the consequences.

Since not all payors are ready and the Medicaid payors particularly are falling behind, you must have the ability to send both 4010 and 5010 depending on the payor. It seems that there’s a sharp focus on provider readiness, but payor readiness (or lack of it) is what’s going to cause problems. We believe the burden of conformity is shared but not necessarily equally among providers and payors. Providers stand to go without reimbursement if claims are denied or delayed.


XiFin is and has always been a strong voice and advocate for providers of all sizes throughout its history. XiFin submitted more than one million 5010 claims prior to the January 1 cutover date. Using our surveillance tools, EDI experts and industry contacts we were able to quickly identify, communicate and resolve key claim submission issues. In our recent webinar and an audio conference sponsored by the Dark Report, XiFin experts, Lâle White and Matt Warner were asked to present some key strategies for submitting and getting paid on clean 5010 claims as well as some real-life examples of 5010 challenges and their solutions. As a service to the lab industry and providers everywhere, we are posting a series of real-world use cases for different 5010 challenges and how to resolve them. We hope these examples will help ease the transition to 5010 and serve as a means to minimize the risk of A/R losses, front-end rejections and back-end denials.

5010 Real-world Example #1: Access to Key Transactions, Charging for Mandated Transactions

Situation:
A number of payors are not providing unsolicited acknowledgements (277CA-not mandated)
Medicaid KY charging for access to mandated transaction types (270/271 and 276/277)
Some payors are not making either transaction available
Lack of transaction sets prevents timely discovery of issues.
Resolution:
Be prepared to discuss details with payor’s HIPAA compliance officer
If no resolution with payor, there is an escalation process through CMS


5010 Real-world Example #2: Enrollment Issues

Situation:
Medicaid MN approved 4010-5010 transition, then rejected all 5010 institutional files in production
How XiFin Discovered the Issue:
Files were rejected
When payor switched electronic provider from 4010 to 5010, the provider’s enrollment for electronic transmission was deleted
Resolution
Payor correcting enrollment records
Resubmitting submission files


5010 Real-world Example #3: Missing Acknowledgement Files

Situation:
Never received 277CA for submitted claims. Unable to reconcile what was accepted or why rejected
How XiFin Discovered the Issue:
XiFin surveillance and reconciliation tools alerted us that expected acknowledgment files did not arrive
XiFin EDI Payor Relations team was alerted to missing files
Worked with contacts at Palmetto GBA to identify root cause
Resolution
Short term: Rolled back to 4010 submission to ensure payment to provider
Long term: Palmetto GBA found that the acknowledgement file was being overwritten, and has revised its system. We are monitoring to verify successful fix


5010 Real-world Example #4: Payor Sending Bad Acknowledgment Files

Situation:
Acknowledgement file indicated claim level had been accepted, while specific procedure codes were rejected (claim splitting); in reality, payor doesn’t split claims and whole claim had been rejected (contrary to what was indicated on acknowledgement)
How XiFin Discovered the Issue:
Service lines were missing from 835 remit
XiFin reconciliation process flagged the issue
XiFin contacted Palmetto GBA, who determined files were erroneously marked “accepted,” appears to be “system maintainer” issue
Resolution
Short term: Utilize strength of workflow to identify presence of service line problems, and assume whole claim has been rejected (ignore the bad claim level accept status)
Long term: CMS has to do the fix. Source of the original rejections was resolved, so we’re not seeing these rejections; not clear whether fix is yet in place.


5010 Real-world Example #5: 5010 Eligibility

Situation
Medicaid NY has eliminated preauth file (278) used in 4010 and is now requiring eligibility (270/271) prior to billing instead
Eligibility must be in 5010 format. 4010 not allowed
Having claims ready in 5010 format is insufficient. You MUST be able to do eligibility
Dial-up modem connectivity
How XiFin Discovered the Issue:
The payor’s 5010 implementation covers all transaction sets
Payor requirement identified through companion guide
Resolution
Implement 5010 claim status inquiry/response
Implement 5010 eligibility and connectivity to the payor


5010 Real-world Example #6: Up-Convert Down-Convert Exposes Legacy ID Mismatch and Service Location Issues

Situation
5010 claims through clearinghouse were down-converted but then rejected because payor wanted legacy ID for 4010 which doesn’t exist in 5010
5010 claims through clearinghouse were down-converted, but did not account for payor-specific requirements in 4010 for the service facility location (2310D)
How XiFin Discovered the Issue:
XiFin EDI Payor Relations Team saw rejections from clearinghouses using our surveillance and reporting tools
Resolution:
XiFin EDI Payor Relations Team worked with clearinghouses to find out which payors needed legacy ID, so sent 4010 until payor was ready. You need to know which payors are being down-converted to 4010 by clearinghouse
Clearinghouse can make adjustments to conversion process to include 2310D
Need to be able to submit both formats on payor-by-payor basis


5010 Real-world Example #7: Up-Convert/Down-Convert at Clearinghouse Causes Paper Claims to Reject

Situation:
Submitted 5010 format 837 to clearinghouse that were down-converted to 4010 for print vendor and then sent to payor. Data not present in converted file caused paper claim to be rejected
How XiFin Discovered the Issue:
Payor sent paper claims back
Resolution:
Print vendor not required to process 5010 and down-conversion was not successful
Reverted to 4010, since print vendor couldn’t take 5010


5010 Real-world Example #8: Incorrect 5010 Payor Information

Situation:
Alabama BCBS appeared to be asking for information inside the 5010 file in a manner that is inconsistent with the 5010 specifications
In 5010, payor is looking at rendering provider loop for adjudication and comparing it to their enrollment records
How XiFin Discovered the Issue:
Payor was rejecting files
Specifications do not allow rendering provider loop (2310B) to be sent if it is the same as the billing provider (2010AA)
Resolution:
As it turns out, files were being rejected because of how the provider was enrolled
Need to match NPIs being sent in 5010 with enrollment
Provider is now scrutinizing the rendering provider loop, not just billing loop


5010 Real-world Example #9: Dependent with Unique Subscriber ID

Situation
Claim for dependents with unique subscriber ID
How XiFin Discovered the Issue:
Payors who assign unique IDs to dependents may reject claims with data in wrong field
Resolution:
Providers need to ensure relationship field contains accurate data


5010 Real-world Example #10: Requirements Causing Rejections- Pay To/Bill To Address and 9 Digit ZIP Code

Situation
Billing provider P.O. Box not allowed in 5010 “Pay-To” loop
Real 9-digit Zip Code required for pay to/billing provider/place of service: Edifecs testing (which only validates syntax, format, and structure) allowed 5-digit + “0000” Zip Code
Spaces not allowed for foreign addresses
How XiFin Discovered the Issue:
Pay To/ Bill To: XiFin EDI Payor Relations Team saw denials
9 Digit ZIP Code: Discovered Medicare rejecting claims without valid 9-digit ZIP Code because “0000” is invalid for the + 4
Payor (Aetna) front end rejected file
Resolution
Pay To/ Bill To: Billing Provider should always be a physical address, “Pay To” should only be used if a different remit address is used
9 Digit ZIP Code: Fill-in the +4 data, get information from provider. An up-convert from 4010 will not fill in the ZIP Code
May require additional validation on your billing system


5010 Real-world Example #11: CMS Common Edit Module for NOS Codes

Situation:
Not Otherwise Specified (NOS) codes require SV101-7 segment comment
How XiFin Discovered the Issue:
Claim gets through front end, but gets denied later, empty SV101-7 segment field triggers front-end rejection
Resolution:
If any data is in field, won’t front-end reject. But unless the right data is in the field, could get denied or possibly audited later.

Revenue Cycle ManagementComplianceArtificial IntelligenceFinancial ReportingBusiness Intelligence

Sign up for Blog Alerts