1

The ERA Denial Manager solution allows providers to organize and manage remittance data; helps staff prioritize and

monitor denials and underpayments; and allows accurate reporting and viewing of all denials and adjustments. With

the robust data collected by the ERA Denial Manager, providers are able to streamline the denial management process

by determining root causes of denials, identify patterns and process breakdowns responsible for denials, and establish

corrective steps to prevent future revenue loss or delay of payments.

The ERA Denial Manager is built with workflow in mind. This application as well as the Task Manager application

provides user-defined work queues designed to streamline workflow and help increase revenue visibility. Once the

tasks are created, they can be assigned to specific users within the provider’s organization as needed. Each practice

has a custom list of working payers, Group/Reason codes, and expected amounts to allow users to classify denials as

expected vs. unexpected for reporting purposes, apply prescriptions of action for each code type for further action,

and easily identify underpayments and overpayments.

Benefits

• Easily identify under and over payments as well as their causes

• Quickly identify practice status using a dynamic dashboard

• Reduce future revenue loss or delay

• Route work automatically to appropriate users using customizable tasks

• Manage Line Level Denials

• Track Expected & Unexpected Allowable amounts by Payer and Provider

• Reimbursement across payers

2013 ERA & DENIAL MANAGER

2

Getting Started

ERA Statuses 3

Working Denials 4

Applying Follow Up Actions 4 Monitoring Details Via Tasks 5

Analyzing ERA Data 5

Application Overview

ERA Selection Criteria 6

ERA Selection Criteria - ERA Functionality 8

Transaction List View 10

Transaction List View - ERA Functionality 13

Status Message View 16

Status Message View - ERA Functionality 17

Managing Tables

Manage Expected Amounts 18

Manage Codes 23

Manage ERA Payers 26

ERA & Denial Manager Reports

ERA Dashboard Reports 28

Adjudication Summary Graph 29

Aged Cash Graph 30

DSO by Procedure 31

Denial Rates by Procedure 32

Top 5 Denial Codes 33

ERA Dataminer Reports 34

ERA Denial Analysis 35

ERA Reimbursement Analysis 36

ERA Web Browser Reports 37

Analysis by Reason 37

Analysis by Procedure and Reason 38

TABLE OF CONTENTS

3

GETTING STARTED

ERA STATUSES

The ERA status is made from a combination of the ansi835’s CLP02 claim status code and the amount paid, amount

allowed, and amount submitted for each ERA.

For both Claim-level ERAs, we can only look at the information in a CLP loop, while with Transaction-level ERAs we

have to look at information from the CLP loop, plus information from the SVC loop associated with the ERA. The logic

for determining statuses is similar for both claim-level and service-level ERAs, but we find the values for amount

submitted (CLP03 for claim-level, SVC02 for service-level), amount paid (CLP04 for claim-level, SVC03 for service-

level) and amount allowed (AMT02 on an AMT*AU for claim-level and AMT02 on an AMT*B6 for service-level)

differently.

Paid statuses are set when any of the following are true:

• there is a positive amount paid

• the CLP02 claim status code is 1, 2, 3, 19, 20, or 21 (for processed as primary/secondary/tertiary), and:

o there Is a zero amount paid but a zero amount submitted

o there is a zero amount paid but a positive amount allowed that is not equal to the submitted charge

o there is a zero amount paid but a positive patient responsibility (a sum of the deductible, coinsurance,

and copay adjustments)

Reversal statuses are set when any of the following are true:

• there is a negative amount paid

• the CLP02 claim status code is 22 (for “Reversal of Previous Payment”) and there is a zero or negative amount

paid

• there is a negative amount submitted and a zero or negative amount paid

The Pended status remains in our system from the 4010 835 guidelines, but is not used unless:

• the CLP02 claim status code is 5, 10, 13, 15, 17, or 27

Denied statuses are set when any of the following are true:

• the CLP02 claim status code is 44 (“Denied” in the ANSI guide), 23 (“Not Our Claim, Forwarded to

Additional Payer(s)”), or 25 (“Predetermination Pricing Only – No Payment”)

• none of the other options are true

ERA & DENIAL MANAGER INTRODUCTION

4

WORKING DENIALS

When working denials the user would first select denied transactions. Denied transactions can be selected by a variety

of different search criteria. A few suggestions:

• By status

• By Payer

• By Group/Reason Code

• By Procedure Code

• By Over/Under Payment Flag

To research more about the denied transaction, the user can view the EOB at the transaction level to view the full

scope of the denial. Once information is known, the user can then take a course of action by:

• Editing the Claim using C, or the Edit Claim Button

• Re-Filing the Claim by using the Ready Claim function

• Print letters such as Timely Filing or Appeal

APPLYING FOLLOW-UP ACTIONS

Once changes have been made to the claim, the user can apply an action by double clicking the transaction record to

update the ERA Follow Up Status. Select the appropriate status that corresponds to the action taken. Also, the user

can create a plan of action, add an expected payment, and assign it to a staff member.

Follow Up Status – The most recent follow up status and action applied to the transaction is displayed in the Update

ERA screen.

