GE CENTRICITY BUSINESS V4.0 NEW FEATURES – Billing & Accounts Receivable (BAR)

FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
Batches /
  • Previously, the system did not monitor who made change to batch controls or the changes that were made. Only changes made via Front Desk batches were audited.
/
  • Now, in Batch Manager, the system now maintains an audit trail of batch control fields that were changed, and the users who made the changes.
  • This enhancement provides the following features:
  • New action code to access the audit trail of batch control total changes.
  • New audit trail screen and grid to view batch control changes.

Filtering Batches in Batch Manager /
  • Previously, in Batch Manager, the user could use action code F-Guided Filter, to filter the list of batches displayed. This filter was limited to only the columns in the grid.
/
  • Now, action code F-Filter, allows you to specify AND or OR conditions for filtering.

Restricting Changes to Batch Controls in Charge Entry and Post Receipts /
  • Previously, the system did not restrict users from editing any of the control fields on the Batch Control screens that are used to compare the actual transactions in Charge Entry and post Receipts. *Users had the ability to force-balance the batch controls even when the transactions were not correctly entered in the batch.
/
  • There is now security to restrict access to some of the fields on the Charge Entry Batch Control screen and Post Receipts Batch Control screen.

FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
Using Security to Restrict Access to Batch Controls /
  • Previously, the system did not restrict users from editing any of the control fields on the Batch Control screens that are used to compare the actual transactions in Charge Entry and Post Receipts. Also, when performing charge corrections, payments that needed to be reapplied were entered in payment batches. There was no limit to the number of charge correction transactions that a user could enter in a batch.
/
  • Now, the system provides security to restrict access to some fields on the Charge Entry Batch Control screen and the Post Receipts screen.
  • As part of the Charge Correction enhancement, when performing a charge correction, users can reapply payments in charge batches. Administrators can define limits on the number on charge corrections per batch that a user can enter.
  • The reapplication of payments in charge correction batches and the limitation of the number of charge corrections per batch can be secured by user.
  • Practice Manager would request security changes for their users.

Performing Charge Corrections /
  • During charge correction, the invoice is first evaluated to determine how the charge needs to be corrected and if any follow up work needs to be performed, such as payment posting or demanding claims. Previously, researching invoice activity within Charge Correction was limited.
  • In addition, the Charge Correction process was complex and time consuming, often requiring the use of multiple open application sessions to keep both charge and payment batches in balance.
  • The system did not accommodate charge corrections that involved placing charges on a different patient or invoice.
/
  • Via this enhancement, the charge correction process has been streamlined as follows:
□The CC process now displays critical account activity for the invoice before the user begins the charge correction process.
□Allows the user to choose to bring either charges forward on a new invoice, charges and payments forward on a new invoice, nothing forward, based on the reason for the correction (dependent on security).
□Allows the user to repost payment activity within a Charge Entry batch (dependent on security).
□Automatically reverses payment activity if you choose to repost payments.
□Guides the user through payment posting to ensure t hat all payments that were removed are reposted as necessary.
FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
Posting Payments to Charge-Corrected Invoices /
  • Previously, when the system tried to post a payment to a charge-corrected invoice, it generated an invalid FSC edit because charge-corrected invoices are transferred to a charge-correction FSC.
/
  • Now, an electronic receipts exchange can be set up to determine if an invoice has been charge-corrected. If this option is activated, the invoice to which the payment is trying to match has been charge-corrected, the system attempts to match to the new invoice created as a result of the charge correction.

Restricting Charge Correction and Invoice Splitting on Reversal Invoices /
  • Previously, there was no way to prevent users from trying to charge correct or split a reversal invoice created by a previously charge corrected or spit invoice.
/
  • Now, users can be restricted from charge-correcting or splitting a reversal (this is a set up option now).

Using Invoice Inquiry for Charge-Corrected and Split Invoices /
  • Currently, if a user researches a charge-corrected invoice, there are 3 invoices to examine: the original, the reversal, and the new invoice.
  • The process is similar for split invoices.
/
  • The enhanced version reduces the steps needed to research charge-corrected and split invoices by displaying all related invoices on the Invoice Inquiry screen by selecting action code H-Chg Crts/Splits for the invoice. (this includes Case and Front Desk charge corrections)

Using the Charge Correction or Invoice Split Filter for Batch Proof Prints /
  • As part of the Charge Correction enhancement, the system allows a user to filter batch proof prints to include only transactions associated with charge corrections, invoice splits, or both.

