HPA Transaction Entry Training - University of Miamicet.med.miami.edu/documents/HPA Transaction...

HPA - Hospital Patient Accounting 1

CHAPTER 1 HPA Transaction Entry Training

HPA Transaction Entry Training

2 HPA - Hospital Patient Accounting

ObjectivesAfter completing this lesson, you will

• Know and understand the different types of Transaction• Be able to create and enter transactions in an HPA transaction batch• Be able to post Line Item payments and Rejections, ARCTR and FIFO transac-

tions• View and print transaction batches• Be able to balance batches• Be able to delete transactions from batches• Understand the functionality of Transfer/Release profiles and bottom screens• Be able to Move Transactions

Prerequisites• Introduction to VM/HPA• HPA Concepts

Access 1. VM/HPA2. One of the methods in the table below.

TABLE 1. Payment and Transaction Access Paths

VM/HPA Function Activity Action Codes

4 - HPA Activities 2 - Transaction Entry

1 - Patient Actions PB - Patient Billing

TE - Transaction Entry

2 - Patient Rep System 1 - Patient Rep Process W - Work Visit

LI - Line Item Payment Posting

4 - Hold Bill Worklist 15 - Hold Bill Worklist LI - Line Item Payment Posting

University of Miami: Clinical Enterprise Technology 3

The Goal and Benefits of Payment, Transaction and Denial Posting in the HPA applica-

The Goal and Benefits of Payment, Transaction and Denial Posting in the HPA application.The goal payment posting is to accurately and quickly enter payments received from payors, patients and guarantors into the IDX system. In addition to posting payments, debit and credit transactions and rejections can be posted on several lev-els: by line item for each charge entered on a Visit, on the Visit or on the Account.

The benefits of HPA Payment and Transaction Posting are:

1. Patient satisfaction is increased because the balances on patient’s Visits and Accounts are current and accurate.

2. Increased ability to analyze Accounts Receivable in detail for specific revenue codes, APCs and HCPCS and in summary with accurate, current data by payor, patient and Visit. This gives the enterprise more information with which to negotiate contracts with payors.

3. Increased ability to analyze payor denials to determine the root cause of the denial and take action to correct them, if possible.

4. Improved cash flow and reduction of manual effort to process secondary and tertiary claims and patient billing.

Use of this DocumentThis document should be used in conjunction with the Enterprise Process Work-flows for the Back End Payment Posting Flow.



IntroductionTransaction Entry is the means by which payments, rejections, some contractual adjustments and other credits, debits and transfer transactions are entered in the IDX VM/HPA application.

The data comes from payor Explanation of Benefits (EOBs), patient or guarantor payments and from debit and credit transaction sheets written by Patient Financial Services (PFS) staff. Denials, defined as zero payments from insurance payors, are also entered in the system so they can be tracked, analyzed and corrective steps taken to eliminate or reduce them.

These transactions can be entered in the IDX system in three ways. This lesson cov-ers Manual Transaction Entry.

TABLE 2. Transaction Entry Methods

Method How entered Examples

Manual Payment and Transaction Posting

Transactions entered manually.

Payments, contractual adjust-ments and denials from insur-ance payors, patient payments and PFS debits, credits and transfers.

System Generated Transactions automati-cally generated by the system.

Write-off (credit) transactions are created by the system based on Transfer/Release Pro-files and Automatic Write-offs (ATWOs).

Interface Transactions created in another application and interfaced, or brought into, the VM/HPA application.

Medicare and Medicaid pay-ments are received electroni-cally


Batches and Batch Controls

Batches and Batch ControlsBatches are groupings of related charges, payments and other types of transactions. Batches are created by users and by the system. Transactions can be entered into a new or existing batch. Each batch is owned by the user who opened the batch. Most users have access to only their own batches and cannot access the batches belong-ing to others.

Transaction batches, which include payment batches, have controls on the number of transactions in the batch and total dollars. One person will manually tally the controls. Another person will enter the controls and the transactions in the system. The system will automatically calculate the batch totals and indicate if there is a discrepancy. If there is a discrepancy, the two sets of numbers must be reconciled before the batch can be processed to update reports. However, as soon as each entry is filed, the patient’s Account and Visit are updated.

Batch Header Slip

The Batch Header contains the posting date, total number of transactions, total pay-ment dollars and total adjustment dollars in the batch. All of these totals are also calculated by the system automatically. According to the Manual Payment Posting Flow, there will be one deposit slip and one batch for each EOB. All self-payments will be batched together into one batch.

Balancing the BatchAfter all the transactions are entered and the user is returned to the Batch Definition screen, the system displays 3 columns of totals. The totals it calculated from the transactions entered, the totals from the Batch Header and the variance if any. If there is a variance, the user must research it and fix it before the batch can posted to the system reports by Night Jobs. The user will follow the Manual Payment Posting Flow and the Policies and Procedures to ensure that the batch is in balance with the Batch Header Slip.

Exiting the Batch

When all the transactions have been entered and the batch is in balance, the user selects Action X from the Transaction Entry screen and files (using F10) the batch. If the batch is in balance, it will be posted to the reports by Night Jobs. If the batch



in out of balance, the batch will not be posted to the reports by Night Jobs, but the individual transactions will have been posted to the Visits. All batches must be in balance and not in a Hold status before the end of month processing can occur.

Payment and Transaction Concepts

Manual Data Entry FormsIncluded with each check from an insurance payor is an Explanation of Benefits (EOB) which, for each charge, lists the payments and contractual adjustments for the charge. If there is no payment, the reason for the denial is included on the EOB. Many EOBs list payments and contractual adjustments for each line item in the charge.

Patient payments and patient guarantor payments are received from a lockbox list or from individual payments.

Debit, credit and transfer transactions are received on paper forms from the PFS billers and collectors.

Transactions are grouped together in batches by the Back Office staff. Usually they are grouped by a common data element, such as payor or type of transaction. Each batch will have a Batch Header Slip.

Transaction EntryBefore transactions are entered, the system displays two screens:

1. A Batch Selection screen to enter the name of the batch is entered for easy iden-tification. The transaction entry person’s ID and the date the batch is created are automatically put on the batch by the system.

2. A Batch Definition screen to enter the totals from the Batch Header Slip and to enter defaults that are common to all the transactions in the batch. Entering defaults save time and keystrokes because the defaults will be automatically entered into each entry without needing to be keyed in. These are called Batch Duplication fields.

After the Batch Description screen is completed, all the transactions in the batch are entered, including the rejections. Rejections are defined as charges or specific parts



of charges whose payment is zero, meaning that the payor declined to pay for the charges. A payor may pay for part of a service but not the entire amount. In this case, both the payment and the rejection amounts will be posted.

As soon as a transaction is entered, the system updates the Visit with the transaction and recalculates the A/R balances on the Visit. This is called ‘real time’ posting. The system does not update the reports with the transactions until the batch is in balance, is not in a Hold status and has been processed by Night Jobs.

When all the transactions in the batch have been entered, the Batch Definition screen redisplays for balancing the batch.

ARCTR - Accounts Receivable CountersThe A/R counter identifies the ‘bucket’ in which the account receivable dollars sit. Payments, rejections and other transaction types are posted to this ‘bucket’ by post-ing to the A/R counter (ARCTR).

For each occurrence of a transfer of dollars from one FSC to another, the IDX sys-tem creates an A/R counter (ARCTR) by using the Visit number and adding a sequential number (1,2,3, etc.) suffix to it. ARCTR 0 (zero) is for patient payments before the first bill is created. Copays and deposits are posted to ARCTR 0.

Ex: FSCs on Visit 123456 are an HMO and then a commercial insurer. ARCTR-0 is automatically created with the Visit for patient payments prior to billing. When charges were entered, ARCTR 1 would be created for the HMO. If the Visit number is 123456, the ARCTR would be 123456-1. The proration credit adjustment would be made to ARCTR 1. When then claim is sent to the HMO, the reference number of the claim is 123456-1. When the HMO pays or denies the claim, they print this number on the EOB. If there is a -# after the ARCTR, it is an indication of the line item on the ARCTR. Ex: 123456-1-2H indicates Visit 123456, ARCTR 1, line item 2. The H will always appear. It signifies Hospital.

