Balance Forward Conversion Manual

Client/Server B/AR Module

MEDITECH Circle, Westwood, MA 02090

(781) 821-3000

This information is proprietary and should be treated accordingly.

Organization of Manual

This manual has been designed to assist the hospital through the entire conversion process. It is broken down into three sections: INTRODUCTION, TESTING, and LIVE CONVERSION. The conversion process is lengthy and covers the entire 6 - 7 month implementation phase. The entire manual should be reviewed during the conversion evaluation phase, prior to the B/AR Assessment Visit (Hospital Reviews Conversion on the PTS schedule). Any

questions the hospital has regarding the contents of this manual can then be discussed during the Assessment Visit.

A half-day has been devoted to conversion testing at the first B/AR Applications visit. At this visit, all routines will be explained, rejection reasons discussed, and this manual will be referenced.

The section entitled INTRODUCTION will be used by the hospital for background on the conversion process. Information is also included regarding what data will be converted and how. The introduction will also highlight considerations in the conversion process that will need to be discussed with other departments regarding the Live conversion process.

The section entitled TESTING will assist the hospital in beginning the Mini conversion test. This section explains the routines to be run, the process for addressing rejections, the validation of conversion data, and the balancing process. Once the mini conversion has been completed (as indicated on the PTS schedule), full conversion testing will be addressed. The full conversion tests will be used by the hospital to simulate the Live conversion process in addressing rejections, balancing, and taking timing estimates.

The section entitled LIVE CONVERSION will detail all tasks relating to the LIVE conversion. It will be used by the hospital to develop a LIVE conversion schedule which will outline all activities that will take place, who will be

responsible for the activities, and approximately when the various activities will be occurring.

Chapter 1: Introduction 5

Background on Conversion 5

Format: Other Vendor vs. MEDITECH 6

Mapping: Auto Creation Menu & Conversion Tools 8

Routines To Auto-Create Conversion Maps 9

Copy Maps To Conversion Database 9

Conversion Testing: Mini vs. Full 10

Mini Database Conversion Testing 10

Full Database Conversion Testing 10

Databases: TEST vs. LIVE vs. CONV 11

Set Up Of Conversion Database: 11

Set Up Of Live Ring: 11

Deletion Of Conversion Database: 11

Tracking Critical Conversion Dates 12

Conversion Considerations: Introduction 14

Parameters Affecting Conversion 14

Creating Conversion Files 14

Conversion Considerations: Pre Live Preparations 15

How To Convert UB Accounts 15

Final Billing Accounts Off Current System 16

Ensuring All Charges Are Entered Into The Current System 17

Contract Accounts 17

Client Accounts 17

Chapter 2: Getting Started with Conversion Testing 19

Hospital Checklist 20

Setting up the Conversion Database 21

Hospital Conversion Testing Schedule 22

Conversion Main Menu 24

Loading Conversion Files 25

Check and File Routine 26

Status Summary 27

Timing Report 27

Various Rejection Lists 28

Summary of Account Rejections 28

Detail of Account Rejections 28

Invalid Dictionary Entry List 29

Invalid Query Mnemonics List 30

Additional Rejection List 30

Demographic Rejection Reasons 31

Fixing Demographic Rejected Record 35

Loop and Edit 35

Edit One File 35

Purge Routines 35

Purge Temporary File 35

Purge Filed Data 36

Verifying Account Information 37

Balancing the Conversion 40

Additional Testing Requirements 41

Testing Statements in the Conversion Database 41

Re-Evaluate Next Statement Date 42

Closing the Month in the Conversion Database 43

Conversion Sign-Off 43

Training In The Conversion Database 44

Chapter 3: Live Conversion 47

LIVE Checklist for a Balance Forward Conversion 47

Moving Custom Menus and Reports from Test to Live 49

Conversion in Progress Flag 50

Converting UB Accounts 51

Reserve Account Numbers and List Compare Conflicts 52

Compare/Reserve Accounts in ADM 52

List Compare Conflicts 52

Conversion Month End 52

Backups 53

Chapter 1: Introduction

Background on Conversion

