SoftAR Presented By Ann Hage May 10 2018 Unsolved Mysteries SoftAR Missing Orders Charges New Invoices Payors Modifiers MISSING CHARGES Missing Charges The topic of Missing Charges is a broad one and its one that we continue to see in support tasks asking about orders not mak ID: 789397
Download The PPT/PDF document "Gathering the Facts; Analyzing" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Gathering the Facts;Analyzing SoftA/R
Presented By: Ann Hage
May
10, 2018
Slide2Unsolved Mysteries .... SoftA/RMissing Orders / ChargesNew InvoicesPayors
Modifiers
Slide3MISSING CHARGES
Slide4Missing ChargesThe topic of Missing Charges is a broad one and its one that we continue to see in support tasks asking about orders not making it into SoftAR, missing charges in the HIS, overall decreases in revenue and everything in between.The underlying reason behind missing charges can typically be found in one of the first three phases of the revenue cycle: Posting, Invoicing and Billing.
Slide5Phase 1: PostingThe basic operational flow of events begins when orders are posted into SoftA/R.Within each Soft Integrated module, tests and orders will qualify for scheduled billing jobs or real time data transfers, which are then transmitted to SoftA/R
through a billing
interface or a Posting Web Service
.
Slide6Phase 2: InvoicingOnce the orders are posted into SoftA/R, they will then qualify for our Invoicing process. This is a scheduled process that is responsible for executing the user defined billing rules and prices.
Slide7Phase 3: BillingOnce an order has been successfully invoiced, it will qualify for the next scheduled billing job for the invoiced payor.
Slide8PHASE 1:POSTING
Slide9Troubleshooting Posting IssuesPosting MonitorAPEX Comparison and Reconciliation ReportsAPEX
Errors Report
Slide10Posting Monitor
The vehicle within SoftA/R that is used to view incoming orders is the Posting Monitor, accessible from the A/R desktop and the ‘Tools’ menu.
Slide11Posting Monitor: Message Content
To view the content of a message, enter the order# using the search filter at the bottom of the dialog.
Slide12Posting Monitor: Message Content
Once the qualified order appears, double click on the message to open the data repository.
Slide13Posting Monitor: ErrorsAlthough the recommended tool for monitoring Errors is the APEX Errors Report, Posting Monitor can also be used to view errors that were encountered when posting an order. To view Posting Errors, select Tools>Error Viewer
Posting Monitor
From the dialog, conduct your search by order number or date range.
Posting MonitorQualified errors can then be reviewed in the results grid.
APEX COMPARISON AND RECONCILIATION REPORTS
Slide17Comparison/Reconciliation ReportsAPEX offers an extensive menu of reports to assist lab and billing personnel in identifying tests and orders in the LIS that are not present in the SoftA/R database. The reports also identify test and order level discrepancies, as well as potential setup issues.
Slide18Comparison/Reconciliation ReportsAlthough these reports reside in the APEX package accessible from SoftA/R, it is recommended that LAB managers and department leads be introduced to this set of reports and participate in the monitoring and management of the data.It is recommended that these reports are reviewed regularly in order to identify potential problems in setup, interfaces or processes within the lab that could lead to manual correction and/or revenue loss.
Slide19LAB Comparison ReportsThe first set of reports resides in the “Lab–SoftBill Order Comparison” folder.
Slide20LAB Comparison ReportsLab–SoftBill Order Comparison: Report MenuTest Status Discrepancy Report
Order Discrepancy Report
Blood Bank Pending Report
Wrk
-Dep-
Loc
Discrepancy
Test Status Discrepancy – Cancellations
Units Discrepancy
Slide21LAB Reconciliation ReportsThe next set of reports resides in the “Lab-Mic-BB Reconciliation” folder.
Slide22LAB Reconciliation ReportsLab-Mic-BB Reconciliation: Report MenuReconciliation
Report
Order Lookup
Orders per Category
Lab-Mic-BB Procedure Lookup
Slide23LAB Reconciliation Report
Slide24LAB Orders per Category Report
Slide25Gene Calculation ReportsThe third set of reports resides in the “Gene Calculation” folder.
Slide26Gene Calculation ReportsReport MenuCompleted, No IBCs
Calculated, Never Transmitted
Completed, Non-Billable Panels
Cancelled, Charge Exists
Slide27Gene Reconciliation ReportThe final report resides in the “Gene Reconciliation” folder.
Slide28Gene Reconciliation Report
Slide29Completed, No IBCs Report
Slide30PHASE 2:INVOICING
Slide31Invoicing ProcessThe key to ensuring that orders do not get lost in the Invoicing process is regular review and correction of errors.
Slide32Invoicing Errors / IssuesInvoicing Message ViewerJob ManagerAPEX Errors Report
Bulk Utility
Slide33Invoicing Message ViewerThe Invoicing Message Viewer is available from the “Tools” menu on the Invoice Details tab in the Patient Account Module as well as the toolbar.
Slide34Invoicing Message ViewerAny errors claimed during the Invoicing process for the focused visit will appear at the end of the trace.
Slide35Invoicing Message ViewerThe Invoicing Trace also provides information to assist in determining why a particular billing rule, price or payor redirection rule was applied.Pre Invoicing RBS Rules that were applied
Final payor resulting from the execution of Payor Redirection Rules.
System Parameter Settings that were used during the Invoicing process.
Billing Rule and Price Redirections that were applied
Test Repeat Options
Outcome of various phases of the Invoicing process such as Bundling / Unbundling / CCI / Frequency Limits
Slide36JOB MANAGER
Slide37Job Manager: A Steadfast ToolJob Manager is the Application in which all scheduled and on demand jobs are registered. For each job executed, files are created as follows:Output Files contain any data pertaining to the successful execution of the job.
Error Logs contain any Errors or Warnings that were claimed during the processing of the Job.
Execution Logs contain Job Statistics.
Slide38Job Manager: Daily RoutineJob Manager should be reviewed daily for any terminations and a support task entered for investigation.
Slide39Job Manager: Daily RoutineTo quickly identify terminated jobs, change the view to ‘Status/Category’
Select ‘Terminated’ in the tree
Slide40Job Manager: Daily RoutineJob Manager Error Logs are one way to identify problems that occurred during scheduled job processing. To quickly identify jobs in an erroneous status, select ‘Errors’ in the tree.
Slide41Job Manager: Daily RoutineJob Manager Filtering - .NET
Slide42Job Manager: Daily RoutineIf the preferred method of Error review is the Job Manager Error Logs, it is important to look for “Additional” logs. A Job with multiple Error Logs can be identified by the presence of a checkmark in the ‘E+’ column in the grid.
Slide43Job Manager: Daily RoutineWhen the grid focus is on a job with multiple error logs, the ‘Additional Log’ icon in the toolbar becomes enabled.
When depressed, the following dialog appears.
Slide44APEX ERRORS REPORT
Slide45APEX Errors ReportThe APEX Errors report resides in the “Daily Monitoring” folder.The Report is available in both Summary and Detailed Views
Slide46APEX Errors ReportThe APEX Errors Report provides flexible search criteria and can be generated for Posting, Invoicing or Billing Errors by utilizing the “Error Group” filter.
Slide47APEX Errors ReportThe report qualifies the same errors that are available from the Job Manager Error Logs in a comprehensive, easy to view format that is exportable to excel.
Slide48Skip vs WarningErrors whose Action=Warning did not stop a process from completing successfully, however, should not be ignored as they can indicate potential setup and/or process related issues.Errors whose Action=Skip stopped the visit / invoice from moving through the Revenue Cycle and should be given the highest priority when reviewing errors.
Slide49APEX Errors Report
The “Error Action” filter provides the ability to manage errors whose action = Skip
Slide50Not Invoiced VisitsThe APEX Errors Report enables you to manage errors claimed during the Invoicing process; however, it is also important to know if there are visits in the system that are not even qualifying for one of your scheduled Invoicing jobs.
Slide51Bulk UtilityThe right combination of search criteria in Bulk Utility will enable you to identify visits that are not qualifying for the scheduled Invoicing job.
Slide52Bulk UtilityIn the “Visit” frame, select status = “Not Invoiced”
Slide53Bulk UtilityIn the “Other” box, enter custom search criteria
Slide54PHASE 3:BILLING
Slide55Billing Process As with Invoicing, the key to ensuring that orders do not get lost in the Billing phase is regular review and correction of errors encountered during this process.
Slide56Troubleshooting Billing IssuesDaily review of Job Manager for terminations and jobs resulting in an erroneous status.Monitoring and correction of billing errors identified in the Job Manager error logs and / or APEX Errors Report
Slide57NEW INVOICE AFTER BILLINGHOW DID IT HAPPEN????
Slide58Reinvoicing after BillingTopic / areas of setup discussed in the next segment include:Visit Alteration
System Parameter, DoNotCreateSameInvoice
Item Significance Setup
Slide59Visit AlterationThe Visit Alteration table enables you to define the number of days, from the date of service, that a billed visit can alter due to an update in one of the pre-defined fields.
Slide60Visit AlterationUsing Patient Type as an example, a setting of ‘30’ tells the system that it is OK to alter a billed visit based on changes to the patient type for up to 30 days from the date of service.
Slide61Visit Alteration – What Next?Simply allowing alteration of a visit does not necessarily mean that a new invoice extension will be created. By allowing a visit to alter, you are enabling the system to re-evaluate the new data in order to determine if a new invoice should be created.
Slide62Visit Alteration – What Next?Factors in determining if a new invoice will be created:Billing Rules, Prices, Payor Redirection RulesSystem Parameter setting for DoNotCreateSameInvoice
Item Significance Setup
Slide63Visit Alteration – Payor Redirection
If Visit Alterations for patient type are not allowed, or if the update took place after the maximum number of days from the date of service permitted by setup had passed, the system updates the patient type on the record in A/R, but will not alter the visit. In this case, the opportunity to re-evaluate the new patient type and apply one of the above payor redirection rules is missed.
The same scenario can occur for any other data element in price setup, payor redirection or billing rules.
Slide64DoNotCreateSameInvoiceThe System Parameter, DoNotCreateSameInvoice is used during reinvoicing to determine if a new invoice should be created.
Possible Settings:
0
- Always create a new invoice.
1
- Only create a new invoice if significant change or any change and invoice was already billed.
2
- Only create a new invoice if significant change
For options 1 and 2, if the change is not considered to be significant, the existing invoice is updated and a new extension is not created.
Slide65What is considered “Significant”??
Slide66Item Significance - SetupThe Item Significance table enables the user to determine which data fields, when modified, are significant enough to warrant a new invoice.
Slide67Item Significance - InvoicingAt the end of the Invoicing process, the system compares items on the existing invoice with items on the “to be created” invoice.If all items are the same (diagnosis, modifier, facility, etc), the system claims error code WRN18 (
New invoice would duplicate the previous one, not
created) and a new invoice is not created.
If some items are different, but the item significance value is set to “Non significant, do not create new invoice”, the system claims WRN26 (
WRN26: New invoice not created, items on previous invoice
updated) and updates values on the existing invoice.
If some items are different,
and the
item significance value is set to
“Significant
,
create
new invoice”, the system claims WRN37 (New invoice ext created. Original invoice
voided), voids the existing invoice and creates a new one.
Slide68Item Significance - Invoicing TracesInformation regarding the outcome of the Item Significance phase of the invoicing process can be reviewed in the Invoicing Traces.The applicable invoicing warning (WRN18, WRN26 and WRN37 ) appear at the end of the trace as well as changes to “significant” items that resulted in the creation of a new invoice.
Example:
New invoice extension created: Values on old invoice and new invoice that differ:
- item GLU(LAB)
– itfclty: old
= 'HACH', new = 'ALB1'
***** Voiding active invoices *****
** Invoice with extension 1 ***
VOID [BINS $-16.00]
Slide69Auditing ChangesWhen investigating changes that resulted in an altered visit or new invoice, Audit Trail provides information related to the old vs new values for a given database field, the date/time of the change and the user/process responsible for the change.The Audit Trail icon is available on various dialogs throughout the system.
Slide70Audit Trail Example
Slide71PAYORS
Slide72PayorsTopic / areas of setup discussed in the next segment include:Payor Tab vs Invoice DetailsSystem Parameter ReviewPayor Redirection
Slide73Payor Tab vs Invoice DetailsPolicies that appear on the ‘Payor’ tab in the Patient Account Module represent all policies for the patient, both current and historical, and should be thought of as “Patient Level” policies.
Slide74Payor Tab vs Invoice Details4.0 Line: Payor Tab Policies are created / updated in the SoftAR database based on information received in posting, update and ADT messages. Policies can also be directly added to this level by a user with proper security access.4.5 Line: Payor Tab Policies are created / updated in
a common, shared database based
on information received in
new order and ADT messages. Policies
can
also be
directly added to this level by a user with proper security access.
Slide75Payor Tab vs Invoice DetailsPolicies that appear on the ‘Invoice Details’ tab in the Patient Account Module immediately after the visit record is created in SoftA/R represent policies assigned to the order, received in the PV1 segment.
Slide76“Empty Payor” VisitsThe term “Empty Payor” refers to visits created for orders for which PV1 / Order Level policies were not received.The system provides the ability to define payor redirection rules for “Empty Payor” visits to assist in the automation of payor assignment when a pre-defined set of conditions is met on a visit.
Slide77“Empty Payor” VisitsIf, after Payor Redirection rules are executed, the visit being processed is still considered an “Empty Payor” visit, the system parameter, InvDefaultPayor, instructs the system how to proceed.
InvDefaultPayor Possible Values:
F: Primary payor
(On the Payor tab)
I: First non-client (On the Payor tab)
P: Private
E: Generate
IN81 error
Slide78MODIFIERS
Slide79ModifiersTopic / areas of setup discussed in the next segment include:Test Repeat ModifierModifiers in Billing Rules
Slide80Test Repeat ModifiersThe ‘Modifiers’ dictionary in SoftA/R setup allows you to designate a modifier as the ‘System Defined Repeat Modifier’
Slide81System ParametersTestRepeatedLogicTestRepeatOptionCheckCDMforRepeatMod
Slide82TestRepeatedLogicThe system parameter, TestRepeatedLogic instructs the system when it is permissible to add the test repeat modifier during Invoicing. This setting controls modifiers that would be added as a result of CCI logic as well as test repeat options
.
Possible options include:
0
= do not place globally defined modifier on item
unless
modifier is defined on procedure level
(=billing rule)
1
= place modifier on the
item
Slide83TestRepeatOptionsThe system parameter, TestRepeatOptions instructs the system how to create billable items for multiple instances of a test. Possible options include:0: First
no mod, other with mod, multiple
units (82310, 82310-91 x 2)
1: First
no mod, other with mod, single
units (82310, 82310-91, 82310-91)
2: All with mod, single units (82310-91, 82310-91, 82310-91)
3: All
with mod, multiple
units(82310-91 x 3)
4: All
no mod, multiple
units (82310 x 3)
6: All
no mod, single units
(82310, 82310, 82310)
These options can also be defined at the billing rule or payor levels.
Slide84CheckCDMforRepeatModThe system parameter, CheckCDMforRepeatMod instructs the system whether or not CDM should be considered when applying test repeat modifiers.
Possible options include:
0 - add modifier when CPT and CDM
are
the
same
1
- add modifier when CPT is the same (do not check CDM)
Slide85Modifiers in Billing RulesThe system provides the ability to define modifiers at the billing rule level.
Slide86THE ENDTHANK YOU