When the next plan, the commercial plan, is released and the remaining balance is transferred to it, ARCTR 2 is created, 123456-2. The claim to the commercial plan has the reference number 123456-2 on it. When the payment is received from the commercial plan, it is posted to the 2nd ARCTR. When the A/R dollars are trans-ferred to the patient responsibility, a third ARCTR is created, 123456-3. When the payment is received, it is posted to ARCTR 3, 123456-3.



Transaction TypesEach VM/HPA transaction has one Transaction Type. The table below lists the five transaction types and the impact it has on the Accounts Receivable (A/R).

TABLE 3. Transaction Types

Transaction Type Used to

A/R Impact

BADJ

Billing Adjustment

• Indicate the expected payment from the insurance plan, the prorated amount.

• One BADJ for each plan on the Visit

• Once the plan has been ‘final billed’, the system creates the BADJ.

• Every time the system creates a BADJ, it creates an ARCTR.

+

DADJ

Debit Adjust-ment

• Adjust proration when not rebilling• Fix an incorrect ARCTR posting• Write off credits• Increase A/R

+

CADJ

Credit Adjust-ment

• Post a contractual adjustment• Decrease A/R• Proration automatically creates CADJs for

contractual adjustments

-

PAYM

Payment• Post a payment to a Plan on a Visit. -

TADJ

Transfer Adjustment

• Manually transfer money from one Plan to another on a Visit or to another patient’s Visit.

• Each transfer transaction creates a BADJ because it moves A/R dollars from one plan to another. The TADJ is created immediately following the BADJ.

• Transfer money from one ARCTR to another• Transfer money to Bad Debt

no A/R impact.

( - on one Plan and + on another Plan)



Transfer Release ProfilesTransfer/Release Profiles automate the transfer of a Visit balance from the current Plan’s ARCTR to the next Plan and then the release of the next Plan associated with the Visit for claim production or guarantor billing. Transfer/Release Profiles work in conjunction with Proration. It replaces the need for the user to manually Transfer the Balance (TB Action Code) and Release Next Plan (RN Action Code) activities.

There is no separate activity through which the Transfer/Release Profile is accessed. When an insurance payment to which a Transfer/Release Profile has been attached is entered, the system displays a Transfer/Release bottom form in the Transaction Entry screen.

The actual transfer and release process is based on the payment percent of the BADJ of the ARCTR. The percent for Medicare will differ from the percent for HMOs. Percents can also differ within a payor for inpatient and outpatient visits. Transfer/Release Profiles may also define transfer limits for the co-payment, deductible and non-covered portions of a plan.

The profile percent is the amount the system is looking for in order to transfer the balance to a new ARCTR and release the next plan automatically.

Example: A patient has a Commercial primary plan and a HMO secondary plan. The Transfer/Release Profile for the Commercial plan (the primary plan) is 80% for outpatient and inpatient visits. The amount of the Commercial BADJ is $1000.00. The payor pays $800.00 or more (80% or greater).

1. The user enters the $800.00 payment to the Commercial ARCTR (this will usu-ally be ARCTR 1).

2. The BADJ a bottom form displays. See next page for example.3. The user enters all visit data from the EOB in the bottom form field. All fields

may not be present on the EOB. Usually at least the original charge amount ($1000.00) is present. Also copay, deductible or coinsurance amounts may be present.

4. The user presses F10 to return to the main part of the form.5. The system transfers the remaining balance ($200.00) on the BADJ to the sec-

ondary plan on the visit by creating a BADJ for the secondary plan.6. The system releases the next plan for queueing for claim or guarantor billing

production.



Example: The Transfer/Release bottom form filled in with the Gross Charges and all other information provided on the EOB.

FIGURE 1. Transaction Posting - Transfer/Release bottom form (IBTE.S1)

To view the Transfer/Release Profile for a Visit,

1. VM/HPA2. Function 13. Lookup the Patient, preferably by entering an H and then Visit number.4. CV Action Code if the Visit number was not part of the lookup.5. PI Action Code, Plan Inquiry.6. Select the Plan.7. V Action Code to View the Plan.8. 6 to View the Transfer/Release Profile and answer YES to view on the screen.



FIGURE 2. Transaction Posting - View Transfer/Release Profile

The Transfer/Release for the Athena Jupiter’s Visit 361626 is

• 85% payment of BADJ amount to transfer the balance to the next plan• 85% payment of BADJ amount to release the next plan• There will be an automatic adjustment of 2% of the BADJ if it does not exceed

$50.00.• The transfer will not take place for any amounts entered in the “Other” field in

the Transfer/Release bottom form on a payment (see screen on previous page).



Batch Definition Screens

Transaction Entry - Batch Definition Screen 1In the first Batch Definition screen, the user creates or identifies an existing batch. If accessing an existing batch, data about that batch is displayed.

FIGURE 3. Transaction Entry - Batch Definition Screen 1 (IBTS.S1).

TABLE 4. Transaction Entry - Batch Definition Screen 1 (IBTS.S1)

Field Description

Batch # G - Generate a new batch

# - Enter an open batch number for data previously entered

? or F12 to list your open transaction batches and select one

?C - Open batches by creation date

?O - Open.batches

?P - Batches by posting date

?U - Batches by a specific user

The above may be combined into one lookup. Ex:?UOC - Batches by a specific user, creation date and only the open ones.

Description Enter the description according to Policy and Procedures.The description may be changed when re-entering the batch.

User Initials of the user who created the batch.



Batch Type “Payment/Adjustment” is defaulted in by the system.

Current Batch Sta-tus

O - Open and accessible. This is the status of new batches.

I - Open and in use by a user.

N - Being processed by Night Jobs and can no longer be accessed.

C - Closed by Night Jobs and can no longer be accessed.

P - Batch proof has been printed.

H - On hold. Batch can not be closed by Night Jobs until it is taken off hold.

B - Out of balance. Batch will not be closed by Night Jobs until it has been corrected and is in balance.

Date/Time Batch Cre-ated

Date and time the batch is created is displayed.

Date/Time Batch Last Entered

The most recent date and time that the batch was accessed by a user is displayed. When creating a batch, this is the same as the date and time the batch was created.

Current Number of Transac-tions

The current number of transaction in the batch is displayed. Ini-tially this number is zero.

Periods The period in which the transactions’ date of service occurred (providing the period is still open) is displayed. If the date of ser-vice is prior to an open period, the system selects the oldest open period. It is possible to see two open periods if transactions are entered with varying dates of service across month’s end.

TABLE 4. Transaction Entry - Batch Definition Screen 1 (IBTS.S1) (cont.)

Field Description



Transaction Entry - Batch Definition Screen 2

In the second Batch Definition screen, the user enters the controls from the Batch Control sheet, enters responses for cursor flow when entering the transaction and enters defaults to improve efficiency and potentially eliminate data input errors.