This section explains what will be converted in a BALANCE FORWARD CONVERSION. For a detailed listing of individual fields that will be converted in the Balance Forward conversion, please refer to your conversion specifications.

The Balance Forward Conversion involves converting "FB" and "BD" accounts with demographic information and only one transaction for the amount of the account balance at the time of the conversion.

Since these accounts were not billed in the MEDITECH system, it is impossible to unbill and rebill these patients. This also makes it impossible to print claims and bills for any charges posted to these accounts prior to conversion. Late bills and claims can be generated for charges posted to these accounts after conversion, but the hospital should be aware that only limited demographic information is converted on the file. If late charges were to be billed via claim forms (UB92, 1500, WCB) additional demographic information may need to be added prior to generating the claim (ex. Diagnosis, Condition Codes, Occurrence Codes, Employment information, etc.).

Accounts converted as Unbilled (UB) will need to be entered manually. The people who are in-house at the time of conversion will be entered through the Admissions module. The UB accounts from the old system that are discharged but not final billed, will have to be keyed directly into B/AR. After the FB and BD accounts have been converted, the interface between ADM and B/AR will be turned on and those accounts will flow over to B/AR. The hospital can then convert the balances onto these accounts using one of the following three methods:

1. Interim bill the accounts off the current system and enter a Balance Forward amount onto all UR accounts, using a Charge Procedure Code that will only be used for the conversion.

2. Enter the charges summarized by REVENUE CODES or by CHARGE CATEGORY. This summary can be obtained via a UB92 or Patient Bill. Procedure codes will have to be added to the dictionary to accommodate this.

Note: Separate Room and board Charges will have to be entered for each service date to print the correct rate on the UB92 Claim form. Separate charges will also have to be entered for charges with CPT-4/HCPCS Codes to print on the UB92.

3. Enter all the detail on all the UR accounts.

Please refer to section Conversion Considerations: Pre Live Preparations for more specific information regarding these three methods of converting UB accounts.

It is not possible to convert accounts to the MEDITECH system with a status of IB. The account must either be final billed off of the current system and converted as an FB account or, converted as a UB account using one of the above

three methods. If any interim billed accounts are converted as UB, they should be interim billed one last time off the old system at the conversion month end. Once the conversion has been completed, they can then be interim billed off the MEDITECH system. This will bring them to the same status on the MEDITECH system as they were prior to conversion on the current system.

As a result of a Balance Forward conversion, the hospital will have the following information on the MEDITECH system:

· FB and BD accounts - Balance as of time conversion files are created. No detailed charges, receipts, adjustments, or refunds. The hospital has the ability to generate statements, late bills, and late claims for FB accounts.

· UB accounts - Depending on method hospital chooses to convert charges, the hospital may have ability to generate any type of bills and claims for these accounts as well as statements. However, the only accounts that will interface with the ABS module are in-house census accounts that are entered in ADM. Accounts that were discharged prior to conversion and manually converted in B/AR as UB will not interface to ABS and will have to be coded, for claims purposes, directly in B/AR.

With a Balance Forward conversion, significant testing is required. Details regarding the testing process for Balance Forward conversions can be found in Section: Getting Started With Conversion TESTING of this manual.

The hospital will need to formulate a Live schedule that will outline when various activities will take place and their duration. The hospital can refer to Section: LIVE Conversions of this manual for details.

Format: Other Vendor vs. MEDITECH

When the hospital contracts for an automated balance forward conversion they have two choices regarding the conversion format:

MEDITECH Format means the hospital is responsible for programming the conversion to MEDITECH specifications.

Other Vendor Format means that MEDITECH is responsible for programming the conversion to MEDITECH specifications.

This section will further discuss the responsibilities of both the hospital and MEDITECH for each of these formats.

Regardless of whether the hospital does a MEDITECH or Other Vendor format conversion, the conversion specifications must be reviewed. MEDITECH will only convert the data identified in these standard MEDITECH conversion specifications.

The hospital will also want to consider the options available for mapping information stored on the current system (Insurances, Providers, etc.....). These values will have to mapped to new values on the MEDITECH system, and the

hospital will have different options based on the conversion format.

