GE CENTRICITY BUSINESS V4.0 NEW FEATURES – Billing & Accounts Receivable (BAR)
FUNCTIONALITY
Batches

Filtering Batches in Batch
Manager

Restricting Changes to Batch
Controls in Charge Entry and
Post Receipts

875098724
Page 1 of 9
CURRENT FUNTIONALITY
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.
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.
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.




NEW FEATURES
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:
o New action code to access the audit trail
of batch control total changes.
o New audit trail screen and grid to view
batch control changes.
Now, action code F-Filter, allows you to specify
AND or OR conditions for filtering.
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
Using Security to Restrict
Access to Batch Controls

CURRENT FUNTIONALITY
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.




Performing Charge
Corrections



875098724
Page 2 of 9
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.

NEW FEATURES
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.
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
Posting Payments to ChargeCorrected Invoices

Restricting Charge
Correction and Invoice
Splitting on Reversal
Invoices

Using Invoice Inquiry for
Charge-Corrected and Split
Invoices


Using the Charge Correction
or Invoice Split Filter for
Batch Proof Prints

Charges-Capturing UB-04
Billing Information
Improved Display of BAR
Action Codes

Suppressing a Claim Form
When Using Split Invoice or
Charge Correction

875098724
Page 3 of 9

CURRENT FUNTIONALITY
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.
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.
Currently, if a user researches a chargecorrected invoice, there are 3 invoices
to examine: the original, the reversal,
and the new invoice.
The process is similar for split invoices.




UB-04 replaces UB-92 billing starting
on March 1, 2007.
Previously, in Charge Entry, Invoice
Inquiry and Charge Correction of Case
Invoice screens, there was no space for
additional action codes.

Previously, there was no way to
suppress claims when performing an
invoice split, or to define the Suppress
Claim default with charge correction.


NEW FEATURES
Now, an electronic receipts exchange can be set
up to determine if an invoice has been chargecorrected. 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.
Now, users can be restricted from chargecorrecting or splitting a reversal (this is a set up
option now).
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)
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.
This new feature allows the customer to comply
with new UB billing requirements.
Now, there is additional space for the following
action codes:
□ S-SDEs
□ E-Enable entries
□ Q-Claim Queue
□ T-More Actions
System build for this new release can now control
these claim suppressions.
FUNCTIONALITY
IT only – Using $INS in the
BAR FSC Rule bank
Capturing the Delay Reason
Code

CURRENT FUNTIONALITY
Previously, when IT defined rules in the
Bar Fsc Rule Bank, the $INS function
could not be used to return a FSC value.




Capturing the Transaction
Control Number
875098724
Page 4 of 9

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.

NEW FEATURES
Now, the $INS function can be used to return a
FSC from the patient’s registration FSC list or
from the FSC Dictionary.
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.
Now, you can capture the transaction control
number both manually and electronically. Also,
this can be included on the claim form.
FUNCTIONALITY
Specifying Individual
Charge Lines for Claim
Form Run
CURRENT FUNTIONALITY

Tracking Fatal/Non-Fatal
Edits in Billing History

Working with Modifier
Variables

875098724
Page 5 of 9

Previously, when viewing invoice
detail, a user could view the claim form
edits associated with an invoice.
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.



NEW FEATURES
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.
Now, a use can see if the edit was fatal or nonfatal.
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
Preventing the User from
Entering FSCs with the
Same FSC Grouping
Category in IMS


875098724
Page 6 of 9
CURRENT FUNTIONALITY
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.

NEW FEATURES
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
Preventing the User from
Entering FSCs with the
Same FSC Grouping
Category in IMS


Posting Payments in Charge
Entry Batches Using the
Payment Posting Form
875098724
Page 7 of 9

CURRENT FUNTIONALITY
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.
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.


NEW FEATURES
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.
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
Posting to Multiple Invoices
using Automatic or
Sequential Posting
CURRENT FUNTIONALITY


Storing All Rejections from
Payment Posting

Working with the Rule Bank
in Payment Posting to
Determine the Transfer to
FSC

Adding Deactivated
Procedures to Fee Schedules

875098724
Page 8 of 9
NEW FEATURES
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.
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.
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, 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.


Now, all rejections for all charges are posted.
Rejections are listed in the correct priority order in the
Rej field on the LIPP screen.

Previously, to determine profile amounts for
older payments, deactivated procedure
codes may need to be restored to the fee
schedules.

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.
Now, deactivated procedure codes can be added to
fee schedules.
FUNCTIONALITY
Registration – Finding the
Correct Patient More Easily
CURRENT FUNTIONALITY

NEW FEATURES
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


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.

Situational Data Elements
(SDEs)-Using the Patient
Height Situational Data
Element

Does not exist in this version.

875098724
Page 9 of 9
Now, by default, the system only displays active
patients.
Before selecting a patient, a user can view each
patient’s appointments and visits.
Now, standard input checking and display of these
numbers is available in:
o Dictionary fields
o Insurance Management System follow up
fields (IMS)
o DBMS tables.columns
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.