Client/Server B/AR Module
Detail Conversion Manual
Copyright by MEDICAL INFORMATION TECHNOLOGY, INC.
MEDITECH Circle, Westwood, MA02090
(781) 821-3000
This information is proprietary and should be treated accordingly.
Organization of Notebook......
Chapter 1: Introduction......
Background on Conversion......
Format: Other Vendor vs. MEDITECH......
Mapping......
Routines to Auto-Create Conversion Maps......
Copy Maps to Conversion Database......
Zero Dollar Detail Conversions......
Differences Between Detail and $0.00 Detail Conversions......
Conversion Testing: Mini vs. Full......
MINI DATABASE CONVERSION TESTING......
FULL DATABASE CONVERSION TESTING......
Databases: TEST vs. LIVE vs. CONV......
SET UP OF CONVERSION DATABASE:......
SET UP OF LIVE RING:......
DELETION OF CONVERSION DATABASE......
Tracking Critical Conversion Dates......
Conversion Considerations: Introduction......
Parameters Affecting Conversion......
Creating Conversion Files......
Conversion Considerations: Pre Live Preparations......
ABSTRACTING CONSIDERATIONS FOR UB CONVERTED ACCOUNTS......
FINAL BILLING ACCOUNTS OFF CURRENT SYSTEM......
ENSURING ALL CHARGES ARE ENTERED INTO THE CURRENT SYSTEM......
CONTRACT ACCOUNTS......
CLIENT ACCOUNTS......
Chapter 2: Getting Started with Conversion Testing......
Hospital Checklist......
Setting up the Conversion Database......
Hospital Conversion Testing Schedule......
Conversion Main Menu......
Loading Demographic Conversion Files......
View Conversion Process Status......
Check and File Routine......
Status Summary......
Timing Report......
Various Rejection Lists......
Summary of Account Rejections......
Detail of Account Rejections......
Invalid Dictionary Entry List......
Invalid Query Mnemonics List......
Additional Rejection List......
Demographic Rejection Reasons......
Fixing Demographic Rejected Record......
Loop and Edit......
Edit One File......
Purge Routines......
Purge Temporary File......
Purge Permanent Data......
Verifying Account Information......
Loading Detail Conversion Files......
Detail Rejection Reasons......
Reprocess Rejection Batches - Detail......
Balancing the Conversion......
Balancing Tools For Detail Conversions......
List Current Balance Record......
Account Balance Compare......
Insurance Balance Compare......
Insurance Balance Auto Adjust......
Additional Testing Requirements......
Testing Statements in the Conversion Database......
Closing the Month in the Conversion Database......
Conversion Sign-Off......
Training In The Conversion Database......
Chapter 3: LIVE Conversion......
Live Checklist for a Detail Conversion......
Moving Custom Menus and Reports from Test to Live......
Conversion in Progress Flag......
Routines Used Only For Live......
Reserve Account Numbers and List Compare Conflicts......
Compare/Reserve Accounts in ADM......
List Compare Conflicts......
Print Statements After Detail......
Re-Evaluate Next Collection Event Date......
Cut Late Bills For BD Accounts......
Demand Cutoff In Conversion Month......
Verifying the Integrity of the Insurance Buckets......
Conversion Month End......
Backups......
Organization of Notebook
This notebook 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 notebook should be reviewed during the conversion evaluation phase, prior to the B/AR Assessment Visit (Hospital Reviews Conversion on your PTS schedule). Any questions the hospital has regarding the contents of this notebook 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 notebook 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 information 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
Background on Conversion
This section explains what will be converted in a Detail Conversion. For a detailed listing of individual fields that will be converted in the Detail conversion, please refer to your conversion specifications.
The DETAIL CONVERSION involves converting "FB" and "BD" accounts with a balance as of FINAL BILL. This information comes over with Demographic information on the demographic file. The account will get all its AFTER FINAL BILL transactions (receipts, adjustments, refunds and late charges) converted onto the MEDITECH system through the DETAIL file. Transactions after the final bill will bring the account to its current balance (Balance After Final Bill subtracting out any receipts, adjustments, and adding in refunds will equal the account's current balance).
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.).
"UB" accounts come over with no account balances on the Demographic file. Unlike "FB" and "BD" accounts, ALL detail transactions (Charges, Receipts, Adjustments, and Refunds) are converted via the DETAIL file. These accounts will be billed off the MEDITECH system and should therefore behave like a
regular account in the system.
As the result of a Detail conversion, the hospital will have the following information on the MEDITECH system:
FB and BD accounts - No detail charges prior to the Final Bill. After Final Bill, all receipts, adjustments, refunds, and late charges that bring the account to its current balance. The hospital has the ability to generate statements, late bills and late claims for FB accounts.
UB accounts - All demographic information and all charges, receipts, adjustments, and refunds are brought over via the detail conversion file. The hospital has the ability to generate all bills and claims and statements for these accounts. 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 converted as UB will not interface to ABS and will have to be coded, for claims purposes, directly in B/AR.
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. 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.
With a Detail conversion there is significant testing required. Details regarding the testing process for Detail conversions can be found in the section: GETTING STARTED WITH CONVERSION TESTING of this notebook.
The hospital will need to formulate a Live schedule that will outline when various activities are taking place, and their duration. The hospital can refer to section LIVE CHECKLIST FOR A DETAIL CONVERSION of this notebook 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 two files created for each B/AR status (UB, FB and BD):
_____ One for Unbilled account demographics
_____ One for Unbilled detail charges
_____ One for Final Billed account demographics
_____ One for Final Billed account detail (after final bill)
_____ One for Bad Debt account demographics
_____ One for Bad Debt detail (after final bill)
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.
CONV FAC = Map facility indicator to the appropriate facility mnemonic. The facility indicator will be different for each hospital. Speak with your specialist to help determine what this indicator could be. If your hospital is not multi-facility, a default value can be used in the map.
CONV PROC = Map charge and non-charge procedure code to appropriate BAR Procedure Dictionary mnemonic.
The following is an example of the claim maps the hospital must set up for the conversion:
Mapping: Auto Creation Menu & Conversion Tools
The following menu contains routines which have been created to assist hospital's in building various maps. These routines will allow the hospital to build the conversion maps from entries defined in the respective dictionaries.
Routines to Auto-Create Conversion Maps
For the Provider and Insurance Dictionaries, two Customer Defined queries (ex. MIS.OLDPROV and MIS.OLDINS) would need to be defined in the Query dictionary to store the Other Vendor (OV) mnemonic. Each query will also been linked to separate Customer Defined Screens (CDS) (ex. PROV 2ND PAGE and INS 3RD PG). These screens must be defined as a screen type 'MIS DICT', and have been linked internally to the respective dictionary by your Specialist. This will allow the hospital to store the OV mnemonic within the MEDITECH dictionary via the CDS. The Provider and Insurance dictionaries can be uploaded into MEDITECH. The old value can be part of this upload and populate the queries during this process.
For the Procedure Dictionary, the “old code” field needs to be set up as an Alt Code, and the old charge code must be attached to the BAR Procedure Dictionary entry for each charge procedure. The old code can be included in the Procedure Dictionary upload file that is submitted to MEDITECH. Only charge procedures are included in the auto-create routine for the CONV PROC map.
Note: These maps can only be created in the TEST database. The reason for this is when MEDITECH establishes the hospital's live directory we will copy from the TEST database and not the CONVERSION database. Once the maps are created in the TEST database, the user will simply copy or move the maps from TEST to CONVERSION using routine COPY MAPS TO CONVERSION DATABASE. This routine is described later in this section. Also worth noting, these routines will be run by MEDITECH once just before the Applications I visit when conversion training takes place. Any future changes to the Insurance or Provider dictionary to add or inactivate an entry must also have the appropriate edits made to the CONV INS and CONV DR maps.
Copy Maps to Conversion Database
This routine will be utilized to move the conversion maps from the TEST database to the CONV database. As was mentioned above, the routines to auto-create maps will be creating the maps in the hospital's test database. This is because we copy dictionaries from the hospital's TEST database to the LIVE database, and not from CONVERSION. This routine will prompt the user with the following choices:
The FROM side of the routine will default in information based on the universe, HCIS Database and Application Database the user was signed in from when he/she accessed the routine. Since the user will be copying from TEST to CONVERSION, the user will be restricted to only enter in a BAR.CONV database to copy into. The user will then enter in the maps to be copied; a lookup is available.