*If the transaction has not been worked, the status will default to NEW.

Once the Follow Up Status is set, the user can then search by both ERA Status and Follow up Status in order to

identify desired transactions. For ease of workflow the User can also use these statuses to build TASKS to work

groupings of transactions.

5

MONITORING DENIALS VIA TASKS

Another workflow for transaction management would be setting up various tasks in Task Manager to automatically

track your denials.

There are filtering capabilities in ERA tasks which are solely available in ERA Task that you have the following

capability to group transactions by:

• Expected and Unexpected Code Types

• Minimum and Maximum Amounts of transactions

• ERA Age ranges

• Assign a Staff member by a code or transaction

• Transactions by Patient Ranges

The following are common ERA Tasks:

• DENIED ERA transactions that were denied with a specific Claim Adjustment Group or Reason Code

• ERA Transactions marked PAID $0.00

• New ERA Transactions that have not been assigned to a staff member for follow-up

• ERA Transactions that are appealed and need follow-up to see if they have been paid

• ERA Transactions that did not match to a claim in Claim Manager

ANALYZING ERA DATA

The ERA Manager application comes with several analytic tools that allow the user to see their practice’s financial

status as well as identify potential areas of growth.

Some suggested reports:

• Payer Allowed Amounts by Procedure (ERA Reimbursement Analysis)

• Group/Reason Denial Amounts (ERA Denial analysis)

• ERA Dashboard (Aged Cash Graph, Days of Sales Outstanding, and Adjudication Summary)

6

ERA SELECTION CRITERIA

The main ERA Denial Manager application has 3 main sections: Search Criteria, ERA Transaction List View, Status

Message View.

The ERA Denial Manager Search criteria are split in to three columns.

Column 1

Customer ID – Allows a user to select transactions for a specific practice.

*If the user only has access to one practice then this field will not be shown.

ERA ID – Filters transactions by a unique EDI ERA ID.

ERA Status – The user can search by a specific transaction status.

Transactions will have 1 of 4 of the following statuses:

• Denied – The transaction was labeled as DENIED by the payer.

• Paid – The transaction was labeled as PAID by the payer.

• Pended – The payer has pended this transaction in their system.

• Reversal – The billed amount on the transaction is negative, meaning the payer is taking money back.

Follow Up Status – A transaction can have 1 of 4 main ERA statuses.

Search Last –Allows the user to search for the last 30, 60, 90, 180 days or all days instead of having to input a

specific date range.

Beginning/Ending – Search transactions by a specific beginning and ending date range.

Date Range – This selection applies to the date range and Search Last fields above it. The software will use the range

or days supplied and will search either by Date of Issue, Date Loaded in to EDI, or Service Date indicated on the ERA.

APPLICATION OVERVIEW

7

Column 2

Group/Reason – The drop down selection takes the user to the customer-specific list of Group/Reason codes. The

user can then select transactions for a specific Group/Reason code or several code combinations at once.

*The same code list found in the Manage Codes button from the Manage Tables screen.

Remark – This selection will pull the master list of Remark Codes, which will narrow the returned transactions by the

selected code.

Procedure Code – A free-form text field that can be used to select transactions for CPT/HCPCS code.

*User can search on partial codes, a specific code, or a Procedure code with modifier needing a (-) as separator.

Provider NPI – Allows users to select transactions based on the Provider NPIs received in the 835 data.

*Each transaction, built from the 835, is stored with the Provider NPI that was extracted from the 835.

Expect ID – The Expect ID field allows a user to search for all transactions being compared to a specific Expect ID

from the Manage Expects table.

*This ID can be found under MANAGE Tables button, under the Manage Expected Amounts button.

Inbound Payer Name - Searches for partial or exact payer names as they appeared on the 835.

Payer ID –A user can search for transactions that are matched to the payer’s 5 digit payer ID.

Resp Payer –This field will allow a user to search for Primary, Secondary or Tertiary payments.

8

Column 3

Assigned ID- Filters results for transactions assigned to a specific staff user.

*Users have the ability to assign ERA transactions to individuals to work or manage.

EDI Claim ID – This selection will search for all transactions matched to a specific claim.

*The EDI software will attempt to match the ERA record, to a claim submitted through the EDI software. If it succeeds

then the EDI Claim ID can be used.

Claim Status – Selects all Claim Matched transactions, where the claim is in the chosen status.

Check Number – Filters transactions associated to a specific check number

Pt Account # - Filter transactions using the unique patient account number.

Payer Trace # - The Payers unique internal trace number (ICN/DCN).

Pt Last Name – Select transactions for a given patient last name.

Retrieved ID (*) - Select transactions using the unique ID for the master 835 from a payer.

*This is a Vendor Level ONLY field.

Type - The Type radio buttons allow a user to search for transactions that are service-level, claim-level, or both.

ERA SELECTION CRITERIA- FUNCTIONALITY

SELECT Denials – Selects only transactions in a DENIED status dependent on user entered criteria.

SELECT Transactions – Selects transactions based upon the criteria entered.

CLEAR Selections – Clears any manually entered data that has been remembered by the EDI software from a

previous selection.

