Claim edits in epic

P131 – Billing – Claim Edits Operational Procedure

Revenue Cycle Operations

Revenue Cycle Systems Department

Last Updated 7/31/2018

Table of Contents

1. Overview

2. Purpose

3. Roles and Responsibilities

4. Claims Processing Overview

5. Claim Edits

5

6

5.1 Overview

5.2 Error Codes

6. Types of Edits

6.1 Inpatient Edits

6.2 Outpatient Edits

6.3 Other Edits

7. Integration Between 3M and Epic

8. Resolution of Claim Edits

8.1 Viewing Claim Edits

8.2 Resolving Claim Edits

1. Overview

Claim Edits are used to identify issues with insurance claims before the claims are sent to ePremis and subsequently to the payer. Claim edits are triggered after billing is initiated, during claims processing. Claim edits will prevent claims from being sent out and prompt operational users to resolve errors as necessary. Resolving claim edits is a critical component of revenue cycle operations, as they help to prevent denials which can cause a delay in financial reimbursement for rendered services.

2. Purpose

The purpose of this procedure document is to review the claim edits process at NYU Langone Health including the teams involved, different applications used, and the steps to monitoring and updating claim edits. Additionally, the impact on financial reimbursement will be reviewed.

3. Roles and Responsibilities

3.1 Revenue Cycle Systems (RCS) – The RCS Team is responsible for creating new claim edits and updating existing claim edits in Epic. The RCS Team receives requests for these to be built based on requests received from Revenue Cycle Operations.

3.2 Revenue Cycle Operations (Billing Office, Revenue Management, Revenue Initiatives) - Revenue Cycle Operations teams send requests to the RCS team for review and implementation. These requests can include new edits or modifications to existing edits. In addition to new requests or modifications, Revenue Cycle Operations is responsible for the resolution of claim edits and ensuring clean claims are sent to the payer to prevent denials.

3.3 Health Information Management team (HIM) - HIM plays an integral role in claim edits due to their responsibility in coding accounts. Much of the information that is coded on an account is included on the claim.

3.4 Center for Medicare and Medicaid Services (CMS) – The Center for Medicare and Medicaid Services is responsible for releasing new claim edits in order to promote national correct coding methodologies and to control improper coding and therefore incorrect payment on claims.

4. Claims Processing Overview

Claims processing is the process in which the system automatically searches overnight for charges that are ready to be sent on claims, as well as for claims that previously had errors but are now ready to be sent out. At NYU Langone Health, we process claims in Epic. Claims are sent to ePremis and then to the insurance payer. The payer then determines how claims are paid, rejected, or denied. An electronic remittance advice (ERA), details the notice of and explanation of reasons for payment, rejection, or denial of a claim by the payer to the beneficiary.

Claims processing occurs in the revenue cycle after a patient is discharged and coding is complete, once Discharge Not Billed (DNB) errors are resolved, and billing is successfully initiated. When billing is initiated on an account with no errors, the claim is added to the claims queue.

4. Claims Processing Overview (cont.)

A claim run created during claims processing checks all claims in the queue for errors. If there is an issue, the system will flag the claim with a claim edit. Claim edits are routed to Claim Edit workqueues for review based on the type of error –master file or user error. After claim edits are resolved in a workqueue, they re-enter the claims queue in the process to be sent to ePremis.

5. Claim Edits

5.1 Overview

Claim edits check for inaccurate or missing information on claims that might cause a denial of financial reimbursement. These edits can be industry-wide, specific to a payer, or an organization. When claims are processed, at NYU Langone Health, the claims are configured and checked for errors based on settings specified in the Claim Definition File (CDF). Claim edits are built in Epic within each CDF by the Revenue Cycle Systems team. We have 12 main payer CDFs where these edits are stored, 6 of which are specific to Cancer Center. The RCS team builds the custom edits, CMS regulated edits, payer specific edits, and/or 3M Edits that are stored within the CDFs. It is important to note that many of these edits are repeated throughout the CDFs, where they are applicable to multiple payers. Conversely, other edits may be payer-specific and therefore only are stored within one CDF, such as the Blue Cross CDF.

When claims are processed, they are checked for edits according to the claim definition file associated with the plan or payer. The RCS team builds these errors within the CDF. When a claim triggers an edit, it is sent to the claim error pool. The claim error pool is filtered based on Claim Edit workqueues, which are built based on different teams assigned to review each edit check.

C:\Users\tumilt01\Pictures\cdf.png

5. Claim Edits (cont.)

5.2 Error Codes

Error codes are used to group similar edits for follow-up and review by the appropriate teams. Registrars are responsible for fixing registration issues, billers for billing, and coders for coding. These error codes are also used to drive claim edits to claim edit workqueues. A claim can have multiple errors in which case the claim would be present on multiple workqueues owned by different users. This allows the claim edits to be resolved more efficiently, expediting the process of getting a clean claim out the door. The owner of the claim edit would only be responsible for resolving their appropriate edit.