MEDITECH FORMAT:

If the hospital is doing a MEDITECH format conversion, they are responsible for supplying conversion files that comply exactly to the MEDITECH specifications the week the hospital attends dictionary training at MEDITECH. This date is specified in the hospital's PTS. MEDITECH will review these files for formatting. At this point only the formatting is being checked, the data is not being validated.

The hospital will have two choices available for mapping current information stored on the old system to the new values on MEDITECH (Insurances, Providers, Service, Location, etc.....). The two choices are to store the maps within MEDITECH, or have the conversion programs map the information during the file creation process. The pros and cons for each are listed below:

1. Maps stored in conversion programs:

By electing to store the conversion maps within the conversion programs, the hospital is going to be mapping data from the current system into specified records on the conversion files in a format that MEDITECH understands, (i.e. insurance 011 is now mnemonic MCR). Also, these values are in a sense 'hard-coded' onto the file. This will mean that any rejection, which resulted from a mapping error, will require files to be recreated. This can lead to delays in conversion testing. Depending upon the number of accounts being converted, recreating files could cost the hospital a few days of testing for each mapping error.

Another consideration is that the hospital will have to build all the maps within the conversion programs that the programmer provides. This can also take up a lot of time and resources, as someone will have to be dedicated to entering and updating the maps as required. As you will read in the next section, if the hospital elects to store the maps within MEDITECH, there are routines available which will create three of the larger maps, i.e. Provider and Insurance.

2. Maps stored within MEDITECH:

By electing to store the conversion maps within MEDITECH, the hospital will benefit greatly if there should be a lot of rejections resulting from mapping errors. The reason for this is that the hospital will not have to worry what information is being mapped onto the files during the file creation process. This would mean that it is feasible to cut one set of files off of the current system, and simply re-read into MEDITECH after changes/edits are made to the maps.

The second benefit, as mentioned above, is that there are routines available within MEDITECH to automatically create three of the required maps based on entries stored within the dictionaries. This process is outlined in detail at the end of this section.

The hospital will need to manually build the conversion maps in the MEDITECH system through the B/AR Claim Maps Dictionary (other than the maps that can be auto-created). These maps will be used in the conversion programs to map the current files to the MEDITECH dictionaries (ex. Patient Status, Service, Location, BD Agency, etc.).

OTHER VENDOR FORMAT:

If the hospital is doing an Other Vendor format conversion, they need to supply MEDITECH with the conversion files, specifications of those files, and a printout of the file dump on or before the B/AR Assessment Visit as specified in the hospital's PTS. It is MEDITECH's responsibility to then program custom routines to read and convert the information on the files. When creating test files, the hospital should have one file created for each B/AR status (FB and BD).

The hospital will need to build the conversion maps in the MEDITECH system through the CLAIM MAP Dictionary. These maps will be used in the conversion programs to map the current files to the MEDITECH dictionaries (ex. Provider, Insurance, Service, Location, etc.).

Mapping

These maps must be set up with the following mnemonics in the B/AR Claim Map dictionary (they are provided with the standard dictionaries) whether you are doing a MEDITECH or Other Vendor Format conversion:

CONV DR = Map doctors to the appropriate Provider Dictionary mnemonic (can be auto created).

CONV STAT = Map patient status MEDITECH status's are predefined as:

ER = Emergency Room

IN-OTHER = Other Inpatient

INP = Inpatient

NPA = Non Patient Account

OBSERV = Observation

OUT = Outpatient

OUT-OTHER = Other Outpatient

PRE = Pre Admit

REC = Recurring Outpatient

SDC = Surgical Day Care

POV = Physician Office Visit

CONV INS = Map insurance plans to the appropriate Insurance dictionary mnemonic (can be auto created).

CONV BD = Map Bad Debt Agencies to the appropriate Collection Agency dictionary mnemonics.

CONV SER = Map Inpatient services to the appropriate MIS Service dictionary mnemonic.

CONV LCN = Map Outpatient locations to the appropriate MIS Location dictionary mnemonic.

CONV MS = Map marital status to the appropriate MIS Marital Status dictionary mnemonic.