Charges-Capturing UB-04 Billing Information /
  • UB-04 replaces UB-92 billing starting on March 1, 2007.
/
  • This new feature allows the customer to comply with new UB billing requirements.

Improved Display of BAR Action Codes /
  • Previously, in Charge Entry, Invoice Inquiry and Charge Correction of Case Invoice screens, there was no space for additional action codes.
/
  • Now, there is additional space for the following action codes:
□S-SDEs
□E-Enable entries
□Q-Claim Queue
□T-More Actions
Suppressing a Claim Form When Using Split Invoice or Charge Correction /
  • Previously, there was no way to suppress claims when performing an invoice split, or to define the Suppress Claim default with charge correction.
/
  • System build for this new release can now control these claim suppressions.

FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
IT only – Using $INS in the BAR FSC Rule bank /
  • Previously, when IT defined rules in the Bar Fsc Rule Bank, the $INS function could not be used to return a FSC value.
/
  • Now, the $INS function can be used to return a FSC from the patient’s registration FSC list or from the FSC Dictionary.

Capturing the Delay Reason Code /
  • The system can be set up to prompt the user to specify a delay reason code based on payer requirements.
  • The delay reason code can also print on a claim form to view later for each invoice.

Capturing the Transaction Control Number /
  • When payers receive claims, they assign a unique number to each charge transaction, called the transaction control number. When payers respond to submitted charges, they include the transaction control number with each charge transaction. If a payer denies charges, you may need to later resubmit the charges to the payer. The payer may request the transaction control number to quickly find its match in their system. Previously, there was no way to capture the transaction control number electronically. You could specify a reference number manually in the Reference Number field , however, you could not retrieve this information to include on claim forms.
/
  • Now, you can capture the transaction control number both manually and electronically. Also, this can be included on the claim form.

FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
Specifying Individual Charge Lines for Claim Form Run /
  • In this release, a user can specify the charge lines to contain on the claim submitted in the next run. This features works in both paper and electronic claim runs.

Tracking Fatal/Non-Fatal Edits in Billing History /
  • Previously, when viewing invoice detail, a user could view the claim form edits associated with an invoice.
/
  • Now, a use can see if the edit was fatal or non-fatal.

Working with Modifier Variables /
  • The BAR Claim Form Generator (CFG) allows the user to set up claims, test claims and claim form variables. Previously, the modifier called Welfare Modifier from Dictionary was not capturing all modifiers. The variable was not returning any modifiers if more than one modifier existed.
/
  • The code has been updated to pull each modifier from a strong and write the modifier on an outgoing claim.
  • Additionally, several new modifier variables have been created to pull Blue Shield and Medicaid codes.

FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
Preventing the User from Entering FSCs with the Same FSC Grouping Category in IMS /
  • Previously, when trying to add a registration FSC that was in the same FSC grouping category as the FSC already in the Insurance Management System (IMS) for the patient, the error message was
"Not Found." This was misleading because it did not explain the reason the FSC could not be added to the patient.
  • In addition, when you file plan followup questions, the system that updates corresponding IMS FSC followup question has been modified to strip any followup question data that is not currently in use by the IMS FSC followup questions. This will prevent updates to the FSC audit trail for the same questions since there is no change to track.
/
  • In this release, the error message was modified to more accurately describe the problem. In this release, when adding a FSC in IMS, the system will continue to restrict you from having more than one registration FSC with the same FSC grouping category, but the way it is enforced by the system has been changed. You will be able to select a FSC where the FSC grouping category is the same as a FSC that is already in IMS for the patient. When the selected FSC has the same grouping category of any of the registration FSCs, you will receive the following error message: A FSC with the same Grouping Category already exists for this patient. A patient cannot be registered with more than one FSC with the same FSC Grouping Category. Also, if you list the FSCs before selecting one, FSCs in the same grouping categories as the registration FSCs will be displayed;
however, when one is selected, the error message will display.
FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
Preventing the User from Entering FSCs with the Same FSC Grouping Category in IMS /
  • Previously, when trying to add a registration FSC that was in the same FSC grouping category as the FSC already in the Insurance Management System (IMS) for the patient, the error message was