*Defaults SEARCH LAST selection to 30 days

PRINT ERA List – This button will generate a report list of all selected transactions. This report can then be copied or

exported to Microsoft Excel. You will be prompted for the following:

9

-Yes: Will display the report with added Status messages for each transaction.

-No: Will display the information for the transaction only.

10

TRANSACTION LIST VIEW

The list view shows all ERA transactions based upon the selection criteria chosen from above. The data displayed can

be used to quickly view key data in regards to the ERA.

ERA ID – Each ERA record that is created in the system is assigned a unique, internal EDI ERA ID.

RP – Responsible Payer. This column will display what type of payment the transaction represents.

- Primary

- Secondary

- Tertiary

Type – Displays whether the transaction is a service level (SVC) payment or a claim level payment (CLM).

Status – The status of the transaction based on the information received in the 835 file.

Follow Up Status – If a status has been assigned to a transaction the status will be displayed here.

*If the transaction has not been worked, the status will default to NEW. See Assigning Follow Up Status.

APPEALED: Appealed by user

COMPLETE: Complete by user

NEW: Transaction to be reviewed

NOAPPEAL: No appeal allowed

PAID: Payer making payment

PEND-USR: Pended by user

TRANSFER: Transferred by user

Payer – This column will indicate whether the transaction matched to a payer/plan record in the EDI system.

*This information is generally taken from a matched claim. If the transaction did not match to a payer, this column

will display a 0, followed by the name received on the 835 file.

Payer ID – Matched payer’s 5 digit ID will display.

*If no payer match was automatically or manually created this field will remain blank.

EDI Claim ID – EDI unique CLAIM ID as assigned to the matched claim by the EDI.

*When 835s are received in the EDI software the system will attempt to match it to a claim filed through the

software. If a match was not made the column will display a 0.

Pt Account # - The patient account number extracted from the ANSI 835 transaction.

Pt Name – Name of the patient extracted from the ANSI 835 transaction.

Provider Name – Provider’s name that was matched from the NPPES Registry to the NPI received on the 835 file.

*Most 835s send back a Provider NPI without a name, or with a practice name.

Service Date – The date of service for the listed record.

Procedure – The Procedure Code and any related modifiers that are sent back on the 835 transaction.

11

Billed – The amount billed for the transaction according to the 835 data.

Allowed – How much the payer allowed for the service according to the 835 data.

Paid – How much the payer paid on the service according to the 835 data.

Deductible – If any of the service billed amount is to be applied to the patient deductible, this amount will display in

the Deductible column.

Expected Allowed – The amount of payment expected on the billed transaction.

*All incoming transactions are compared to the expected amounts created in the Manage Expect Table, whether they

were entered via an uploaded fee schedule or created systematically via actual ERA data.

Difference – The difference between the Expected Allowed column and the Allowed amount found on the 835 for this

transaction.

• If the Allowed Amount is lower than the Expected Allowed the value will show in red font as a

negative number and is identified as an underpayment.

• If the Allowed Amount is higher than the Expected Allowed amount the value will show in blue font

and is identified as an overpayment.

• If the Allowed Amount is the same as the Expected Allowed amount the value will show in black font.

Group/Reason – Displays all Group/Reason code combinations that the payer applied to this transaction from the

835 data.

*The dollar amount displayed is the adjustment amount for the given code.

Remarks – Displays any remark codes returned on the 835.

Assigned To – The staff ID# and name of the transaction owner.

* Users can assign transactions to specific staff members.

Check Number – The check number associated with the ERA record.

Date Issued – The Issued date on the check associated with the ERA Record.

Expect ID – Each expect in the Manage Expects table has its own unique ID. This ID allows the user to look at the

specific expect being used for comparison for the selected record.

Customer – This column identifies the EDI ID of the customer that the transaction belongs to.

12

Response File – This ID corresponds to the EDI ID of the customer ERA that the transaction was pulled from. This ID

corresponds directly to the ID of the file in the customer’s Transfer Files screen.

Date Loaded – This date reflects the date that this 835 was received and processed in to the EDI system.

Claim Status – Current status of the matched claim.

*Each transaction or claim level adjustment can relate back to a claim or encounter if the claim or encounter was filed

through the EDI software.

Payer Trace # - The Payers unique internal trace number (ICN/DCN).

Retrieved ID – This column displays the ID of the master file received by EDI that corresponds with this transaction.

13

TRANSACTION LIST VIEW- FUNCTIONALITY

There are several options available for a user to use when working ERA transactions. These options are accessed via

the right-click menu on the transaction list view. Several of the right-click options are also available in button form on

the grey transaction list view bar.

Help (F1) [Right Click] – This option will take the user to our F1 online help manual. This manual has full topic and

keyword searching options.

Submit/End (End) [Right Click] – Each function opens up a form within the software. By hitting the END key, the

software will save any changes and close the form that the user is in.

Cancel (Esc) [Right Click] – Cancel will close the form and not save any changes made.

UPDATE Transaction (Button)/ Update Follow Up Information (F2)[Right Click] - Assigns a Follow Up status

for the transaction chosen.