FIGURE 4. Transaction Entry - Batch Definition Screen 2 (IBTC.S1

TABLE 5. Transaction Entry - Batch Definition Screen 2 (IBTC.S1)

Field Definition

BATCH BALANCING FIELDS

Batch Balancing fields are used to record numbers that are useful in balancing a batch. If the actual totals calculated by the system do not match the control totals entered by the user, the batch maintains a status of Not in Balance.

Control Column: Data entered by the user from the Batch Header Slip.

Actual Column: Total of all the data entered in the batch. This figure is calculated by the stem

Variance: The difference between the Control Column and the Actual Column. This figures is calculated by the system.

Total Payments Enter Total Payments from the Batch Header Slip. Enter the payment total with a minus sign.



Total Adjustments Refer to Policies and Procedures to determine if adjustments should be entered for the batch from the Batch Header Slip.

If entered, enter with a minus sign.

Total Paym+Adjs System calculates the total of the payments and adjustments.

Total Transactions Enter number of Transactions from the Batch Header Slip

BATCH CONTROL FIELDS

Batch Control fields can help reduce data entry time if transaction batches are grouped by similar transactions.

Ask Trans Date Always use N

Y - Have the cursor stop in the Transaction Date field.

N or Blank - Cursor does not stop in the Transaction Data field. If N, enter Trans date in Batch Duplication Fields to automatically have the system default the Transaction Date in each transaction. Also, the user can use arrow keys to move cursor to the Transaction Date field if N is entered.

Ask Trans Com-ment

Y - Have the cursor stop in the Trans Comment field for data entry.

N or Blank - Cursor does not stop in the Trans Data field for data entry. If N, enter Trans Comment in Batch Duplication Fields. User can use arrow keys to move cursor to the field.

One Trans per Patient (Y/N)

N or Blank - Multiple transactions per Visit. Cursor returns to transaction entry after each transaction.

Y - Only one transaction per Visit. Cursor returns to patient prompt after each transaction.

Ask Trans Code Y - Have the cursor stop in the Trans Code field for data entry.

N or Blank - Cursor does not stop in the Trans Code Data field for data entry. If N, enter Trans Code in Batch Duplication Fields. User can use arrow keys to move cursor to the field.

Ask Payment PPS N or Blank - Cursor does not stop for collection of the Pro-spective Payment System returned by the payor

Y - To have the system stop for collection of the Prospective Payment System returned by the payor.

TABLE 5. Transaction Entry - Batch Definition Screen 2 (IBTC.S1) (cont.)

Field Definition



Require Dollar Format

Recommended to use N.

Y - To require the entry of cents in the amount field.

Ex: If amount is 10 dollars, enter 10.00.

N - To enter the period and cents only when needed.

Ex: If amount is 10 dollars, enter 10.

Receipts Printer Y - To print transaction receipts from the Special Action field (SA) in transaction entry.

N - To not print receipts for the transactions entered.

Default Covered in LIPP

Always use N

N - To not allow the system to default in the expected covered amount from the payor

Y - To allow the system to default in the expected covered amount from the payor.

Accelerated LIPP Always use N or leave Blank.

N or Blank - To require user to specify the next line item to be posted.

Y - To have the system automatically go the next line item in the system to be posted. This is a very dangerous option to choose as there is no guarantee that the line items on the EOB are in the same order as they are on the screen display.

BATCH DUPLICATION FIELDS

Data entered in these fields automatically defaults into the transaction entry fields. If the data entered in these fields is changed during the entry of transactions in a batch, the changes will only affect new transaction entries. It will not affect any existing entries in the batch. These are optional fields.

Transaction Date Follow Policies and Procedures to know what date to enter.

If all the entries of the batch are for one transaction date, enter the date in this field.

This field must be filled in if the Ask Trans Date field is N.

Comment If all the entries of the batch have one comment, enter the comment in this field. This is useful for entering the same comment on many entries. Follow Policies and Procedures to know what comments should be entered.


Field Definition



Transaction Code Enter the Transaction Code to be used on all entries in the batch. This duplication field can be used when all the transac-tions in the batch have identical code.

Prefix This duplication field can be used as a prefix for the comment field. It is useful for entering “CK# “when posting patient payments so that only the actual check number has to be entered in the comment field of each transaction. If there is only one check per batch, enter the check number after the CK# text.


Field Definition



Transaction Entry Types

There are three types of Transaction entry actions. Each has its own data entry screen. The initial screen that is displayed is the E screen. If Action E is selected, data entry is on that screen. If other codes are entered, another data entry screen dis-plays.

The codes are listed below in the order of data entry preference.


TABLE 6. Transaction Entry Types

Code at Action prompt Description

Data Entry Screen

L Line Item Payment Posting (LIPP).

- Payments, debits or credits post to each specific line item in the ARCTR.

- If the EOB has line item specific data, use this option. If some, but not all, of the EOB has line item specific data, use this option and select Action R (Post to ARCTR) from within this screen to post the full amount to the Visit.

ITR2.A

E Enter total claim amount. No line item detail provided by payor.

- Payments, debits or credits post to the entire ARCTR, not any specific line items.

- If the entire EOB does not have line item specific data, use this option.

IBTE.1

F FIFO Posting. For use when posting to an account and the specific Visits are not identified.

Payments, debits or credits post to ARCTRs, from the oldest to the most recent.

- Use when posting patient payments from a patient statement.

IFFO.S1



Transaction Entry - Initial screen (IBTE.S1)

This screen is the entry point for all data entry for payment and transaction entry. When an Action is selected, a screen specific for the action may be displayed.

FIGURE 5. Transaction Entry - Initial Screen (IBTE.S1)

The first three Action Codes listed are in recommended order for data entry.

TABLE 7. Transaction Entry - Initial Screen Action Codes

Action Code Description

L - Line Item Payment Posting

(LIPP)

- Action code to Enter Line Item Payments and Rejections

E - Enter Transactions

- Action Code to Enter non-Line Item transactions

F - FIFO - Post patient payments to multiple visits using the First In-First Out (FIFO) method.

A - Patient Actions

- Access the Patient Action screen (VM/HPA Function 1)

B - Batch - Branches back to the Batch Definition screen. Convenient for changing the batch balancing, control or duplication fields.



D - Delete Transactions

- Delete unbilled transactions on a Visit. Other batches may be accessed, but the deleted transaction goes into the current batch.

NOTE: Use this Action Code to delete transactions that have not been billed. Do not enter a credit or negative transaction if the transaction can be deleted.

I - Inquire - Inquiry into specific transactions in this batch. Also provides the capability to delete a transaction entered in this batch.

X - Exit - Exit the transaction entry process.

TABLE 7. Transaction Entry - Initial Screen Action Codes



Action L - Line Item Payment Posting (LIPP)

Action L - Line Item Payment Posting (LIPP)The first screen is the initial screen shown above. Input an L at the Action prompt. Other actions available are listed below.

FIGURE 6. Transaction Entry - E Action Code Screen (IBCE.S1

TABLE 8. Transaction Entry - Actions (IBCE.S1)

Action Field Description

L - Line Item Payment Posting (LIPP)

- Post Line Item Payments and Rejections

A - Patient Actions



D - Delete

Transactions


NOTE: Delete transactions that have not been billed rather than entering a credit or negative transaction.

E - Enter

Transactions

- Post non-Line Item transactions




L



Line Item Selector Screen ((IBCE.S1)

Immediately after entering L at the Action Code prompt, the Line Item Payment Posting selector screen is displayed.

Line items are displayed and posted to specific ARCTRs. Before the Line Items are displayed, the patient, Visit and ARCTR must be identified. The Action Codes will be displayed only if an Patient/Visit#/ARCTR combination has not been input at the Patient prompt.

The most efficient method to post to Line Items is to enter the specific Visit, ARCTR and Line Item information at the Patient prompt. The format is described in the table below.

FIGURE 7. Transaction Entry - LIPP Screen 1 (ITR2.A)

TABLE 9. Line Item Payment Posting Screen 1 Fields

Field Description

Patient Enter the Visit#-ARCTR. If this number is entered, the LIPP Screen 2 is displayed immediately. Ex: 548946-1. This number is usually on the EOB.

If just the Visit# number is provided, enter it.Ex: H54946

If the Visit#-ARCTR is not provided by the payor, identify the patient by any of the standard methods.

MRN Organization MRN displays



ARCTR Bal The balance of the ARCTR is displayed after the ARCTR is identified.

Vis # Enter Visit number or ? to select Visit (shown above). If the Visit number was entered in the Patient field, it will be dis-played here.

Plans The mnemonics of all the Plans on the Visit

Seq Y defaults in. It indicates the payors on the Visit are billed sequentially.

ARCTR The number of the ARCTR

Plan The full name of the Plan on the ARCTR

FSC The full name of the FSC on the ARCTR

Type The type Hospital will display for all entries.

LIPP Visit Selector Fields

Adm # Visit number

Adm Date Admission Date

VTyp Visit Type

Dates of Svc Visit Dates of Service

ARCTR ARCTRs. The number will be followed by the letter H (for Hospital). Do not use the trailing H when entering an ARCTR in the Patient name field to identify the Visit/ARCTR combination.

Plan The Plan of the ARCTR.

FSC The FSC of the ARCTR

Balance The Balance of the ARCTR

LIPP Visit Selector Action Codes

B - Balance Only/All Visits

To display all ARCTRs on a Visit. Initially only ARCTRs with balances are displayed. This is a toggle switch. Sample is displayed on next page. Compare it to above display.

I - Inquiry To display detail information about the ARCTR. A sample is displayed on next page.

TABLE 9. Line Item Payment Posting Screen 1 Fields

Field Description



Line Item Selector Screen Action Code B - Balance Only/All Visits Action Code

When the B Action Code is invoked, all ARCTRs on the Visit are displayed. In the following screen, ARCTR-2 has not been billed yet so it does not have a balance. It was not displayed in the initial display of the screen (see above). ARCTR 0 will always display as it is the ARCTR used for deposits and copays.

FIGURE 8. LIPP Selector Action Code B - Balance Only/All Visits (ITR2.A)

Line Item Selector Screen Action Code I - Inquiry Action Code

This is the ARCTR inquiry screen. Only the first page of the Inquiry screen is active.

FIGURE 9. LIPP Selector Action Code I - Inquiry (ITR2.A)



Line Item Payment Posting Screen 2 (IBTE.S1

Once the Patient, Visit# and ARCTR are specified, the system displays the line items.

Select Line Items in the order on the EOB to ensure that all of the EOB lines are posted. There may be some Line Items on the ARCTR that the payor has not identi-fied on the EOB and the order of the line items on the EOB may not be the order in the IDX system.

FIGURE 10. Transaction Entry - LIPP Screen 2 (IBTE.S1)

The fields in the top part of the screen have been described in the previous section.

TABLE 10. Line Item Payment Posting Screen 2 fields (ITRL.A)

Field Description

# ARCTR Line #

HCPCS/IC The HCPCS or Revenue Code (IC) code for the procedure

Mods Modifiers on the Charge

Description Procedure Code description

Service Date Date of Service

Exp Amt Expected remittance amount

Charge Charge amount



Line Item Payment Posting Screen 2 Action Codes

TABLE 11. Line Item Payment Posting Screen 2 Action Codes


P - Post Transactions To post the payment, debit or credit transaction.

See “Line Item Payment Posting - Posting Screen (ITRL.A)” on page 27.

R - Post to ARCTR To post transactions at the ARCTR level instead of the line level. This is equivalent to Transaction E described in the next section.

See “” on page 33.

A-APC Summary The system displaces any APC results for any HCPCS revenue codes associated with the selected item.

C - Change ARCTR To post to a different ARCTR for this Visit

I - Inquiry To view transaction detail for the line item.

N - New Patient To permit entry of a new patient

See “Transaction Entry - LIPP Screen 1 (ITR2.A)” on page 22.

T - Display/Hide Transactions

A toggle switch to display all the transactions that have been associated with the line items or just display the line items in summary format.



Line Item Payment Posting - Posting Screen (ITRL.A) The fields above the black line describe the Visit and ARCTR. See “Line Item Pay-ment Posting Screen 1 Fields” on page 22.

After the amount field is entered, the Adjustment/Transfer Balance bottom form displays for entry of additional data. Then, after pressing F10, the cursor stops at the Special Actions (SA) field for posting rejections, deleting transactions and other actions.

FIGURE 11. Transaction Entry - LIPP Posting Screen (ITRL.A)

Line Item Payment Posting - Posting Fields (ITR4.A).

TABLE 12. Line Item Payment Posting - Posting Fields (ITR4.A)

Field Description

Line # Line # on ARCTR

Svc Dt Date of Service

Charge Charge amount previously entered

Expected APC Expected APC



Date Post Date. Refer to Policies and Procedures for appropriate date. If a date was entered in the Batch Duplication Transac-tion Date field, it will be defaulted here. It may be overridden. If the Batch Control field Ask Trans Date is answered N, the cursor will not stop in this field.

Code Enter payment or transaction code. Codes are 5 digits.

• Payment Codes: The last 3 digits of payment codes are 510.

• Rejection Codes: The last 3 digits of rejection codes are 600. When used, the system defaults zero into the amount field.

• If a code was entered in the Batch Duplication Transaction Code field, it will be defaulted here. It may be overridden.

• If the Batch Control field Ask Trans Code is answered N, the cursor will not stop in this field.

Type Transaction Type associated with the selected Code. The sys-tem defaults this field. It cannot be overridden.

Comment • If a comment was entered in the Batch Duplication Comment field, it will be defaulted in and may be overridden.

• If text was entered in the Batch Duplication Prefix field, it will be defaulted in. The user may add to it. Ex: if the prefix is CK#, the user can add the specific check number for the line item. Adding 1234 will give the value CK#1234.

• Enter a free text comment for the line item.• If the Batch Control field Ask Trans Comment is

answered N, the cursor will not stop in this field.Rev Enter the Rev Code (IC) from the EOB. If may be different

than the Rev Code from the charge which defaults into the field.

TABLE 12. Line Item Payment Posting - Posting Fields (ITR4.A) (cont.)

Field Description



Amount • Enter the transaction amount.• If a rejection transaction code was used, the system

defaults a zero into this field.• If a partial payment, just enter the paid amount.

SA Special Actions

• A - Patient Actions. The VM/HPA Function 1 screen displays

• C - Claim Reference number. A bottom screen (ICRN.A) displays for entry of the payor’s line item or claim reference number.

• D - Delete Transaction. To delete a line item transac-tion that has not been billed yet.

• J - Rejection Entry. To enter partial or full line item rejections. See “” on page 30.

• U - Enter UB92 data: Occurrence, value and condi-tion codes

• V - Visit Notes. The Visit Notes B screen displays for data entry.

TABLE 12. Line Item Payment Posting - Posting Fields (ITR4.A) (cont.)

Field Description



Transfer/Release Bottom form fields (ITAA.S1)

The Transfer/Release Botttom form displays for certain specific plans. When it appears, the data from the EOB needs to be entered.

Refer to Policies and Procedures for specific instructions for posting to these fields.

These fields may be displayed when posting in L- Line Item Payment Posting and E-Transaction Entry (non-Line Item transaction entry).

TABLE 13. Payment Posting-Transfer/Release Bottom form fields (ITAA.S1)

Field Description

Transaction Code Transaction code for contract adjustment defaults from Plan Master.

Gross Charges Enter the Charges listed on the EOB.

Deductible Enter the deductible amount if listed on the EOB.

Leave blank if none.

Coinsurance Enter the coinsurance amount if listed on the EOB.

Leave blank if none

Non-Covered Enter the non-covered amount if listed on the EOB.

Leave blank if none

Copayment Enter the copayment amount if listed on the EOB.


Other If an amount other than the above is on the EOB, enter it here.




Line Item Payment Posting - Rejection - Special Action JUse Special Action (SA) J-Rejections to post full or partial line item rejections. When the Special Action J is entered a bottom form displays for entry of rejection data.

The only data entry difference between a full and partial rejection is the Transaction code used at the Code field.

1. Partial Line Item Rejection: Use a payment Transaction Code (ends in 510) and enter the payment amount in the amount field. Then use Special Action J - Rejection to enter the rejection data.

2. Full Line Item Rejection: Use a rejection Transaction Code (ends in 600). The system will default zero into the payment Amount field. The Special Action J-Rejections does not need to be used as the system knows to display the bottom form because of the Transaction Code used. Just press Enter until the bottom form displays.

The first screen below is the entry in the LIPP using a rejection Transaction code. The second screen is the entry of the rejection data.

FIGURE 12. Transaction Entry - LIPP Full Rejection (ITR3.A)

Press Enter after the amount field to display the Rejection data screen. It is not nec-essary to select Special Action J. Each rejection code has been pre-set to display the rejection bottom form.



FIGURE 13. Transaction Entry - LIPP Full Rej Bottom Form (IREJ.A)

TABLE 14. LIPP Full Rejection Bottom Form fields (IREJ.A)

Field Description

>>> Follow Policies and Procedures for data entered in these fields.Reason Code Enter the rejection codes from the EOB. Each

rejection code is entered on a separate line.

This is a recurring field. As soon as the Enter key is pressed, the entry scrolls and a new entry appears.

Description The description of the rejection code defaults in.

Rejection Category The category of the rejection code defaults in

Ref Number If there is a reference number on the EOB for the rejection code, enter it here.



Rejection Amount Enter the amount of the rejection. from the EOB. It is important to capture that amount if it is different from the default value. The default is calculated by the system (Line Item Charge amount - Line Item Amount paid).

Message If there is a message associated with the rejection, it can be entered here.

NOTE: This message appears on the patient state-ment.

TABLE 14. LIPP Full Rejection Bottom Form fields (IREJ.A)

Field Description



LIPP - Action Code T - Display Hide Transactions.

This is a toggle switch. It is effective only after Line Items have been posted to an ARCTR. The T Action Code is accessed on the LIPP screen 2. See “Line Item Pay-ment Posting Screen 2 (IBTE.S1” on page 25.

FIGURE 14. LIPP - Action Code T - Hide Transactions (ITRL.A)

Invoking the T Action Code displays the transaction details.

FIGURE 15. LIPP - Action Code T - Display Transactions (ITRL.A)


Action Code E - Enter Transactions

Action Code E - Enter TransactionsThis section describes entering transactions for specific Visits that cannot be Line Item posted.

FIGURE 16. Transaction Entry - E Action Code Screen (IBCE.S1

TABLE 15. Transaction Entry - Transaction Entry Screen Fields (IBCE.S1)

Field Description

ACTION FIELDS

Action Action Codes available in Transaction Entry

E - Enter Trans-actions

- Post non-Line Item transactions

A - Patient Actions



D - Delete Transactions


NOTE: Delete transactions that have not been billed rather than entering a credit or negative transaction.


E



L - Line Item Payment Posting

(LIPP)

- Post Line Item Payments and Rejections



TRANSACTION HEADER FIELDS

Patient Recommended lookup is the Visit Number.

Ex: 123456. This number is usually on the EOB.

MRN Organization MRN

Guar: Guarantor name

Rep The mnemonic of the Rep to whom the selected Visit is cur-rently assigned

Vis # Enter the Visit number unless entered in the Patient field.

ARFSC ARFSC number and description

Vis Bal Current balance on the Visit

Stmt Dt Date of last patient statement

Dunn Current Dunning level

Unbilled Amount unbilled

Plan List The mnemonics of the Plans on the Visit

Sequence Y defaults in. It indicates the payors on the Visit are billed sequentially.

ARCTR Enter the EOB reference number suffix or enter a ? to display the acceptable choices. Prepayments and payments at time of service should be posted to ARCTR 0 (zero).

Ex: The number after the dash in the EOB reference number: 123456-1. This number was in the Patient Control Number field on the UB92 forms. In this example, the ARCTR is 1.

Plan The Plan associated with the ARCTR

Balance ARCTR balance

Type Hospital will default

FSC FSC associated with the ARCTR’s Plan


Field Description


Action Code E - Enter Transactions

TRANSACTION FIELDS

Date Post Date. Refer to Policies and Procedures for appropriate date. If a date was entered in the Batch Duplication Transaction Date field, it will be defaulted here. It may be overridden. If the Batch Control field Ask Trans Date is answered N, the cursor will not stop in this field.

Code If the Transaction Code does not default in from the Batch Duplication field, enter a ? or F12 to view available transac-tions.

If Y was entered at the Ask Trans Comment and/or the Ask Pay-ment PPS fields on the Batch Definition screen, the cursor moves to one or both of these fields after <Enter> is pressed.

Amount Enter the transaction amount. Press <Enter>.

NOTE: If the payment leaves a zero balance for the ARFSC to which it is posted and there are other ARFSCs that have a bal-ance, the system automatically changes the ARFSC to the next one in priority sequence for the Visit. The system also displays the message, “ARFSC has changed to: ###” (the next ARFSC number).

The system may display a transfer/release Profile bottom form.

SA Special Actions.

• A - Patient Actions. The VM/HPA Function 1 screen displays

• C - Claim Reference number. A bottom screen (ICRN.A) displays for entry of the payor’s line item or claim reference number.

• D - Delete Transaction. To delete a line item transac-tion that has not been billed yet.

• J - Rejection Entry. To enter partial or full line item rejections. See “” on page 30.

• U - Enter UB92 data: Occurrence, value and condition codes

• V - Visit Notes. The Visit Notes B screen displays for data entry.


Field Description



Action Code F - FIFO Enter TransactionsThis section describes entering Account level payments and transactions.

FIGURE 17. Transaction Entry - Action F - FIFO (IFF0.S1.)

TABLE 16. Transaction Entry - FIFO Screen fields (IFF0.S1)

Field Description

Batch # Batch number to which transactions will be posted

Description Batch description

User Initials of the user who created the batch

Batch Type Payment/Adjustment is defaulted in by the system.

Date Date the batch was created

Action F defaults in. It is the code for FIFO payments

Account/Name Enter Account name. Use standard name entry formats.

MRN Organization MRN

Account Number Account number defaulted in by the system


Action Code F - FIFO Enter Transactions

Tel. Account telephone number

Address Line 1 Account Address Line 1

Address Line 2 Account Address Line 2

City,St Account City and State

Zip Account Zip Code

Date Post Date. Refer to Policies and Procedures for appropriate date. If a date was entered in the Batch Duplication Transac-tion Date field, it will be defaulted here. It may be overridden. If the Batch Control field Ask Trans Date is answered N, the cursor will not stop in this field.

Code Transaction Code. If a code was entered in the Batch Duplica-tion Transaction Code field, it will be defaulted here. It may be overridden.

If the Batch Control field Ask Trans Code is answered N, the cursor will not stop in this field.

Typ Transaction Type associated with the selected Code. The sys-tem defaults this field. It cannot be overridden.

Comment • If a comment was entered in the Batch Duplication Comment field, it will be defaulted in and may be overridden.

• If text was entered in the Batch Duplication Prefix field, it will be defaulted in. The user may add to it. Ex: if the prefix is CK#, the user can add the specific check number for the line item. Adding 1234 will give the value CK#1234.

• Enter a free text comment for the line item.• If the Batch Control field Ask Trans Comment is

answered N, the cursor will not stop in this field.Amount Enter the transaction amount.

Total ARCTRs

Balance Account Balance

TABLE 16. Transaction Entry - FIFO Screen fields (IFF0.S1) (cont.)

Field Description



Transaction Entry - Delete Transaction ScreensThis action is used to delete one or multiple transactions from the batch.

When a transaction is deleted, the system adds another transaction to delete the original transaction and then replaces the description of the original transaction with the description ** Delete *. The description of the new transaction will also display the description ** Deleted **, but the dollar amount will be preceded by the opposite ‘sign’ of the original transaction.

The new transaction will be given the next sequential transaction number. There-fore, it will appear at the bottom of the list, not necessarily next to the transaction that was deleted.

If the deletion of a transaction causes the system to change the ARFSC, the system displays a message with the new FSC.

FIGURE 18. Transaction Entry - Action D - Delete Transaction


Transaction Entry - Delete Transaction Screens

Transaction Entry - Action D - Delete Transaction fields

TABLE 17. Transaction Entry - Action D - Delete Transaction fields

Field Transaction

Seq Sequence number that represents the order in which the transac-tion was entered into the batch

Code Transaction Code

Date Transaction Date

Type Transaction Type

• BADJ - Billing Adjustment• CADJ - Credit Adjustment• PAYM - Payment• TADJ - Transfer Adjustment

Description Transaction Description. If the transaction was deleted or moved, the text ** Deleted ** displays

Patient Patient name

Billing # The format is: Visit# - ARCTR- Line # H (if posted with LIPP)

Amount The dollar amount of the transaction. If the transaction was deleted or moved, the figure in this column may be preceded by a minus sign, depending on the ‘normal sign’ of the transactions. Payments may also be preceded by a minus sign for the same rea-son.



Transaction Entry - Action D - Delete Transaction Action Codes

TABLE 18.


A - Select All To select all transactions in the batch at one time. A diamond displays to the left of all the transactions

To unselect specific transactions, using the up and down arrow keys, highlight the transactions to unselect and press Enter on each transaction. The diamond will disappear on the transactions.

D - Delete Transaction To delete the selected transactions

1. Using the up and down arrow keys, high-light a transaction to be deleted and press the Enter key. A diamond will appear.

2. Repeat step 1 until all transactions to be deleted have been selected.

3. Type D to delete the selected transactions.4. Reply appropriately to the question

“Delete all selected transactions? NO=?” • Enter or N will not delete the selected

transactions.•Enter Y to delete all the selected transac-

tionsF - First Transaction To move the highlight bar to the first transaction on

the first page of the transactions for the batch.

I - Inquiry To inquire about specific transactions.

Highlight the transaction to see. See “Transaction Entry I - Inquiry Screens” on page 43.

L - Last Transaction To move the highlight bar to the first transaction on the last page of the transactions for the batch.

T - Delete All Transactions

U - Unselect All To unselect all the selected transactions. The action removes the diamonds from the left of all the trans-actions.


Transaction Entry I - Inquiry Screens


FIGURE 19. Transaction Entry - I Action code

From the Inquiry screen, the user can also delete entries by selecting one or more visits using the <Enter> key or in combination with the A and U Action Codes. After selecting the transaction(s), press Action Code D to delete. Below is a display from the Inquiry Action Code above

FIGURE 20. Transaction Entry - I Action Code - I Action Code



The Transaction Inquiry screen below show the line items posted. The R in the Ind column indicates that there a rejection on the line item.

FIGURE 21. Trans Entry - I-Inquiry with LIPP and Rej

Action Code I - Inquiry. Screen 1 shows the ARCTR data.

FIGURE 22. Trans Entry I-Inquiry - LIPP and Rej detail screen 1 (IBTL.S1)



Inquiry screen 2 Screen 2 shows the payment data.


Inquiry screen 3 shows the rejection data.




Moving Payments and Transaction ConceptsIf payments or other transactions are posted to the wrong visit or the wrong patient, they can be moved to the correct visit or patient.

Selection of transactions to be moved may be by ARCTR, transaction date, posting date or transaction code.

Transactions can be moved between two visits for the same or different patients.

Moving Transactions WorkflowScenario 3 is an example of moving transactions from one patient to another.

1. Select/Create a Batch2. Select patient and visit to move FROM3. Select transactions to be moved4. Review screen for accuracy5. Select patient and visit to move TO6. Move the transactions

TABLE 19. Moving Transaction Concepts

Transactions can be moved between visits of

• Any Visit Type• Any Visit StatusDebits and Credits can be moved.All detail associated with the transaction movesTransaction amounts cannot be changed in the moveDeleted transactions cannot be movedWhen the transaction is moved, a transaction reversal is created on the FROM Visit. If the original transaction is a debit, the reversal will be a credit on the FROM Visit. An exact duplicate of the original debit is cre-ated on the TO Visit.Two users cannot access the same batch at the same time


Moving Payments and Transaction Concepts

Access - Moving TransactionsTransactions can be moved from one visit to another for the same or different patients in one of two ways. This is the corrective action when a payment or trans-action has been posted incorrectly.

NOTE: When transactions that are associated with line items are moved, the line item information will be removed regardless if the transaction that the user is mov-ing to has line items or not. When the user moves a transaction that has line items, the system will display a warning message that notifies the user that moving the transaction will remove line item information.

1. Move Transactions Activity (shown below and used in Scenario 3 in this lesson)•VM/HPA•Function 4, HPA Activities•Activity 11, Move Transactions

2. Transaction Transfer Action Code•VM/HPA•Function 2, Patient Rep System•Activity 1,•MT Action Code



Move Transaction Screens

Access1. VM/HPA2. Function 4, HPA Activities3. Activity 11, Move Transactions4. Select the FROM patient and Visit.

FIGURE 25. Move Transaction - Select FROM Visit (ITM1.S1)

5. Select N for New Patient (the TO patient). Then select the TO Visit.

FIGURE 26. Move Transaction - Select TO Visit (ITRM.S1)

4

54



6. Select the transaction(s) to move and then Action Code M to move transactions.

FIGURE 27. Move Transaction - Moving Completed message (ITRM.S1)

7. The batch will always be in balance because the system creates a debit and a credit for each Move Transaction. It does not permit user entry of the controls.

FIGURE 28. Move Transaction - Batch Balancing Screen



Scenario 1You have been given an EOB from Beacon Health Plan which indicates payments for one Visit for patient Clark Kent.

The EOB and Batch Controls are shown below. Check #12345 was for $

Your task is to enter the transactions.

SolutionUse the Transaction Entry, Action L for Line Item Payment Posting (LIPP) to enter transactions. Check your data entry from the Patient Billing Screen (PB Action Code) using the Transaction Inquiry functionality (TI Action Code).

Access1. VM/HPA2. Function 4, HPA Activities3. Activity 2, Transaction Entry

TABLE 20. Transaction Entry - Scenario 1 EOB

Procedure Charge Paid OtherDenied Reason Code and $

93005 272.00 58.70 213.30 Non-covered

Q0081 199.00 0.00 Reference: RJ345562 96 $199.00

250 82.00 42.00 Reference: RJ5554433

(Per new fee schedule)

42 $ 40.00

92083 193.00 193.00

92286 385.00 385.00

92499 177.00 177.00

86580 20.00 0.00 Reference: RJ9874433 42 $ 20.00

90782 50.00 0.00 Reference: RJ5521430 42 $ 20.00

10.00 Payment Code 55510

Contract Adjustment Credit on the claim



FIGURE 29. Transaction Entry (IBTS.S1)

1. A “G” was entered at the Batch # field to create a batch and generate the batch number.

2. Type in the description of the batch according to policy and procedure instruc-tions.

3. F10. and enter data in the Batch Control Screen.

FIGURE 30. Transaction Entry - Batch Control Screen (IBTC.S1)

4. F10 5. Action Code L



FIGURE 31. Transaction Entry (ITBE.S1)

6. Immediately the Line Item Payment Posting screen displays. If the visit number and ARCTR were not entered at the Patient prompt, the options display.

FIGURE 32. LIPP Visit Selection Screen (ITR2.A)

7. Select the Visit and enter the ARCTR8. F10



FIGURE 33. lLIPP - Line Item Selection Screen (ITRL.A)

9. Arrow down to select the first line item on the EOB (Procedure 93005). This charge was paid according to the fee schedule.

10. Action Code P

FIGURE 34. LIPP - Posting Screen w/ Transfer Release Bottom Form (ITR4.A)

11. Fill in the data from the EOB12. F10 twice to return to the LIPP Selection Screen.13. Select the next item on the EOB (Procedure Q0081). This entire charge was

denied.



14. Action Code P15. Enter the correct Payment Code and complete the data entry.

FIGURE 35. LIPP - Rejection Entry (ITR3.A)

16. F10 twice.17. Select the next item on the EOB (Procedure 250).18. Action Code P.19. Enter the correct data.



FIGURE 36. LIPP - Partial Payment (ITR4.A)

20. Enter J in the SA field21. Enter the denial information.

FIGURE 37. LIPP - Partial Payment with Rejection data (ITR4.A)

22. F10 twice.23. Select the next item on the EOB (Procedure 24. Enter the next 5 items on the EOB (all but the last one).



25. Select the last item on the EOB. It is not for any specific charge on the claim, but it does pertain to the claim. Do not select Action Code P.

26.

27. Action Code R.

FIGURE 38. LIPP - Action Code R - Post to ARCTR (ITR4.A)

28. When complete, F10 back to the Function menu29. Function 130. R to recall the patient



31. Action Code PB - Patient Billing32. Select the Visit

FIGURE 39. Transaction Entry - PB after Posting Transactions (I6RU.A)

33. Action Code TI - Transaction Inquiry

FIGURE 40. Transaction Entry - PB - TI (I6VC.A)



34. Action Code D - Display/Hide Line Items

FIGURE 41. Transaction Entry - PB - TI - D Line Item Detail (I6VC.A)

35. Action R - Rejection Only Toggle to see only Rejections

FIGURE 42. Transaction Entry - PB - TI - R Rejections (I6VC.A)

36. F10 to return to the Function Menu. You have posted all the transactions.


Scenario 2

Scenario 2You just realized that the last transaction you posted in Scenario 1 was posted in error.

Solution

Delete the transaction.

Access1. VM/HPA2. Function 4, HPA Activities3. Activity 2, Transaction Entry4. Re-enter the batch and change the Batch Controls.

F10 to get to the Transaction Entry Screen

FIGURE 43. Transaction Action Entry Screen (IBTC.S1)

5. Action D - Delete Transactions



Transaction Entry - Delete Transaction Code Screen 1

6. Select the transaction to delete.7. Action Code D

FIGURE 44. Transaction Entry - Delete Screen with message

8. Answer Y to question if all the transactions with diamonds next to them should be deleted.

9. F10


Scenario 2

10. A message displays that all the transactions selected have been deleted.11. The Delete Transaction Screen redisplays.

Transaction Entry - Delete Screen with deleted transaction

12. Note the deleted transaction.

You have successfully deleted the transaction.



Scenario 3You have been given a small batch of payments to enter into the IDX VM/HPA sys-tem. One check is for a visit for Lois Lane from a commercial insurer with whom the University of Miami does not have a contract. The other check is for a visit for Clark Kent from an HMO with whom the University of Miami does have a con-tract. Neither payor has identified Line Items on the EOB.

Your task is to enter the transactions and balance the batch.

The Batch Controls are shown in the table below.:

The date of all the transactions in the batch is 5/14/03. The two encounters in the batch are for Janus Jupiter and Solar Saturn.

SolutionUse the Transaction Entry, Action E to enter transactions and balance the batch.

Access 1. VM/HPA2. Function 4, HPA Activities3. Activity 2, Transaction Entry

TABLE 21. Transaction Entry - Scenario 1 Batch Header Slip

Control Data Entry

Total Payments 300.00

Total Adjustments 74.00

Total Transactions 20.00

TABLE 22. Transaction Entry - Scenario data input.

Patient Lois Lane Clark Kent

Visit # 369390 369388

Payment Code and $ 30510 $300.00 90510 $20.00

Adjustment Code & $ 30210 $74.00


Scenario 3

FIGURE 45. Transaction Entry - Batch Selection Screen (IBTS.S1)

1. A “G” was entered at the Batch # field to create a batch and generate the batch number.

2. Type in the description of the batch according to policy and procedure instruc-tions.

3. F10. Enter the Batch Balancing Fields from the Batch Header Slip. Remember to use the correct signs. Enter the Duplication fields defaults. F10 to continue.

FIGURE 46. Transaction Entry - Scenario 3 Batch Def. Screen (IBTC.S1)

Do you see anything that was entered incorrectly above?



FIGURE 47. Transaction Entry - Scenario 1-Action Code E screen (IBTE.S1)

4. Notice that the Visit has been billed and there is a balance. 5. Enter E at the Action prompt to enter transactions.6. Enter H369390 at the Patient prompt.7. Enter 30510 at the Code prompt and 300.00 at the Amount field. Press <Enter>

and the cursor returns to the Code field.8. Enter 30210 at the Code prompt and 74.00 at the Amount field. Since the com-

mercial payor is not a contracted payor, the IDX system is not set up to prorate the charges to automatically create and post the contractual adjustment. It has to be entered manually.

9. Notice that the ARCTR is 1. Since only the primary payor has been billed, there are no other ARCTRs on the Visit, so the system defaults in ARCTR 1. If there were more than one ARCTR, the correct ARCTR would have to be entered. It should be on all claim forms. If there is more than one ARCTR on the Visit, the user can enter a ? at the ARCTR prompt to view all the ARCTRs and select one for posting the transaction.

45


Scenario 3

FIGURE 48. Transaction Entry - Scenario 1-E Action Code (IBTE.S1)

The next screen displays what the Batch Definition screen would look like after the above postings. You can exit the batch to view the batch screen or Press <Enter> to return to the Patient prompt to enter to return to the patient prompt to enter Clark Kent’s payment transaction.

The signs on the amount fields in the Batch Definition screen have been corrected to reflect the proper controls. Payment and credit (including contractual adjust-ments) have minus signs in the controls but are entered as positive dollars in Trans-action Entry.

FIGURE 49. Transaction Entry - Batch Definition Screen after 1st posting



10. Now enter Clark Kent’s transaction. Notice that Clark Kent’s visit has not been billed yet.

11. The system defaults ARCTR 0 if there is no other ARCTR on the Visit. Patient Time of Service payments are posted to ARCTR 0.

12. Enter 90510 for the Code and $20.00 for the Amount. A message will display that there is a credit balance on the Visit. The message is just to alert users to the fact that there’s a credit balance on the visit. Usually it is because there are no charges on the visit yet.

FIGURE 50. Transaction Entry - Scenario 1-E Action code (IBTE.S1)

13. Press <Enter> until the cursor is at the patient prompt. Enter X in the Action field or press F10 to file the batch. If there is a message that the batch is not in balance, return to the Batch Definition screen and follow the Manual Payment Posting flow for correction instructions.

The batch can be printed by answering Y to the Print Batch Proof prompt or the batch can be put on hold. There is no need to put a batch on hold if it is out of balance because the system will not process an out of balance batch. Usually there is no reason to put a batch on hold if it is in balance.

If the batch was out of balance, a batch proof could be printed to match the entries on the posting document (and EOB or transaction data entry sheet) to see where the discrepancy is. When found, if data needed to be corrected in the system (transactions added or deleted), use the Return to Transaction Entry field to fix the data. Refer to the table above for functionality at the Action prompt on the E-Enter Transactions Action Code in Transaction Entry.

1112


Scenario 3

FIGURE 51. Transaction Entry - Batch Definition Screen

You have completed payment and transaction posting for Scenario 3.



Scenario 4

You are posting patient payments and have to post a check for $100 on Artemis Jupiter’s account. There is no notation which visit(s) the money should be applied.

Your task is to post the money to the correct visit(s).

SolutionUse the F-FIFO Action Code in Transaction Entry. FIFO stands for First-In, First-Out. It means that the money to be posted will be posted to the visit with the oldest patient responsibility balance and then automatically post the remainder of the pay-ment to the next oldest visit with a self pay balance.

Access 1. VM/HPA2. Function 4, HPA Activities3. Activity 2, Transaction Entry4. Access the same batch if it is open. If not, open a new one or use another open

batch. The posting would normally occur in a patient payment batch.5. At the Transaction Action prompt, enter an F to post a FIFO transaction.6. The Enter Patient screen displays with a choice of visits. Select the oldest for

FSC 1, self pay. That is #6 below.

FIGURE 52. Transaction Entry - F Action Code - Patient Lookup screen


Scenario 4

7. Enter the payment as it would be in regular Transaction posting. Notice that the number of ARCTRs are listed below the transaction line.

8. F10 when entry is correct.

FIGURE 53. Transaction Posting - Scenario 2 - FIFO Posting (IFFO.S1)



9. A message displays at the bottom of the screen showing the visits that have had money posted to them and the dollars that have been posted to each.

FIGURE 54. Transaction - Posting - Scenario 2 - FIFO posted (IFFO.S1)

10. The a pop-up box will display the message

FIGURE 55. Transaction Posting - FIFO - Transaction Filed Message

The total amount of the payment is filed in the comment field in all the visits that had money posted to them. Shown below is the inquiry screen for both Visits


Scenario 4

Transaction Inquiry after the FIFO posting for Visit 369394 shows the amount of the check applied to the Visit (-$56.00) and the entire amount of the check in the Comment field and the way the transaction was made (FIFO)

FIGURE 56. Transaction Posting - FIFO - TI Action Code Visit 1(IBTD.S1)

11. You have completed posting a FIFO payment.



Scenario 5After the batch was posted by Night Jobs, it was noticed that a payment to Sally Saturn visit should have been posted to Sunny Saturn’s visit.

Your task is to correct your error. Inquire on the actions to make sure the move was successful.

Solution

Use the Move Transaction functionality to move the transaction from Sally visit to Sunny’s visit.

Access 1. VM/HPA2. Function 4, HPA Activities3. Activity 11, Move Transactions4. Open an existing Transaction batch or create a new one5. At the patient prompt, enter the patient that the charges are to be moved FROM.6. Select the Visit. The transactions will be displayed.

FIGURE 57. Move Transactions Screen (ITM1.S1)

6


Scenario 5

7. F10.8. Select the To Patient and Visit.9. Select the Transaction(s) to be moved.

FIGURE 58. Move Transactions Selector Screen (ITRM.S1

TABLE 23. Move Transactions Selector Screen Action Codes

Action Code Definition

Individual Transac-tion Selection

Use the standard IDX Selector functionality

A-Select All Selects all displayed transactions

B-Batch Inquiry Shows the detail of the current batch

G-Legend Displays a legend for the Ind column

I-Transaction Inquiry

Provides a detailed look at the selected transaction

J-Jump to Group Jump from one group of transactions to another. The jump works off the current sort.

M-Move Transac-tions

Use this code after entering the patient visit through N-New Patient receiving the transactions. This action files the screen and moves the selected transaction(s) from one patient’s visit to the visit selected through N-New Patient. An M indicator displays next to the moved transaction on the new visit.

N-New Patient Allows selection of the patient/visit to which the transactions are to be moved.

68

9



10. Action Code M. After the move a confirmation message displays for a brief moment at the bottom of the screen.

FIGURE 59. Move Transaction - Confirmation message. (ITRM.S1)

11. The transaction has been moved.12. There are no controls to input because the total of the transactions is zero. A

credit transaction is created on the FROM Visit and a debit transaction is created on the TO Visit. The batch screen is displayed below.

S-Sort Display Sorts the list of transactions by ARCTR, Transaction Code, Dollar Order, Entry Date, Plan code or Transaction Date.

U-Unselect All Unselects all of the items currently selected.

TABLE 23. Move Transactions Selector Screen Action Codes

Action Code Definition


Scenario 5

FIGURE 60. Move Transactions Batch Screen (IBMT.S1)

13. There are no controls to enter in this screen. The screen does give the user the options for printing a batch or putting a batch on Hold if the user does not want it to be posted by Night Jobs. It would be unusual for the batch to be put on Hold.

14. You have completed the moving transactions exercise. Now inquire on the move to see how it displays in summary and in detail.



Transaction Move Inquiry

The Batch Inquiry for transaction shows the two transactions that the move created.

Access1. VM/HPA2. Function 1, Patient Actions3. Access patient visit4. PB Action Code, Patient Billing5. TI Action Code, Transaction Inquiry6. M Action Code - Moved Transactions

FIGURE 61. Move Transaction Inquiry - Action Code PB, TI, M

1. The original transaction deleted on Sally’s visit. The M in the Ind column indi-cates the transaction was moved.

2. The reversal transaction, created by the Move Transaction, deleted on Sunny’s visit. The M in the Ind column indicates the transaction was created by a Move Transaction.

21


Scenario 5

Batch Inquiry showing a Move Transaction Inquiry1. VM/HPA2. Function 4, Batch 3. Activity 4, Transaction Batch Inquiry4. Access the batch of the Move Transaction

FIGURE 62. Move Transaction - Batch Inquiry

1. The transaction after it was moved to Sunny’s Visit. It has a minus sign because the original transaction was a payment with a minus sign.

2. The transaction created by the Move Transaction to reverse the original pay-ment transaction on Sally’s Visit. Both it and the original transaction were deleted by the Move Transaction as shown in the previous screen.

12



Exercises:1. What types of transactions can be posted in HPA Function 4?2. What is the benefit of Line Item Payment Posting (LIPP)?3. What are the two types of rejections?1. Why is deleting the preferred way to correct an incorrect transaction entry?2. If you are part way through entering a batch that is grouped by date and the date

changes, how do you change the default date?3. What is the purpose of the batch controls?4. Why is it important to balance the batch?5. Why must all batches be balanced by the end of the month?6. What is the functionality of Transfer/Release Profiles?7. How to they work in relationship with Proration?8. Can a transaction be moved from one patient’s visits to another visit of the same

patient?9. Are Line Item transactions maintained in a move?10. What is the benefit of using the FIFO method of payment posting? What does it

do?11. Why is it valuable to track rejections?

HPA - Hospital Patient Accounting 1

CHAPTER 1 Transaction Batch Inquiry Training

Transaction Batch Inquiry Training

2 Visit Management

Objectives

After completing this lesson, you will

• What appears on the Transaction Batch Inquiry screens

• How to access and when to use the Transaction Batch Inquiry functionality.

• How to use the Transaction Batch Print functionality

Introduction

The purpose of the Transaction Batch Inquiry functionality is to view and print the transactions on the Visit but not modify them.

Prerequisites

Introduction to VM/HPA

Access

Access to Charge Inquiry

1. VM/HPA

2. Function 4, HPA Activities

3. Activity 4, Transaction Batch Inquiry

4. ? at the Batch prompt. If the batch number is known, it can be entered

University of Miami: Business Information Management Systems 3

Introduction

Transaction Batch Inquiry Screens

The first screen of the Charge Inquiry is a selector for the user to select the charge on which to inquire.

FIGURE 1. Transaction Batch Inquiry - Batch Selection Screen

TABLE 1. Transaction Batch selection column descriptions

Field Description

Batch # The number of the batch. Newest batch is listed first.

Desc Description of the batch as entered by the user or put by the system

User The user who created the batch. SYS$$ indicates the system created the batch.

Created Date when the batch was created by the User.

Post Date Date when the batch was posted to the system by Night Jobs.

Total $$$ Total of the dollars in the batch

Stat The status of the batch. See table below for descriptions of the codes

1

1 - Transaction Batch selection section (see table below)2 - Action Codes (see table on next page)

2


4 Visit Management

TABLE 2. Transaction Batch Inquiry Status Codes

Code Description

CL Closed

CP Closed, Batch Proof printed

CR Crashed

HL On Hold

OB Out of Balance

OP Open

OU Open and in Use

TABLE 3. Transaction Batch Inquiry Action Codes

Code Description

F - First Batch Moves the cursor to the first bath in the selector screen.

I - Inquiry Displays detailed information for the selected batch. Example on next page.

L - Last Batch Moves the cursor to the last batch in the selector screen,

P - Print Batch Proof

Print a Batch Proof for the selected batch. The Batch Proof lists all the transactions in the batch.

T - Transactions Displays a list of all the A/R transactions for the selected batch. Example on next page


Transaction Batch Inquiry - Action Code I screen


FIGURE 2. Transaction Batch Inquiry - Action code I (IBTH.S1

1. This screen displays basic transaction batch information and the batch balancing fields.

2. F10 to return to the main Transaction Batch Inquiry screen.


6 Visit Management

Transaction Batch Inquiry - Action Code T screens

The first screen of the T Action Code is a batch selector screen.

FIGURE 3. Transaction Batch Inquiry - Action Code T Screen

TABLE 4. Transaction Batch Inquiry - Action Code T Column Descriptions

Column Description

Seq The sequence of the transaction in the batch

Code Transaction Code of the transaction

Date Date of the transaction

Type Transaction type

Description First 11 characters of the description of the transaction

Patient Patient name

Billing # Visit number followed by a dash and then the ARCTR. The H will always follow the ARCTR.

Amount The amount of the transaction. The sign indicates how the transaction will affect the A/R



3. Action Code I from above screen on Visit 361079 ARCTR 1 displays the details of the transaction.

FIGURE 4. Transaction Code Batch-Action Code T then I Scrn 1 (IBTD.S1)

FIGURE 5. Transaction Code Batch-Action Code T then I Scrn 2 (IBTD.S2)


8 Visit Management

Transaction Batch Inquiry - Action Code P screens

The first screen of the Transaction Batch Print action code is where the user tells the system where to print the batch proof.

FIGURE 6. Transaction Batch Inquiry - Action Code P to Print a Batch

4. Enter Y132 to print to the screen or enter the NO and then specify a printer

There may be many pages in the batch proof. The first page will always contain batch summary data. The last page will contain the batch totals. The intervening pages contain the details of each transaction in the batch.



FIGURE 7. Transaction Batch Inquiry - Action Code P - First Screen

FIGURE 8. Transaction Batch Inquiry - Action Code P - Detail Screen


10 Visit Management

FIGURE 9. Transaction Batch Inquiry - Action Code P - Last Screen



Exercises:

1. What are the purposes of the three types of screens in a batch proof?

2. What are the two types of users that create transaction batches?

3. Your instructor will give you two transactions on which to inquire. Fill in the blanks for the information from each of the transactions.

TABLE 5. Transaction Batch Inquiry - Exercise Table

Question Payment Transaction Adjustment Transaction

Batch Number

Visit Number

Transaction Number

Transaction Type

Transaction Code

Transaction Amount

Affect transaction will have on A/R

Total batch payments

Total batch adjustments

Total batch transactions

Sequence number of the transaction in the batch


12 Visit Management

HPA Transaction Entry Training - University of Miamicet.med.miami.edu/documents/HPA Transaction...

Documents

Transcript of HPA Transaction Entry Training - University of Miamicet.med.miami.edu/documents/HPA Transaction...