"Not Found." This was misleading because it did not explain the reason the FSC could not be added to the patient.
  • In addition, when you file plan followup questions, the systemthat updates corresponding IMS FSC followup question has beenmodified to strip any followup question data that is not currently inuse by the IMS FSC followup questions. This will prevent updatesto the FSC audit trail for the same questions since there is nochange to track.
/
  • In this release, the error message was modified to more accurately describe the problem. In this release, when adding a FSC in IMS, the system will continue to restrict you from having more than one registration FSC with the same FSC grouping category, but the way it is enforced by the system has been changed. You will be able to select a FSC where the FSC grouping category is the same as a FSC that is already in IMS for the patient. When the selected FSC has the same grouping category of any of the registration FSCs, you will receive the following error message: A FSC with the same Grouping Category already exists for this patient. A patient cannot be registered with more than one FSC with the same FSC Grouping Category. Also, if you list the FSCs before selecting one, FSCs in the same grouping categories as the registration FSCs will be displayed;
however, when one is selected, the error message will display.
Posting Payments in Charge Entry Batches Using the Payment Posting Form /
  • When doing charge corrections, there may be the need to reapply payments to other invoices for the patient or to a different patient. Currently, these payments are posted in payment batches in Post Receipts. To do this, the user must exit the batch and navigate to Post Receipts.
/
  • Now, the user can post payments directly from the Batch Control Form using Batch Action P and the form PC (Post Receipts- Charge Entry). This feature makes it easier to post and balance charge correction batches. When performing charge corrections, all transactions, charges, and payments can be posted in a single charge batch instead of posting some of the transactions in a payment batch and some in a charge batch.

FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
Posting to Multiple Invoices using Automatic or Sequential Posting /
  • Previously, if a user wanted to post payments to multiple invoices in the same patient account, it was necessary to select the invoices one at a time and post the payment.
  • When posting similar transactions to many invoices on the same account, payment posting actions were redundant. The system did not allow the user to select and post payments to multiple invoices.
/
  • Now, from Payment Posting, a user can post sequential payments to multiple invoices. From PCS, Payment Posting or Invoice Inquiry, a user can post automatic transfers or automatic credits/debits to multiple invoices.

Storing All Rejections from Payment Posting /
  • On the Line Item Payment Posting (LIPP) screen, if a user specified R at Post to post rejections, the system displays the Rejection Information screen. On this screen, the user specifies rejections and files the screen. They system then branches back to the LIPP screen and should display the rejections posted in priority order in the Rej field. However, at times, the system was not displaying the rejections for the first charge line, or the priority order of the rejections was incorrect.
/
  • Now, all rejections for all charges are posted.
  • Rejections are listed in the correct priority order in the Rej field on the LIPP screen.

Working with the Rule Bank in Payment Posting to Determine the Transfer to FSC /
  • The Rule Bank allows a user to alter the FSC to be billed. This functionality does not exist in Payment Posting to allow the user to alter the FSC to which the invoice was to be transferred.
/
  • Now, rules can be written to determine the “Transfer To” FSC in payment posting to handle exceptional situations that require the FSC to be different than the next FSC in the registration or invoice FSC string. This will result in the second insurance being properly billed.

Adding Deactivated Procedures to Fee Schedules /
  • Previously, to determine profile amounts for older payments, deactivated procedure codes may need to be restored to the fee schedules.
/
  • Now, deactivated procedure codes can be added to fee schedules.

FUNCTIONALITY / CURRENT FUNTIONALITY / NEW FEATURES
Registration – Finding the Correct Patient More Easily /
  • Previously, it was difficult to find the correct patient in the list of matching entries. The system included deactivated patients and did not let you view the appointments or visits for the matching
/
  • Now, by default, the system only displays active patients.
  • Before selecting a patient, a user can view each patient’s appointments and visits.

Standardizing the Entry and Display of Telephone Numbers and Social Security Numbers /
  • Previously, there were inconsistencies in the way the system accepted and displayed telephone numbers and social security numbers throughout the system.
/
  • Now, standard input checking and display of these numbers is available in:
  • Dictionary fields
  • Insurance Management System follow up fields (IMS)
  • DBMS tables.columns

Situational Data Elements (SDEs)-Using the Patient Height Situational Data Element /
  • Does not exist in this version.
/
  • A situational data element has been added to the charge entry functionality for BAR, Front Desk and TES, to record the patient’s height for instances when a certificate of medical necessity is required.

GE CENTRICITY BUSINESS V4 New Features_BAR_UsersGroup_123107.doc

Page 1 of 9