2013 ERA & DENIAL MANAGER

Transcription

1 2013 ERA & DENIAL MANAGER 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 1

2 Getting Started TABLE OF CONTENTS 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 2

3 ERA & DENIAL MANAGER INTRODUCTION 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 servicelevel) 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 o o there Is a zero amount paid but a zero amount submitted there is a zero amount paid but a positive amount allowed that is not equal to the submitted charge 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 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 3

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. 4

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) 5

6 APPLICATION OVERVIEW 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. 6

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. 7

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: 8

9 -Yes: Will display the report with added Status messages for each transaction. -No: Will display the information for the transaction only. 9

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. 10

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. 11

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. 12

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 resubmitting the claim. The claim can be edited from the transaction by using the Edit Claim function. 13

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. 14

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. 15

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. 16

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. 17

18 MANAGE TABLES 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. 18

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. 19

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 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. 20

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. 21

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 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. 22

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. 23

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. 24

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. 25

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. 26

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 27

28 ERA & DENIAL MANAGER REPORTS 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. 28

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. 29

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. 30

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. 31

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. 32

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. 33

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. 34

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 35

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. 36

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. 37

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. 38