-Assigning a Follow Up Status: Double mouse click the transaction desired from the selection view, or

Highlight the transaction and use the Update Transaction button.

The available Follow Up Statuses are:

APPEALED: Appealed by user

COMPLETE: Complete by user

NEW: Transaction to be reviewed

NOAPPEAL: No appeal allowed

PAID: Payer making payment

PEND-USR: Pended by user

TRANSFER: Transferred by user

Once the Follow up Status is set, the user can then search by both ERA Status and Follow up Status in order to

identify desired transactions.

Find Claim (CTRL+F) [Right Click] – This function will open the Find Similar Claims screen. This screen locates

matched claims for this transaction if they exist in the EDI Software. This will also identify any duplicate submissions,

Primary/Secondary/COB pairings, and Professional/Institutional versions of the same claim.

*Same functionality available in Claim Manager

EDIT Claim (C)[Right Click] – When working denials often times claim data will need to be changed before re-

submitting the claim. The claim can be edited from the transaction by using the Edit Claim function.

14

EDIT Expects (x) [Right Click] – Edit the Expect that the transaction is being compared to without having to go in

to the Manage Expects table and search for the expect. The following screen will open:

The software will allow the practice to edit the expected allowed amount and expected payment amount in order to

lock the record and amount to use for comparison.

The user can also assign an effective and ending date to the Expect to match the contracted fee period for the

selected payer and provider.

Once edited, the record will become locked and cannot be overwritten by incoming 835 data.

PRINT Letter/ Print Claim Letter (F7)[Right Click] – There are several letters that the EDI software provides in

order to assist with working denials or initiating appeals. This function will allow the user to choose from 4 standard

letters.

• APPEAL – The Claim Appeal Letter is a pre-formed cover letter that includes all of the pertinent information

from the matched EDI claim that corresponds to the selected transaction.

• CLMSTAT – The Claim Status letter acts as a formal request for a claim status from the payer. The information

on the letter is pulled directly from the matched EDI claim and can be printed and faxed or mailed.

• REFUND - The Claim Refund Letter allows users to print a letter stating that they are submitting a voluntary

refund to the payer in response to identifying a potential overpayment. Users now have the ability to offer a

voluntary refund to a payer before the payer finds the error on an audit. It helps the practice maintain a more

accurate record of their incoming cash flow.

• REQUEST – The Medical Record Request letter allows users to attach a cover sheet to a claim or transaction

that has been Pended or Denied due to needing medical records to complete adjudication. The letter contains

all of the relevant claim information as well as the payer’s trace number so that a one to one match can be

easily and quickly identified, speeding up the adjudication process.

View Claim on CMS Form (F9) [Right Click] – If the ERA transaction is matched to a claim in EDI, this option will

allow the user to view the matched claim on a CMS form.

READY Claim/ Set Claim Ready to Send (CTRL+F4)[Right Click] – If the user needs to re-submit the matched

EDI claim to the payer in order to re-file a denied transaction this option will set the matched EDI claim status to

READY in order to get sent back out.

VIEW Entire ERA as an EOB (e) [Right Click] - This option allows the user to view the ANSI 835 as an EOB. This

also gives the user the option to view the entire remittance in the standard MREP view.

15

View ERA Summary (s) [Right Click]- Views all pertinent data associated with the given transaction extracted

from the 835, and if matched to a claim the claim data as well.

*Also displays the Note field from the Group/Reason code record.

Display Payer Contact Info (p) [Right Click] – If the ERA transaction matched to an EDI payer this option will

display NPI settings, ANSI version, Send and Receive method (VENDORS ONLY), Submitter and Connection

information (VENDORS ONLY) and EDI Contact information (VENDORS ONLY).

Change Claim Status (F11) [Right Click] – This option allows the user to change the status of the matched EDI

claim without changing the transaction status or transaction follow-up status.

View Complete Inbound File (f) [Right Click] – This option will allow the user to see the inbound claim

information for the matched EDI claim that corresponds to the selected transaction.

16

STATUS MESSAGE VIEW

The bottom portion of the screen shows the claim status history of the matched EDI claim for the transaction selected

in the Transaction List View. If the transaction did not match to a claim in the EDI software this section will be blank.

The Status Message view bar will indicate which claim the status messages pertain to in the top left corner. This bar is

also home to a few function buttons which will be covered in the Status List View – Functions section.

Status ID – Each status that is created for a claim is assigned a unique status ID. This status ID is displayed to the

left of its status.

Date – The date of creation for the status is displayed in the Date column.

Source – The source of the status will be displayed in the Source column. This will show whether the status was

generated from a response file, a user, the EDI Software’s tester or loader, or if the status is an ERA (ANSI 835) file.

Msg Level – The message level indicates the level of severity for the status. If the status has the ability to change

the claim status, the appropriate status will be indicated in this column. If the status is purely information, resulting in

no status change, the column will display the word INFO.

Message – The message field contains the primary message as sent back on the response file if the status has a

source of RESPONSE or ERA. For all other sources the message is the stock message associated with the status type.

Message from Support – This field is where the EDI software will put a translated message, or additional

