Presentation is loading. Please wait.

Presentation is loading. Please wait.

Don’t Get with 5010 Presented by Gretchen Beicher UW Medical Foundation April 3, 2009.

Similar presentations

Presentation on theme: "Don’t Get with 5010 Presented by Gretchen Beicher UW Medical Foundation April 3, 2009."— Presentation transcript:


2 Don’t Get with 5010 Presented by Gretchen Beicher UW Medical Foundation April 3, 2009

3 Clinical practice organization for the faculty physicians of UW School of Medicine and Public Health The Medical Staff of over 60 clinical practice locations throughout Wisconsin Largest academic, multi-specialty physician group in Wisconsin 837 = 87% -- > 837P

4  Version Payments  Version /271 – Eligibility  Providers  Payers

5  Claim Status code list has changed significantly. Claims Status Code location at CLP02 identify the status of the entire claim as assigned by the payor. Claim status code 4 - Denial definition changed Codes removed from list Notes added for clarifications. 835 Remittance A dvice

6 Provider  Redefinition of Claims Status 4 will make it more difficult for the provider to distinguish between a true denial or claims with high deductible amounts.  Claim Status Code 4 should only be used when the patient cannot be found on the payer system. 835 Remittance A dvice Claims Status Codes Payer  Payer should know whether or not they are primary. Multiple coverages may make this difficult to determine.

7  Allows for the provision of a technical contact and the payer’s website where further policy information can be found. Not required. 835 Remittance A dvice

8 Technical contact Provider  Would have to make changes to accept and store the information  Would be great to have the specific informational policy without making a phone call or researching the web for a possible match Payer  May lead to procedure/workflow changes for supporting inquiries at the technical level.  Policy may need to be on an unsecured website which many payers do not like

9  Allows for Remit delivery data to be provided when both the EFT and 835 are sent to a financial institution. Not Required 835 Remittance A dvice Provider  This is not widely used but serves as an opportunity for the future. Payer  Would require coordination with the bank and some programming changes to provide the destination information of the 835 to the bank.

10  Additional Clarity for Balancing Balancing does not change 835 Remittance A dvice Provider  If interpretations are correct of the 4010, this can be considered an enhancement.  Some have experienced invalid credit balances.  The clarification of items labeled “are and are not” may help in reconciliation issues with the payer. Payer  MUST review how they balance the 835 currently against the enhanced front matter for balancing to ensure that they are following the rules of the transaction set.

11  Claim Overpayment Recovery is Clarified Providers may still elect to negotiate specific methods in their contracts. 835 Remittance A dvice

12 Provider  It does help to know that there is a reversal  It is problematic because method of recovery is left to Trading Partner Agreements.  Provider does not have a voice in recoup method. 835 Remittance A dvice Overpayment Payer  All payers should be aware of the State laws which may govern the method that must be used.  Some states require the payer to give the provider an option upon each occurrence.

13  Remark Code Usage Situational Required when reason code is insufficient to explain denial 835 Remittance A dvice

14 Provider  Very beneficial in reporting for the provider so that an automated determination can be applied to the claim  Will reduce call volume and the need to call for more information. Will reduce call volume and the need to call for more information. 835 Remittance A dvice RARC Usage Payer  This does require programming changes for some and configuration set up for other payers.  Will reduce calls received with requests for clarification Will reduce calls received with requests for clarification The WEDI 835 SWG is creating a uniform list suggesting RARCs to be used with CARCs and CARC definitions and clear scenario- based examples.

15 5010 extends the definition of the subscriber identifier to all downstream transactions. 278, 837, 276/277, /271 Eligibility Provider  Simplifies software rules needed for data capture, storage and exchange  Standardizes subscriber programming across transaction sets Payer  Some payers already assign unique IDs to each family member  May require software changes where payer uses separate systems for enrollment and claims

16 Provider  This could be the single biggest advantage to the providers. Currently many providers require the subscriber DOB on the 837, but do not provider it in the eligibility response for the dependant leading to phone calls, denied claims and appeals. OR paper claims.paper 270/271 Eligibility Payer  This could be the most difficult to achieve requiring significant programming effort 5010 requires eligibility response to include all subscriber/dependant patient identifiers that a payer requires on subsequent transactions

17 Provider  Would require programming to enable upload and storage of data to enable its later submission on claims  Where patient has multiple coverages it could require data storage at the insurance level rather than the patient level 270/271 Eligibility Patient Identifiers Con’t. Payer  May payers apply different edit sets between claims and eligibility  4010 requires only an active or inactive response. To include more will require programming.

18 New required alternate search options using member ID and DOB or member ID and name 270/271 Eligibility Provider  Some payers now require an exact match to patient name. Example: Mary E. Smith claims will deny if Mary Smith is submitted. The alternative search will enable providers to submit ID, patient last name and DOB. Where active coverage is found, the response will provide the name format the payer requires on subsequent transactions Payer  Compliance with the Privacy Rule would restrict response where an exact match cannot be found.

19 Provider  As above some payers require an exact DOB match, yet may have the DOB stored incorrectly. A search using the ID, last name and first would provide the payer DOB. 270/271 Eligibility Alternate Search Con’t. Payer  Significant software modifications would be required.

20  Additional Service Type Codes and Requirements. 45 New Service Type codes have been added. New requirement: If information source receives a STC 30 or one they do not support, 10 codes must be returned if they are covered at the plan level.  1 – Medical  33 – Chiropractic  35 – Dental  47 – Hospital  86 – Emergency Services  88 – Pharmacy  98 – Professional Office Visit  AL – Vision  MH – Mental Health  UC – Urgent Care 270/271 Eligibility

21 Provider  Important in environments where physician and hospital events are covered by different insurers. A generic STC 30 query to a payer would require a response of both 47 hospital and 98 physician if covered. Lack of response on any of the 10 could be interpreted as no coverage for the service type. 270/271 Eligibility Additional Service Codes Con’t Payer  Software modifications will be required in order to report the additional information. Where payers now are required to provide a minimal response (active or inactive), patient responsibility must now be reported.

22 Provider  Ambiguity remains for financial responsibility does not mandate content on response to patient responsibility. Benefits remaining or used are still unknown 270/271 Eligibility Additional Service Codes Con’t Payer  It means a lot more digging into benefits to determine the various types of coverage and report them at a very high level.

23 Requires the return of PCP where applicable 270/271 Eligibility Provider  Excellent change – Provides us with the contact needed to obtain a referral prior to the visit Payer  Same as with the requirements for additional service type reporting. Payers that in 4010 reported the minimum (active/inactive) will need software programming effort to report the additional data.

24 COB Information 270/271 Eligibility Provider  If patients have multiple coverages, providers can query to determine who is primary.  Where the coverage is Medicare or Medicare providing the third party MCO information allows the provider to search the MCO to locate the patient in that system Payer  COB information is not always available or accurate  Programming changes are again needed to report complete information

25 Don’t Get with 5010 DISCUSSION Contact information: Gretchen Beicher

Download ppt "Don’t Get with 5010 Presented by Gretchen Beicher UW Medical Foundation April 3, 2009."

Similar presentations

Ads by Google