User errors occur when users leave out information or enter incorrect information. Master File errors occur on claims when there is crucial missing information on the claim that should be included based on build in the system, like an NPI or hospital address.

Error codes are categorized by error code group, which relate to a specific error source. User error codes (Level 100-300) are sent to front-end user workqueues where they are reviewed and resolved. Other error codes that are built out in Epic by the Revenue Cycle Systems team are typically sent to back-end teams for review and are often Master File Errors. Master file claim edit errors are sent to the appropriate team’s workqueue for review, which can include MCIT teams such as ADT, SER (Provider), or RCS Team. Some examples of error code edits are shown below:

· 100 Level Error Code –Registration Error; Registrar will review

· 200 Level Error Code – Billing Error; Biller will review

· 300 Level Error Code – Coding Error; Coder will review an error source of

· 400 Level Error Code – Financial Class not mapped in the CDF; MCIT Analyst will review

· 500 Level Error Code – Federal Tax ID or Billing Provider SSN missing; MCIT Analyst will review

· 600 – Claim needs to go through 3M CGS; RCS Analyst will review

· 800 – SPARCS Error; RCS Analyst will Review

5. Claim Edits (cont.)

5.2 Error Codes

Owner

Error Code Group

Error Source

Registrar

100

Registration

Biller

200

Billing

Coder

300

Coding

MCIT Analyst

400

Master File Error

MCIT Analyst

500

Master File Error

RCS Analyst

600

3M Core Grouping Software

RCS Analyst

800

SPARCS Error

It is important to note that the different edits in Epic (DNB Edits, Claim Edits, Stop Bills, etc.) must be properly resolved to prevent future claim edit issues. If a front-end user incorrectly overrides a DNB edit, as the billing workflow continues and claims processing begins, a claim edit may fire on an account and prevent the claim from being sent out. Additionally, overriding front-end edits may eventually cause a claim edit for review by a back-end team.

6. Types of Edits

6.1 Inpatient Edits

At NYU Langone Health, Inpatient edits are specified in the Claim Definition File (CDF). Inpatient claims are not sent to 3M Core Grouping Software for additional edits, and all edits are applied in Epic. An Inpatient Part B claim, however, will be treated as an outpatient claim and will be sent to 3M CGS where edits will be applied.

6.2 Outpatient Edits

6.2.1 NCCI Edits

CMS developed the National Correct Coding Initiative (NCCI), also known as CCI, to promote correct coding methodologies and to control improper coding which often lead to inappropriate payment. The National Correct Coding Policy Manual for Medicare Services is updated annually by the CMS. The NCCI contains two types of edits – PTP edits and MUE Edits.

(i) PTP Edits

NCCI procedure-to-procedure (PTP) edits that define pairs of Healthcare Common Procedure Coding System (HCPCS)/Current Procedural Terminology (CPT) codes that should not be reported together for a variety of reasons. The purpose of the PTP edits is to prevent improper payments when incorrect code combinations are reported.

(ii) MUE Edits

Medically Unlikely Edits (MUE) is a type of claim edit for a HCPCS/CPT code with the maximum units of service that a provider would report under most circumstances for a single patient on a single date of service. All HCPCS/CPT codes do not have an MUE edit. MUE edits were first implemented January 1st, 2007 under the development of CMS to reduce claims error rate for Part B (Medical Insurance) claims. Since October 1, 2011, CMS has published quarterly updates of the MUE edits on the CMS.gov website.

6. Types of Edits (cont.)

6.2.2 Outpatient Code Editor (OCE)

OCE is a type of claim edit used to detect coding errors when the expected reimbursement is being calculated for outpatient hospital claims. The Ambulatory Payment Classification (APC) reimbursement method for paying hospital outpatient services in the United States was developed by CMS to calculate Medicare Outpatient Prospective Payment System (OPPS). APC grouping streamlines claim reimbursement by establishing groups of covered services clinically comparable in services rendered and resources used.

6.3 Other Edits

There are other types of edits that are built in Epic, including DNB edits, custom claim edits, payer-specific edits, or Epic-released claim edits.

· DNB edits are fired on an account when an initiate billing is attempted on an account. These edits hold the account at its current place in the revenue cycle and prevents it from moving forward until the edit is reviewed and resolved. These edits can therefore prevent claims processing from running on an account.

· The Revenue Cycle Systems team receives requests for custom claim edits that need to be built in Epic. These edits can be organization wide and can often relate to a specific team’s workflow.

· Payer-specific edits are provided to the RCS team by Operational teams to be built in Epic. Commercial payers and Medicare have different requirements and therefore there are two different CDFs in Epic to account for the necessary edits. These payer-specific edits can be based on claim format requirements.