information from the report or response. Typically this information is included to enhance the standard message or

include important information that came back elsewhere in the file.

Error Code – If the status contains a specific error code it will be displayed in this column.

Claim Status – This column indicates the status of the claim after being marked with the associated status.

Batch ID – This column will display an associated batch ID with a status related to sending the claim, or being

marked with an 835. This number is typically used by EDI staff to locate the batch that included the matched EDI

claim.

Batch Number – This is an internal batch number that is specific to the EDI software.

Resp Msg ID – Whenever a status is created from a report with a specific message the status is given a response

message ID. This ID will be the same for all statuses that are created with this message. This allows the user to look

across transactions or claims to find all items that have been associated with that particular status message.

Retrieved ID – This ID indicates which master file received in the EDI software that the status is associated with.

17

STATUS MESSAGE VIEW- FUNCTIONALITY

There are several options available for a user to use when viewing status information. These options are accessed via

the right-click menu on the status message view. Several of the right-click options are also available in button form on

the grey status list view bar.

Help (F1) [Right Click] – This option will take the user to our F1 online help manual. This manual has full topic and

keyword searching options.

Submit/End (End) [Right Click] – Each function opens up a form within the software. By hitting the END key, the

software will save any changes and close the form that the user is in.

Cancel (Esc) [Right Click] – Cancel will close the form and not save any changes made.

VIEW Change Log/ View Change History Log (F9)[Right Click] – This option is also available in form of a button

on the status list view bar. Every time a change is made to a transaction or a claim, this information is stored in a

change log report. This way all data is remembered and all changes are recorded.

PRINT Timely Filing/ Print Proof of Timely Filing (F7) [Right Click] – The Proof of Timely Filing letter is another

option users have when appealing a denial for timely filing. This letter displays all of the claim information as well as

all of the EDI response information to give the payer a clear timeline of submission. The responses include the file

name received from the payer to assist payers in identifying their files.

View EOB Standard Remittance (e) [Right Click] – This option allows the user to see the single patient view of

the remittance on the status level. This view is especially helpful when working appeals as the user can print out a

singular piece of the EOB without having to exclude unnecessary data.

View ANSI Data (a) [Right Click] – This option displays the ANSI data associated with the ERA status selected in a

numbered segment view.

View Retrieved Response File (r) [Right Click] – For statuses with a source of RESPONSE this option allows the

user to view the raw file for the customer that came in on the master report. The format will show the original format

sent in by the source.

View Claim in Outbound Batch File (b) [Right Click] – For statuses with a source of SENT this option allows the

user to see a pretty ANSI view of the claim as it was sent in the selected submission.

Create COB Claim (s) [Right Click] – This option allows the user to use an ERA status to create and balance a COB

claim. The process will look at the responsible payer of the 835 and will generate the COB claim using the ERA data

from the selected status.

Edit Claim (c) [Right Click] – The user can edit the claim data from the newly created COB claim at the status line

instead of having to find the newly generated claim and edit from the claim list view.

View Status Message (m) [Right Click] – This option allows the user to see a report view of the status line

information. This report also includes relevant information from the EDI matched claim.

18

Manage Tables is where the practice will go to manage fee schedules, expected allowed amounts, Group/Reason

codes and denials, as well as their custom working ERA Payer list.

MANAGE EXPECTED AMOUNTS

The Manage Expect table is where expected allowed amounts are stored for each client. The Expects are populated in

one of two ways: by uploading a fee schedule from the PM, or by historically building the table from actual 835 data.

Historical 835 Data

The software can build a table of expected amounts using the live 835 data. The software will record the Provider NPI,

Payer, Procedure Code and Modifier combination and will make a record of the highest amount that has been allowed

for this combination. Unless these records are edited, these will be dynamic, and can be overwritten if the payer

begins sending a higher allowed amount for the record. The user has the option to edit the expect amount and lock it

as the fee of record.

Editing Expects

Once the expect record has been created in the system, the practice has the ability to manage the expect record. To

edit, simply double click the record.

MANAGE TABLES

19

The software will allow the practice to edit the expected allowed amount and expected payment amount in order to

lock the record and amount to use for comparison.

The user can also assign an effective and ending date to the expect amount to match the contracted fee period for the

selected payer and provider.

*Once edited, the record will become locked and cannot be overwritten by incoming 835 data.

All incoming transactions will be compared to the expect record for that code/payer/provider combination to

determine an incoming overpayment or underpayment. The difference between the incoming transaction and the

expected amount will be shown in the Difference column on the main ERA Manager screen.

Under payments will display in red font, with over payments displaying in blue.

*Tasks can be created to show only under payments, over payments or a combination of both.

Expected reimbursement data (“Expects”) – Expects will now be created with Beginning and Ending dates of the current

year of the date of service. We will automatically create NEW Expect records at the beginning of each year to allow the

tracking of updates to fee schedules. The Expect is tracked for the payer and provider NPI based on the new tables.

• Providers tracked in the Expect records will be associated with the new NPI ERA provider list to allow the

reimbursement to be more accurate at the rendering provider level.

