Application Facts

• The Billing Application is typically the last stop in a patient record's journey through the system after the patient has passed through the clinical applications and experienced patient care. Billing is where a patient's charges are entered either manually or through the automated batch entry routines and bills, claims, and statements are processed and money is collected for clinical services performed.
  
• Patients and charges flow into the BAR module through interfaces from ADM and the ancillary clinical modules, but the only application BAR is what we call "open" to is MIS.  This means that data fields and information from MIS can be obtained with either a possessive or a computed field and utilizing subscripting, but one will need to write a fragment to gather information form any other module with the exception of MIS.  Possessives to any DPMs outside of  the BAR application will not work.
  
• There is a large amount of data stored in the BAR application. However, in writing reports, there is also an issue of purging which takes place in the BAR application as patients, period end information, batches, claim tapes and report files can all purge. These are all controlled by the Purge parameters on Page 3 of the BAR parameters and can be set anywhere between typically 5 days and 999 days depending on personal choice, system resources, etc. The batches, claim tapes and files purge automatically as part of the close day process but the patient accounts themselves must be manually purged using the standard routines located in the Purging submenu.
  
• The only exception to this rule in terms of purging patient data is that the period end information which is located in BAR.PAT in the pe status vector segments purges at the end of the month during the close month end process and only 3 months worth of data is stored at any given time. For instance, on April 15th, there would be period end information stored for the months of January, February and March. As the period end process for April begins typically a few days before the end of the month, to ready for the storage of the April period end vector information, the January information will be purged and then as of May 1st or whenever the period end process finishes, the information which will then be available in the pe status vector segments will be February, March and April.

back to top

Data Definitions

• The BAR.PAT DPM stores all patient related information and is usually popular DPM in which to write an NPR report.

• The most popular segments within BAR.PAT to use would most likely be the segments of bar.acct which is the main segment in BAR.PAT and stores the singular patient related information, and child segments bar.acct.insurances which stores the patient's general insurance information, bar.acct.bills which stores the bills a patient has received and relevant billing information, bar.acct.insurance.ledger which is also a child segment of bar.acct and stores billed information per insurance, bar.acct.transactions which stores a list of each and every transaction which happened to a patient and bar.acct.pe.status.vector which stores a snapshot of period end information about a patient account at the end of a period.

• In more detail, the segment of bar.acct stores some 400-500 data fields so a large amount of data is stored in this segment. This would be all patient demographic data as well as anything which is "singular" in nature with respect to the patient. In other words, a patient can only have one name, so the name field will be stored in this main segment of bar.acct.

• Conversely, the child segments will store MULTIPLE records per patient or multiple records per each record in the main segment. For instance, a patient can have up to 4 insurances, a patient can have multiple bills printed for him or her, and certainly a patient can have many many individual transactions for each patient record in the BAR system.

• The segment of bar.acct.transactions is one of the most volumnous files in the entire MEIDTECH system as it literally stores each and every transactions which happens to a patient which is interphased with BAR during his or her stay in the hospital and even beyond. This would include all clinical procedures performed, medications given, operations, lab tests, room charges, room transfers, edits made to the patient's file, bills processed, claims sent to insurance carriers, statements sent, reminders and comments added by billers and collectors, payments received, adjustments made, refersing and flagging individual transactions, refunds processed, etc. etc.

• The segment of bar.acct.transactions is a very popular segment to write reports in since it contains such a vast amount and wide variety of information. However, the caution is that virtually any NPR report written in this segment will take a long time to run as in most cases, it must process thousands if not tens or hundreds of thousands of records (depending on the amount of patients stored in the BAR system and the elapsed time since going LIVE with BAR).

• The most popular index files in BAR.PAT would most likely be the bar.acct.acct.type.index if selecting by account type, the bar.acct.adm.ser.date.index if selecting patients by their admit or service date, the bar.acct.bar.status.index if selecting only certain BAR statuses for a report, the bar.acct.discharge.date.index if selecting patients by their discharge or service date, bar.acct.number.index if sorting or selecting by patient account number, and the bar.acct.unit.number.index if sorting or selecting by patient's unit number.

• A key point about the bar.acct.adm.ser.date.index and the bar.acct.discharge.date.index is that when using these indexes for selecting records, you should not use the fields service.date, admit.date or discharge date as selects as you might expect. These index files are subscripted by the fields bar.adm.ser and bar.dis.ser respectively and these are the fields which must be used as select fields to improve efficiency.

• Other common DPM's to use are BAR.BCH which stores batch information, BAR.REV.AT.PI which stores revenue statistics (REV) by account type (AT) and primary insurance (PI), BAR.REV.PROC which stores revenue (REV) by procedure (PROC) and BAR.PROC which is the Procedure Dictionary.

• The BAR.BCH DPM in particular is useful when searching for transaction level information for a more current time frame. Typically, batches purge from the system after somewhere between 60 and 120 days. As a result, the BAR.BCH file stores less transaction level data than say the bar.acct.transactions segment in BAR.PAT since patients are not regularly purged and many sites choose to keep patient records on the system for a very long time. As a result, a report which needs to print transaction information for say the last 30 days would most likely be more efficient if written in BAR.BCH as opposed to BAR.PAT.

back to top

Field Information

back to top

Fragment Links

back to top

Accessing Queries

back to top