· Epic-released claim edits are edits that are included with the system that are standard edits that are often released industry wide to help prevent denials. These edits can be turned on or off and can be copied and further customized as necessary. Some examples of this type of edit are ‘Insurance ID is not specified’ or ‘Patient’s sex is not specified’.

7. Integration between 3M and Epic – Outpatient Claims

5.

6.

7.

7.1 Overview

At NYU Langone Health, Epic is connected to 3M Core Grouping Software (CGS), a third-party application developed by 3M, to automatically send and receive data. When claims processing begins in Epic, outpatient claims are sent to 3M CGS for grouping and calculated reimbursement under the Medicare OPPS reimbursement methodology. Claims are sent to 3M if the plan associated with the account has been set for APC Grouping in 3M by the Revenue Cycle Systems Team. During this calculation, the claim is scrubbed by MUE, CCI, and OCE edits stored within the 3M CGS application.

Once the claim has been scrubbed with edits and reimbursement has been calculated, the data is then sent back into Epic, where the edits are automatically applied. The data is sent to Epic via an Edit Log, which is automatically picked up on the server and then imported into Epic. This Edit Log file contains all of the edits for a particular hospital account or group of hospital accounts. Once the file is loaded into Epic, the edits are applied to the accounts as necessary. This process occurs in ‘Real-Time’, meaning as soon as a claim is created and picked up in a claim run, the information is sent to 3M and the process begins.

7. Integration between 3M and Epic – Outpatient Claims (cont.)

The ‘Real-Time’ process is essential at NYU Langone Health, as it allows for quicker identification of issues and therefore more timely resolution of claim errors. Once the edits have been loaded back into Epic, NYU Langone Health staff can begin resolving edits in their assigned workqueues, thus expediting the claims reimbursement process.

At NYU Langone Health, calculating accurate reimbursement is an essential process. The Health System continues to look for ways to improve the claims reimbursement process. It is important to note that this ‘Real-Time’ functionality did not always exist at NYU Langone Health. The previous set-up involved claims only being sent to 3M on a nightly basis, which resulted in a slower claims reimbursement process. There are ongoing discussions to improve the current process to ensure 3M consistently calculates accurate reimbursement.

8. Resolution of Claim Edits

8.1 Viewing Claim Edits

Operational users can view their claim edits errors and warnings in Epic Hyperspace in either a claim edit workqueue or on the liability bucket. Additionally, claim edits can be viewed within ePremis.

8.2 Resolving Claim Edits

8.2.1 Claim Edit Workqueues

· Fixing the Source Data

Steps:

1. From the Hospital Billing Workqueue List, click the Claim Edit Tab.

2. Double click the appropriate claim edit workqueue, and select the claim for review.

3. Once in the claim record, go to the Claim Edit tab

4. In the Claim Errors section, click the Error Message link which will open the Claim Edit Workqueue Companion.

5. Follow the steps to correct the error.

6. After the error is corrected, close the activity you were working in and click Refresh Claim. If the error was successfully fixed, the error will no longer appear in the Claim Edit activity.

· Fixing the Claim Itself

Steps:

1. In a claim edit workqueue, select a claim record and go to the Claim Edit tab.

2. Click Edit Vals and then click Edit Lines.

3. Select an item on the claim and edit the value. For example, if the Subscriber ID is missing, enter the value.

4. Click Refresh Claim and Close.

**It is important to note that when this option is used, the source data is not updated. This means that any changes made to the claim will not affect any related secondary claims.

8. Resolution of Claim Edits (cont.)

8.2.2 Overriding Claim Edits

If a claim edit cannot be resolved, it may need to be overridden so that the claim can continue through the revenue cycle. A manager is typically responsible for overriding a claim edit.

Steps:

1. In the Claim Edit activity, go to the Claim Errors section.

2. Click the Override link and enter a comment to explain why the override is being performed.

3. Click Accept.

**It is important to note that even though the error is being overridden in Epic, the clearinghouse may still error the claim for that same edit in their system.

8.2.3 Acceptance Rate

The ePremis claim acceptance rate is calculated each day per location by the Revenue Cycle Systems Team. The percentage of accepted claims is calculated by taking the total accepted claims, divided by the total submitted claims, minus the number of claims withdrawn or with a hold code. This reconciliation is completed by an RCS analyst assigned to the Claim Run Report. This analysis is then sent out to Revenue Cycle Operations senior management for review. The acceptance rate is important to the reimbursement process because it allows Revenue Cycle Operations to monitor trends in claim acceptance, and to identify and isolate elevated denials.

15

Applied Sciences

Architecture and Design

Biology

Business & Finance

Chemistry

Computer Science

Geography

Geology

Education