• Payers associated with each expect record will now be linked to the new “Matched Payer” based on the

“Inbound Payer Name”.

Group/Reason Code table – This table will store every combination of reported Group/Reason code found in ERA files

for each customer. The table will be used to make selections much easier in tasks and in the main application. The code

combinations can be flagged with important information as follows.

• Staff Assigned lets transactions with the certain Group/Reason codes automatically route to a user to be

worked through a task or selected in the main application.

20

• Expected/Unexpected flag will allow the Group/Reason to be set as Expected if needed (ex. CO45) so

that adjustment can be excluded from analysis and tasks and true denials can be tracked in tasks and

reporting.

• Notes can be added to the Group/Reason Code to allow information to be stored to help the users know

how to handle the rejection when received.

MANAGE EXPECTED AMOUNTS – SEARCH CRITERIA

The Manage Expects table search criteria allows users to filter through their Expects to find expected allowed amounts

for certain payers, codes, date ranges, and providers.

Procedure Code – Filters any expects that are set for a given procedure code.

Procedure Modifier – The drop down selection allows users to choose up to 4 modifiers to search for when looking

for expects that contain those modifiers.

Beginning/Ending –Users can search for expects within a given date range.

-Can use +, -, or . short-cut Functionality.

Date Range –This option tells the EDI software to search on either the Effective date of the Expect or the Ending date

of the Expect.

*This selection is dependent upon the Beginning and Ending range above when using the date range in the fields

above.

Expect ID – Unique identifier given to a specific Expect as the record is built in the EDI.

Retrieved ID – Unique ID extracted from the master 835 that was received by EDI software.

*Search for expects generated from a specific ERA received into the EDI software.

Inbound Payer Name - The user can search for all or part of an inbound Payers name extracted from the returned

835.

-Can perform range, Wildcard, %% searches.

Payer ID – Unique Identifier given to the Payer in EDI based on the customers Working Payer List.

*Will search for all Expects that have matched to an EDI Payer in the EDI. Choosing from the customer specific

Working Payer list, can select one or many payers.

Provider NPI – National Provider Identifier for the Provider on the ERA that users can search for.

21

MANAGE EXPECTED AMOUNTS – COLUMNS

All of the Manage Expect columns with an asterisk (*) are sortable. The default sort will sort A-Z, Low- High. Clicking

again will reverse sort.

The column order can be re-arranged per user preference, to customize the display. To re-arrange a column, simply

click and hold on the column header, then drag to the desired position.

Expect ID – Each Expect in the Manage Expects table has its own unique ID assigned by the EDI software. This ID

allows the user to look at the specific Expect being used for comparison for the selected record.

Provider Name – is matched from the NPPES table to the inbound provider NPI.

Matched Provider – A table has been added that will store the NPI number found in the ERA file. The Rendering

provider, if reported in the ERA, will be the matched provider to ERA transaction. The provider name associated with

that NPI in the NPPES table would be associated with that NPI number that is used for selections in the applications.

This provider will be linked to the ERA transaction and the Expect record. The data will not be linked back to a provider

record id setup in the provider setup for claims since that is not consistent with ERA data.

Provider NPI –the provider’s NPI returned on the 835 and is associated with the expect amount.

Inbound Payer Name – The payer name extracted from the 835.

Payer ID – The EDI payer ID for the Expect. The software uses a matched claim to obtain this ID if it is not sent in on the inbound 835.

Matched Payer –We assign a payer to the transaction based on the “Inbound Payer Name”. The PI payer id

from the matched claim will be associated with the “Inbound Payer Name” only if the claim is the same responsible

payer. The user will be able to manually set the payer id to the “Matched Payer” record if no match was found. This

will be more accurate for tracking expects and for reporting purposes. *If no match or ID can be found, the software will default to an ID of 0. The user can then manually edit the payer in

the Manage Payers table to update the payer ID.

Procedure Code –The CPT/HCPCS code and modifier combination for the Expect.

Standard Fee – The Billed amount extracted from the 835 that generated the selected Expect.

Expected Allowed – Amount based on either:

-The highest value received for the provider/payer/procedure combination in the historical 835 data.

-A manually entered amount (edit or uploaded fee schedule).

Expected Payment – Amount paid on the 835 associated with the Expect record.

Effective Date – Date when the Expect record becomes effective for comparison.

*This date defaults to January 1 of the current calendar year unless otherwise manually altered.

End Date - Date the Expect record becomes no longer effective for comparison.

*This date defaults to December 31 of the current calendar year unless otherwise manually altered.

Edited – This field indicates whether an Expect record is edited or “locked”.

22

- If a user manually edits the Expect record then it will be locked, and display a Y. The Expect record will not

be overwritten by historical data once locked.

- 835 historical Expect records default to N and can be overwritten when higher amounts for that Expect

are received.

Retrieved ID – Unique ID for the master 835 that was received by EDI software.

23

MANAGE CODES

The Manage Codes table lists all of the Group/Reason code combinations that have ever been received on actual 835

data for the selected practice.

This allows the practice to manage their specific set of codes instead of sifting through the entire master code list.

From this screen, the user can edit the code in order to assign this Group/Reason to a user, assign a prescription of

action to the code, and label it as Expected or Unexpected for reporting purposes.

EDIT Code- Allows the User to edit a specific Group/Reason Code. Referring

Each individual Group/Reason code can be assigned to a staff member to work or be in charge of. Also, a prescription

of action can be entered in to the note field in order to instruct the practice on what to do the next time this code is

received.

The user can also label this Group/Reason code as Expected (Yes) or Unexpected (No). This will allow for inclusions

and exclusions of expected denials on the ERA Dashboard as well as ERA Tasks.

24

MANAGE CODES – SEARCH CRITERIA

The Manage Codes table includes search selections in order to let the user filter through their list of Group/Reason

codes.

Group – Drop down list of Group codes the customer has received in 835s.

Reason – Allows for selections from a list of Reason codes the customer has received in 835s.

Expected – Radio selection.

Yes: Group/Reason code is Expected, when selected Expected Codes will display.

No: Group/Reason code is not Expected, when selected Non-Expected Codes will display.

All: When selected all Group/Reason codes will display.

Staff Assigned – Drop down selection to filter Group/Reason Codes that have been assigned to a specific staff

member.

* Users can assign Group/Reason codes to staff in order to be worked.

MANAGE CODES – COLUMNS

All of the Manage Codes columns with an asterisk (*) are sortable. The default sort will sort A-Z, Low- High. Clicking

again will reverse sort.

The column order can be re-arranged per user preference, to customize their display. To re-arrange a column, simply

click and hold on the column header, then drag to the desired position.

The grey Group/Reason Codes bar will list a count of all selected Group/Reason codes in the top left corner. This bar

also allows users to Edit a Group/Reason code as described in the Manage Codes section.

ID – The unique ID code given to the Group/Reason record.

Code – The unique Group/Reason code.

Expected – Displays that the Group/Reason code is Expected or Not.

Y= Expected

N= Unexpected

*Users have the ability to label Group/Reason codes as Expected or Unexpected. All codes default to N for

Unexpected. During editing the user can change the code to Y for Expected.

Group – The standard description of the Group code.

Reason – The standard description of the Reason code.

Assigned To – If the Group/Reason code is assigned the Staff ID# followed by the Staff Name will be displayed.

25

Date Created – The date the Group/Reason code record is entered into the system. There will only be one record per

Group/Reason code.

Date Modified – The latest date that the Group/Reason record was edited.

Note – Any entered notation for the Group/Reason code will display.

*While editing Group/Reason codes, users can add any notation in the Notes field. This could otherwise be known as a

Prescription of Action.

26

MANAGE ERA PAYERS

The Manage ERA Payers button displays a list of the payer names that the practice has received from incoming 835

files. Each ERA record will then attempt to match to a claim based on that Payer Name, if the claim was sent through

the EDI Claim Manager product.

*If the Inbound Payer Name does not match to the EDI claims payer name, the Payer ID number will be left blank

and the user can manually make a match to an EDI payer by editing the payer record.

-EDIT Payer Name Match Record: Double click on record or highlight record desired and click OPEN

button. Enter desired Payer ID Number into field. Save changes by clicking Save in upper right corner.

Editing the record will allow the user to match the Inbound Payer Name to the EDI 5 digit Payer ID.

*Typically, this screen is used for payers that came in on Secondary ERAs that did not match to a claim in EDI due to

being automatically crossed over.

MANAGE ERA PAYERS– BUTTONS

PRINT Payer List – To view a printable list of the ERA payers that pertain to the selected customer.

- The practice can see which payers they are actively receiving 835s from; versus the payers they may or

may not be enrolled to receive remittances from.

Open- With a record highlighted, then pressing open will pull the record up for editing.

*Same functionality as the Right click function F2, or Double clicking on desired record.

MANAGE ERA PAYERS – COLUMNS

All of the ERA Payer Name Matches columns with an asterisk (*) are sortable. The default sort will sort A-Z, Low- High.

Clicking again will reverse sort.

The column order can be re-arranged per user preference, to customize the display. To re-arrange a column, simply

click and hold on the column header, then drag to the desired position.

27

Rec#- Unique identifier for the Payer Match Record.

Cus ID- Customer ID.

Create Date- Date and Time stamp given to the record when the Payer Match was created.

Payer ID Number- 5 digit EDI Payer ID associated to the match record.

*Will display 0 if no match was made from the Inbound 835 to a Payer within the EDI software.

Inbound Payer Name- Payers name extracted from the Inbound 835.

ERA Format- Format of received ERA.

-Professional

-Institutional

28

ERA Manager Reports are available in 3 different formats: ERA Dashboard, ERA WebBrowser, and ERA Data Miner.

ERA DASHBOARD REPORTS

There are 5 different ERA Dashboard reports that can be run in the ERA Dashboard format. A user can choose to run

one, many, or all dashboard reports at the same time, by selecting the DASHBOARD button from within ERA Manager.

Once this button is selected, the user will be taken to the ERA Dashboard welcome screen.

ERA & DENIAL MANAGER REPORTS

29

From the welcome screen the user can choose which new report to run in the dashboard format. Up to 4 reports can

be chosen to display at one time from the New Report button.

Once the user has chosen the desired configuration the report layout can be saved using the Save button in the

bottom right corner and the next time the user logs in to the Dashboard the report configuration will be remembered.

Any of the Dashboard reports can be run as a stand-alone report in Search Tools – Report Manager.

ADJUDICATION SUMMARY GRAPH

The Adjudication Summary Report allows the practice to see a quick, graphical summary of their Adjudication Status.

The report takes information from all of the customer’s received 835s and classifies them as Paid, Denied (Unexpected)

or Denied (Expected).

The Expected versus Unexpected designation is controlled by the provider practice and can be accessed by the Manage

Codes table in ERA Manager.

The legend at the bottom gives the total percentage of denials associated with each category. The hover text displays

transaction then dollar amount associated with each category.

30

AGED CASH GRAPH

The Aged Cash Graph report allows the practice to see how long it is taking for payers to pay their claims.

This graph breaks down all claims uploaded within the given date range and charts how long the date of payment took

compared to the claim’s filing date.

The legend on the bottom gives color coded categories and claim volume percentage associated with the time in days.

The hover text gives the associated claim amount totals.

31

DSO BY PROCEDURE

This report shows how long it takes for payers to pay for the top 10 grossing submitted procedures (Days of Sales

Outstanding).

The yellow bar graph shows the top ten procedure codes based on received payment volume.

The blue bar graph above shows the corresponding number of days it took on average for the payer(s) to pay the

procedure.

If the user hovers over the yellow bar, the hover text will give the exact dollar amount for the listed code. If the user

hovers over the blue bar, the total dollar amount and exact number of Days of Sales Outstanding will appear.

32

DENIAL RATES BY PROCEDURE

This report uses 2 bar graphs to show the top 10 denied procedures based on denial rate by percentage and by dollar

amount billed.

Hover text on the top graph shows procedure code and dollar amount with the percentage of denial rate. Hover text on

the bottom graph shows procedure code and exact dollar amount for the denial rate of that specific code.

This allows users to see which codes are being denied most frequently and what financial impact the denial percentage

has on the practice.

33

TOP 5 DENIAL CODES

The Top 5 Denial Codes report shows the top 5 denials received on 835s for the practice based off of the highest

denial rate.

The user has the ability to include or exclude expected denials from this report, allowing the user to focus on just the

denials that are not anticipated, or to expand and focus on the entire revenue picture.

The legend at the bottom shows the top 5 denial codes and their percentages. Hover text is available on the legend

and will display the definitions of the listed denial codes. The pie chart gives both volume and dollar amount associated

with each code.

34

ERA DATAMINER REPORTS

Data Miner reports are interactive reports that allow the user to configure their own custom reports. The 835 is

broken up in to “blades” or categories of data that the user can filter and re-arrange in to columns or rows to create

individual report templates.

Upon running a Data Miner report the user will be asked to choose a customer and date range. The report’s

configuration screen will then appear.

From the configuration screen the user can run the default (all available blades) or can create a new custom

configuration.

To create a new configuration the user must click New Configuration or go to the Configuration Blade Selection screen.

35

The Configuration Blade Selection screen lists all available blades in the farthest left column. From here users can

drag the desired blades to the column or row to form a default template. For additional blades the user can add them

to the Included but Unused Blades column.

Once the configuration is complete, click Save As New Configuration and the saved report will appear under the

Current Saved Configuration tab.

ERA DENIAL ANALYSIS

36

The ERA Denial Analysis is a report that allows the user to generate analytics based off of each received

Group/Reason code. In contrast, the Reimbursement Analysis generates analytics based off of the total billed amount

for each transaction.

ERA REIMBURSEMENT ANALYSIS

When selecting the report the prompt for the data set will be requested. After selecting the data you would like used

for the report, the user can then select the exact configuration the same as other Data Miner reports.

At this point the user can create a new configuration or run a saved configuration.

*Keeping in mind the Default cannot be deleted.

The Reimbursement Analysis generates analytics based off of the total amounts of the transaction. In contrast, the

Denial Analysis generates analytics based of the dollar amounts associated with each specific Group/Reason code

received.

37

ERA WEB BROWSER REPORTS

ANALYSIS BY REASON

The Analysis by Reason report shows the Adjustment Reason code, Procedure codes, Adjustment Totals, and

Adjustment count that were received on 835s for the practice based off of the date range selected.

The user has the ability to select if the date range applies to the Check Issue Date or the Date of Service. Also, the

user can make a selection of if the Responsible Payer is Primary, Secondary, Tertiary, or All.

38

ANALYSIS BY PROCEDURE AND REASON

The Analysis by Procedure Code and Reason report shows the Procedure code, frequencies of the code, Adjustment

Codes, Description, Adjustment Totals, and Adjustment count that were received on 835s for the practice based off of

the date range selected.

The user has the ability to select if the date range applies to the Check Issue Date or the Date of Service. Also, the

user can make a selection of if the Responsible Payer is Primary, Secondary, Tertiary, or All.