WO2010040075A2 - Medical practice billing recapture system and method - Google Patents

Abstract

A method comprises receiving first and second data, wherein the first data corresponds to historical inventory transactions within a medical practice for a selected period and the second data corresponds to historical billing transactions within the practice. A computer-readable medium is provided having executable instructions stored thereon for analyzing at least a portion of the first data and the second data to generate an exceptions list of possible billing errors within the medical practice for the selected period. Each possible billing error corresponds to an associated billing event. Instructions are executed on a computer system to perform analysis of the first and second data, and transactions surrounding each billing event are investigated to verify an existence or absence of a billing error pertaining thereto.

Description

MEDICAL PRACTICE BILLING RECAPTURE SYSTEM AND METHOD

BACKGROUND

Fig. 1 diagrammatically depicts an overview 10 of a representative billing process in a medical oncology practice. Once a patient 12 has been diagnosed by a doctor 13, a diagnosis code is assigned to the patient pertaining to the disease or malady he/she is suffering from. These diagnosis codes are used by Medicare to cross-reference which drugs may be billed for the patient's ailment. Medical oncologists may consult a medical journal 14 which has a regimen for the cancer involved. Resources in the field of medical oncology are available, for example, from the American Society of Clinical Oncology or the American Medical Association. The regimen for the patient likely includes a treatment schedule which includes the drugs to be administered. The doctor creates treatment instructions 15 (i.e., orders) for the medical staff, and these orders become part of the patient's chart. A nurse or pharmacy technician, also referred to as a Pharm Tek 16, reads the orders and prepares the drugs to be administered.

Many practices, oncology included, utilize automated medication and supply management systems to ensure that inventory is available to the medical staff upon demand. Such systems are often leased by medical practices and offer real-time, detailed reporting on cost per patient, inventory levels, and other information to assist in managing the medical practice. In the oncology field and other medical fields, one such system which enjoys widespread use has been marketed under the name Pyxis OncologyStation™ system, or "Pyxis ®" for short. Pyxis ® is from Cardinal Health of Dublin, OH. Another popular medication and supply management system is available from OTN of South San Francisco, CA and marketed under the name Lynx™. These companies monitor their leased systems to ascertain when inventory is low, and they automatically ship new inventory to the site as necessary to cover baseline levels. Medical practices thus pay the drug suppliers for the drugs they use, as well as a monthly service fee to utilize these supply management systems so that inventory levels can be maintained. Pyxis ® and Lynx™ machines, each represented generally by the designation 108, have the capability of generating an inventory report 110. Report 110 can be available in two forms or names. In one form is a .ptx file which can be directly captured from the station. Another is in the form of an archived transaction log from the supplier, OTN, and is indicated by the name PYX ACT ARCHIVE D AT A REPORT. If there is no such system in the particular medical environment, the pharmacy department usually tracks the drugs and supplies through some other mechanism, for example, via a pharmacist who logs into a computer 112 to generate a pharmacy usage report 114. For purposes of this discussion, however, it will be assumed that the oncology practice utilizes a Pyxis ® System.

As well-known in the oncology field and other medical fields, the drugs and supplies (collectively referred to as "inventory items") stored in the Pyxis ® system each have an associated National Drug Code (NDC). The NDC codes are controlled by the FDA, and can be downloaded from their website at http://www.fda.gov/cder/ndc/. A publication known as the Redbook is produced by an independent third party (Micromedix) and is a collection of NDC codes and other supporting information such as pricing. Each NDC code has three parts and is 10 digits long. Each NDC code has one of the following three formats:

(1) #####-###-## (5-3-2)

(2) #####-####-# (5-4-1)

(3) ####-####-## (4-4-2)

An official NDC code can be in any of the above three formats. There is a "normalized" view which is 11 digits and has the format 5-4-2 where an extra '0' or asterisk '*' has been added to the appropriate component. In each format, the first set of digits in the NDC code identify the manufacturer of the drug (officially referred to as the "labeler code"), the second set of digits identify the drug itself (officially the "product"), and the final set of digits identify the packaging of the drug. Thus, a unique NDC code exists for every packaged drug by manufacturer, product and packaging configuration. When third parties reproduce the NDC codes, they may actually pad them with an additional digit in an effort to normalize the three formats above. This can cause confusion, and efforts must be made by programmers to avoid collisions in their coding.

In practice, the nurse or Pharm Tek will log into the Pyxis ® system 108 and remove the medications and/or supplies needed for treating the patient. A record is maintained for what was removed, for example, whether it be an entire vial or a portion of a vial. In doing so, the Pyxis ® system user will also associate the item(s) removed with the patient for whom it is intended. Ideally, all users of the Pyxis ® system maintain a current and correct inventory of its drugs and supplies. The PTX archive report 110 generated by the Pyxis ® system can be in either physical or electronic format, such as a *.csv file.

Once the nurse 11 treats the patient 12 according to the doctor's orders, he/she enters information onto the patient's chart 116, such as the amount of medications administered, time of day, etc. Typically, the nurse practitioner also enters this treatment data onto a super bill 118 to identify what needs to be billed to the provider. Depending on the nature and sophistication of the practice, this can be accomplished in a variety of ways, such as through a computerized or paper entry system. Moreover, either the nurse or other employee may make the determination as to what the particular billing code should be for the service provided. A super bill 118 exists for each treatment session (e.g., each date of service for each patient, generally). In general, each patient has one super bill per day, although there may be multiple super bills if a patient is treated more than once on a given day. Each patient also generally has only one chart which travels with the patient throughout his/her stay at the medical facility. The patient's chart is periodically updated as treatments are provided and may, thus, have multiple sections for different purposes. Chart formatting can vary from practice to practice. A process known as "abstracting" refers to the ability of creating a super bill for a patient by extracting information from his/her chart.

The medical practice also typically has billing personnel such as 120, generally referred to herein as the "biller", who then approves the super bill and enters it into the electronic billing system. Some oncology practices utilize a charge capture (real-time) system whereby all the data is electronically integrated into the system and, based on the characteristics of the data, the charge capture system can recommend charges based on what transpired. Information input by the biller 120 is then stored in a billing database 122. Depending on the particular environment, for example hospitals, there may be separate billers for different units because the billers require different skill sets. Thus, database 122 shown in prior art Fig. 1 may represent a subset of a much larger database within, for example, the hospital itself. If necessary, the biller 120 may decide how to best code the treatment to be billed to the payor 121, which is often Medicare but could be other carriers. CPT (current procedural terminology) coding is used to code administrative services, e.g., injections, office visits, etc., while HCPCS (healthcare common procedural codes) are used for coding drugs within a billing system. Each of these coding sets is dictated by Medicare. Thus, the billing codes for the given drugs and administrative services are typically the same whether the payor is Medicare or a private payor, but the billing charges for such codes may differ. Thus, while the quantities billed will be the same using CPT and HCPCS, the charges to and payments from private payors will typically be higher than Medicare. In any event, biller 120 determines which code is appropriate and charges it out to the payor 121 for payment.

The electronic billing database 122 stores a variety of pertinent information such as patient data, date of service, quantity billed, code billed, accompanied by a description of what was billed and the amount charged, among other things. Billing reports 124 can then be selectively generated from the billing database 122. There are a variety of billing application programs available to medical practices in general, and the oncology practice in particular. For the most part, such billing programs are believed to use their own custom backend. The databases are thus usually customized per site so that these programs can vary across applications. Representative billing programs include Allscripts, Cerner, Encore, Impac, Lytec, Medical Manager, Medisoft, Mysis, PCN, AdvancedMD and IDX .

Medicare determines what the average sales price for a drug is for purposes of reimbursement. In 2005 Medicare changed its guidelines from a wholesale pricing strategy to an average sales price (ASP) strategy. Currently, reimbursements are calculated as the average sales price +6%. Medicare maintains a database which identifies what the ASP is for each individual code that can be paid, and this database is updated quarterly. With such recent changes, drug companies in general are not being reimbursed as much of a premium over their costs, resulting in less profit margins. Thus, many medical practices struggle to survive if their billing system is not efficient and cost-effective. Reimbursement from private pay carriers is somewhat different because contracts with them can be negotiated, unlike Medicare. However, private pay carriers typically lag one month behind in reacting to what Medicare implements.

As with any billing system which is not fully automated and involves human intervention, mistakes can occur. In the medical oncology field, for example, under-billing is prevalent. Since the healthcare industry today is subject to much public scrutiny, it is vital for a practice's survival to provide reputable healthcare in a cost-efficient and profitable manner. A practice's billing system is one area where many mistakes can occur throughout the system. Where human error is involved, the mistakes can be wide ranging and stem from inattention to detail, a lack of knowledge about billing procedures and codes, a neglect of duties, or purely inadvertent mistakes (e.g., improper keystrokes). Regardless of the derivation of the mistake, the result can be reduced profits for the medical practice as these mistakes ultimately translate into improper and/or insufficient billing. A need, thus, exists for a billing recapture system for use in a medical practice for optimizing revenue streams. The present invention is directed to meeting this need.

SUMMARY

A method comprises receiving first and second data, wherein the first data corresponds to historical inventory transactions within a medical practice for a selected period and the second data corresponds to historical billing transactions within the practice. A computer-readable medium is provided having executable instructions stored thereon for analyzing at least a portion of the first data and the second data to generate an exceptions list of possible billing errors within the medical practice for the selected period. Each possible billing error corresponds to an associated billing event. Instructions are executed on a computer system to perform analysis of the first and second data, and transactions surrounding each billing event are investigated to verify an existence or absence of a billing error pertaining thereto.

The investigation of transactions surrounding each respective billing event preferably comprises identifying the patients involved, identifying the date of service involved and pulling relevant portions of the patient's chart. A report may be generated which, for each exception within the exceptions list, includes an analysis of why the respective billing event occurred, a re -billing recommendation and imagery from the respective patient's medical record which supports the re- billing recommendation. Analysis codes may be included in the report, with each analysis code associating the circumstances surrounding each billing event for which a billing error is verified. A list of analysis codes may, thus, be compiled relating to circumstances within the medical practice which result in verifiable billing errors. In exemplary embodiments, analysis of the data includes executing a set of algorithms against the first and second data to identify possible billing errors. For example, with respect to each HCPCS code in the historical billing transactions, a possible billing error may be identified when (1) a number of occurrences of a particular quantity billed during the selected period falls beyond upper and lower outlier limits; (2) historical quantities of units billed over the selected period for a given patient and for a given drug reveal anomalies in billing activity; or (3) anomalies are identified in a patient's treatment pattern.

Also in preferred embodiments, each item of inventory has an associated national drug code (NDC), and each billing transaction pertaining to a selected drug has an associated healthcare common procedural code (HCPCS). The executable instructions are operative to perform a first mapping between dosage of NDC codes in inventory and dosage of HCPCS codes in billing prior to analyzing the first and second data with a set of algorithms. For each drug identified in inventory, a preferred HCPCS code billing resolution sequence may be identified, and the executable instructions preferably generate a possible billing error when an actual billing sequence for a selected event fails to adhere to the HCPCS code billing resolution sequence. The executable instructions preferably also perform a second mapping between patient-related information in the first data and patient-related information in the second data. Such patient- related information may include patient name, date of birth, a system patient identifier (e.g, patient ID), patient gender and/or patient date of service. The executable instructions may also logically group, for each date of service and for each patient, the first and second data by the drugID corresponding to each drug administered to the respective patient. The instructions may also ascertain, for each drug which according to its NDC code can only be administered to a single patient regardless of quantity used, whether an entire vial of the respective drug was unbilled, thereby to generate an exception for each such determination.

A system is also provided which comprises an inventory data retrieval component for receiving first data corresponding to historical inventory transactions within a medical practice for a selected period, and a billing data retrieval component for receiving second data corresponding to historical billing transactions within the medical practice for the selected period. A database component stores the first and second data. A data conditioning and analysis component interfaces with the inventory and billing data retrieval components. The data conditioning and analysis component analyzes selected records from the first and second data to generate an exceptions list of possible billing errors within the medical practice during the selected period, wherein each possible billing error corresponds to an associated billing event. A reporting component produces an output report that identifies each verifiable billing error.

DETAILED DESCRIPTION OF THE EXEMPLARY EMBODIMENTS

In the following detailed description, reference is made to the accompanying drawings which form a part hereof, and in which is shown, by way of illustrations, certain exemplary embodiments. The leading digit(s) of the reference numbers in the figures usually correlate to the figure number; one notable exception is that identical components which appear in multiple figures are identified by the same reference numbers. The embodiments illustrated by the figures are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and changes may be made without departing from the spirit and scope of the present invention.

The described embodiments herein relate to a medical billing recapture system, otherwise referred to as a revenue recovery system, for verifying missing charges in a billing system. Once identified and verified, information about the missing charges can be provided to a user who, at his/her discretion, can elect to re-bill for the services and recoup lost revenue. While the embodiments are described with reference to the field of medical oncology, the ordinarily skilled artisan should appreciate that the teachings can be applied to other medical fields, such as radiation oncology. Indeed, any suitable billing environment could benefit from the described concepts. Moreover, while the described embodiments pertain to the tracking of drugs and other supplies in a medical oncology practice, at times collectively referred to as "inventory", the concepts herein can be extended to any suitable form of inventory which can be tracked. In this regard, it is contemplated, though not necessarily deemed required, that each of the inventory items to be monitored will be identified by a unique code within the system, such as an NDC. In its exemplary application, though, the invention relates to the monitoring of uniquely coded billable items that are maintained in some type of inventory system or billing system which codify transactions by quantities and unique identifiers. With the above environment in mind, initial reference is made to Fig. 2 which expands upon the diagrammatic overview of the billing process described above. More particularly, Fig. 2 depicts an exemplary overview of a billing process 20 which is similar to billing process 10, but incorporates other features such as the addition of a revenue recovery component 22. Together, the revenue recovery component 22 and the features of the billing system can comprise a revenue recovery system. Revenue recovery component 22 has the ability to selectively interface with certain aspects of a conventional billing environment. More particularly, revenue recovery component 22 receives medication and supply management information, generally 24. Preferably, this information is either the PTX archive 110 or pharm report 114 since oncology practices typically utilize one or the other. Revenue recovery component 22 also receives billing data, generally 26. This billing data 26 can be in a variety of forms, such as a standard billing report 124 which typically represents a subset of information within the billing database. Alternatively, the billing data 26 can be derived from any customized billing report such as 125 generated by querying the practice billing database. A customized report might, for example, be provided by the customer as a front end to their database.

The input data retrieved from these two sources 24, 26 is analyzed to generate exceptions which may be indicative of an improper billing event. These exceptions, or flags, will alert a user to a particular event which can be investigated further to verify if the generated exception relates to either an under-billing or over-billing situation. Depending on who is actually using the system, one or both of these may be of interest. The teachings are described in the context of a medical practitioner customer who would more likely be interested in identifying under-billing occurrences. Once an exception has been identified for a patient, the patient's chart can be (but preferably always is) consulted, if needed, in an effort to verify the generated exception.

Fig. 3a illustrates the import of billing and inventory data into the revenue recovery component 22. In the current implementation, historical inventory data is obtained for a period of approximately 15-27 months. As discussed above, the inventory data 24 may assume a variety of forms, such as PTX archive data 110 from a Pyxis ® or Lynx™ system, a pharm report 114, or some other type 109. Where PTX archive data is used, it is pre-processed at 32 through an application function and then input directly into the system's primary database 34. The pharm report 114 or other inventory data 109 is pre-processed at 36 so that it can be stored into a suitable file 38, such as a *.csv file, before being imported into a database 34. Thus, in its current implementation, the PTX archive data is essentially communicated directly to the database, while the pharm report or other data is first stored as a file 38 that is then loaded into the database. However, as also illustrated in Fig. 3a, the PTX inventory data could optionally also be stored as a *.csv file before being loaded into database 34. The ordinarily skilled artisan could, of course, devise other approaches for importing the various types of inventory data into the database, so that Fig. 3a is only representative of one such approach for accomplishing this.

In practice, the inventory 24 can be directly uploaded through a modem or other suitable communications channel to a system which supports the revenue recovery component 22. For example, current Pyxis ® systems run Windows NT and have a keyboard for data entry. These machines can have an encrypted modem connection via a PC Anywhere™ interface, or the like. Alternatively, the data can be imported from a backup system at the customer's site, from the company leasing the machine, or even through an application program operative to compress and encrypt the data for purposes of e-mail transmission. These are, of course, only representative of a few approaches for capturing the inventory data of interest.

Billing data 26 comes from multiple databases (various representative types noted in Fig. 3a) generated from different billing systems such as those discussed above in the background section. It is contemplated that this data can be imported either statically or dynamically in a variety of ways known in the art or hereafter developed. For example, many billing systems have a Crystal Reports™ feature and accommodate standardized communications protocols for interfacing with their databases. Alternatively, import modules could be written for each billing system's database to extract data from it. Still another alternative would be for the customer to generate a report having certain fields based on a requirements document.

Once acquired, billing data 26 also goes through a pre-processing routine 310 so that it can be converted to a desired format and stored in a file 312, representatively identified as "bills. csv", that is communicated to the database 34. Alternatively, the billing data 26 can go directly into the database via pre-processing 314. The system's main application program interacts with the database. More particularly, the main application program systematically captures under-billed transactions and is representatively abbreviated as "SCOUT" (Systematic Capture of Underbilled Transactions).

Generally speaking, preprocessing of the data in Fig. 3a may be done either with SCOUT or with separate ETL scripts and can be either loaded directly into the database or pushed into the Bills. csv and the Inventory.csv and imported directly into the database.

A newer approach illustrated in Figs. 3b & c uses a set of custom made ETL scripts that process the data without sending it through SCOUT or even to these intermediate files. This is much faster and allows the data to be scrubbed more efficiently and thoroughly. Here, the input billing or inventory data is stored as a .csv file 315 which is acted upon by an ETL engine 316. ETL engine 316 utilizes supplemental data, for example a valid list of NDC codes, from database 34 to process the .csv file and generate a clean.csv file 318 and a rejects. csv file 320. Rejects. csv basically contains data which is not proper and fails any processing step within the ETL engine 316. The file clean.csv is then loaded into the database which, as well known in the art, can have user-configured constraints applied in this regard.

The processing which occurs in ETL engine 316 is shown in Fig. 3c. The input csv file shown in Fig. 3b is formatted to include a header and a plurality of columns which each contain transactional data. Each row in the .csv file corresponds to either a billing or inventory record. Each column is separately processed by a respective input processor and a respective output processor. Each output processor can talk to multiple input processors, as representatively shown. Input processors are generally represented by the designation 324, and output processors are generally represented by the designation 326. Each input processor accomplishes pre- verification, transformation and post- verification of data. For example, if the information in a respective column is intended to pertain to a date, then the pre-verification step can confirm whether the data is in fact a date. The transform step transforms the date, and the post- verification step confirms that the date was transformed properly. Each output process also accomplishes transformation and post-verification. As needed also, an output process may incorporate a step of combining data from multiple input processes. For example, it might be necessary to combine the first, middle and last names of a patient, or to search for an NDC code in one of four fields. Once output processes 326 have completed, the revised data is written out to the clean. csv file 318. If any step fails with respect to any input process or any output process, then the record (i.e., the data in a respective row) is sent to the rejects. csv file. This file can be manually inspected to identify issues or re-processed by the ETL engine 316 as needed.

Fig. 4 illustrates a functional block diagram of a system otherwise referred to as a revenue recovery component 22. In the exemplary embodiment, revenue recovery component 22 can be regarded as a main application program having three sub-components, described in more detail in subsequent figures. A first sub-component 41 incorporates data import and pre-conditioning. That is, steps are taken to ensure that the database 34 used by the main application program is populated with the proper data and has been properly conditioned within the system. To this end, the various NDC codes need to be maintained and updated. The primary source for current information is the FDA website. Failing this, official package inserts can be searched. Failing this, the Redbook and other third party sources can be consulted for such information. This maintenance component can be implemented either manually or automatically. The same holds true for the CPT codes and the HCPCS codes. As well known in the industry, CPT codes and HCPCS codes are billing codes. Oncology represents a subset of these two code sets. CPT codes typically begin with numbers, while HCPCS codes begin with letters. CPT codes are administration insurance billing codes and, for example, typically have the following format:

9#### (admin) 96### (chemo admin)

Sometimes a "G" code will also be used for administrative services.

HCPCS codes are drug insurance billing codes. A given HCPCS code represents a formulation of a drug and typically has the following format:

J#### (drug) J9### (oncology drug)

In HCPCS terminology, all drugs have a "J" designation and the digit "9" represents oncology. Thus, the designation "J9" represents an oncology drug. A second sub-component 42 of revenue recovery component 22 pertains to exceptions generation, mentioned previously. At this stage, multiple algorithms analyze the billing and inventory to identify suspicious transaction events. This stage can analyze either or both the billing and inventory data. A third sub-component 43 may be in the form of a user interface (UI). At this stage, trained account specialists, who are assigned certain types of exceptions to investigate, consult patient charts to ascertain whether the exceptions are valid and what may need to be done to recover lost revenue. This resultant information can then be compiled into a report and provided to the customer. A representative such report is shown in Fig. 13.

Another embodiment for a system may incorporate components for receiving inventory and billing data. Here, an inventory data component receives first data corresponding to historical inventory transactions within a medical practice for a selected period. A billing data retrieval component receives second data corresponding to historical billing transactions within the medical practice for the selected period. These components can entail any suitable hardware and/or software implementation for capturing, in either real time or though a store and forward approach, the inventory and billing data onto suitable media(s) for processing and analysis. This system also preferably incorporates a database component for storing said first and second data in a database. A data conditioning and analysis component is interfaced with said inventory and billing data retrieval components, at least to the extent that it can retrieve data therefrom for analysis. This component analyzes selected records from said first and second data to generate an exceptions list of possible billing errors within the medical practice during the selected period, wherein each possible billing error corresponds to one or more associated billing events. Finally, a rreporting component produces an output report that identifies each verifiable billing error.

Fig. 5 diagrammatically illustrates the process 50 for generating and validating exceptions. The inventory data 24 and/or billing data 26 is analyzed by a set of algorithms 52 to generate an exceptions list 54. Exceptions list 54 serves to identify "red flag" events to be further investigated. For purposes of the description herein, the term "event" is intended to encompass any transaction that appears to be incorrect. Representatively, this includes billing too many units, not billing enough units, billing the wrong code, billing for an incorrect drug, billing a drug to the wrong patient, billing or not billing for drug waste, billing on the wrong date of service, charging too much, being paid too little, using the wrong administration codes, mismatched administration and drug codes, patterns that deviate from surrounding data, , failing to bill for a drug, billing for a drug which was not administered to a patient, and billing for a nonreimbursable drug and billing that is significantly different statistically from subsets of the data. Among the information pertaining to a particular exception within the exceptions list is the identity of the patient involved (patient ID) and the date of service in question. Since it is contemplated that the exceptions list 54 will pertain to multiple patients, a list 56 of patient charts can be identified. Relevant portions of patient charts are then pulled 58 from the client customer 510. This information can be copied, scanned or stored in any suitable media, such as a charts DVD 512.

Depending on the types of exceptions generated in exceptions list 54, one or more tasks 513, 514 can be assigned for personnel 516 to investigate. As mentioned above, these personnel are account specialists who are equipped in investigating certain types of exceptions. Over time, a compilation of analysis codes 518 can be maintained pertaining to the various types of circumstances which give rise to the "events" which generate exceptions within the billing system. In addition, the account specialists have multiple guides at their disposal, such as one or more CPT or HCPCS guides 520, which may be consulted while performing their investigation. Once the analysis of the generated exceptions have been completed, the account specialists 516 have, to the best of their ability, ascertained the "why" behind each billing event that generated an exception. They then associate one or more of the analysis codes with each exception at 522, and propose a recommended course of action 524 for re-billing to correct the error(s). Together, a final report 526 (see Fig. 13) is prepared for the customer client. Preferably, this final report identifies, for each exception within list 54, the analysis code for why the event occurred, the re- billing recommendation and an image of any associated "proof from the medical record.

With an appreciation of the above, reference is now made to Fig. 6 which illustrates a high-level flow diagram for the revenue recovery process 60. Following start 62, a preparatory step 64 is involved to suitably condition the data for analysis. As mentioned above, the data sources 66 can be one or both of inventory data and billing data, 24 and 26 respectively. An extraction, translation and load (ETL) process is implemented with respect to the data sources at 68. ETL process 68 helps to ensure that the data from the data sources is valid, verifiable and in a suitable format for loading into the database at 610, as would be understood by the ordinarily skilled artisan in the field of database management and design. Data entry mistakes, for example those made during operation of the Pyxis ® machine, can be identified and rectified at this point. For example, a user may have inadvertently referred to a quantity of a particular drug as being 1 milligram when 1 meg was intended.

Once preliminary operation 64 is completed, mapping tables are created at 612, and this process is described in more detail below with reference to Fig. 8. A set of algorithms is then run against the data at 614. The exceptions list is generated by these algorithms, from which charts that need to be pulled can be identified at 616. The information pertaining to the exceptions on the exceptions list is then analyzed at 618 so that results, typically in the form of a report, can be generated for the customer at 620. Process 60 then ends at 622.

A permutation flow diagram 70 is depicted in Fig. 7 to illustrate the various manners in which exceptions can optionally be generated based on user preferences. Inventory data 24 is stored in its own table portion of the database, the client's schema, generally referred to as 72. A crosswalk algorithm 74, which is described in more detail below with reference to Figs. 8a & b, is applied against the inventory data to generate associated exceptions 76. In addition, or as an alternative to this, it is contemplated that algorithms can be applied against data at 78 pertaining to the NDC codes identified within the inventory data. These algorithms would require the quantity and units (mg, meg, etc.) and other transaction information from the inventory data. For example, one algorithm might look for optimal waste strategies. These algorithms, though not yet developed, could be used to generate their own exceptions at 76. Another branch of diagram 70 acts on the billing data 26 which is also stored within its own table within the client's schema 710. A set of billing algorithms 712 are applied against this data to identify associated exceptions 76. Alternatively, or in addition, the crosswalk algorithm 74 can also be applied to the billing data to generate exceptions. It should be recognized that algorithms can run against the quantities or other components of the data, such as the amount charged or paid to see how it compares to ASP+6% . Thus, the invention is not limited to just billed quantities, and there can be some rules/algorithms (or db queries) that check for undercharges and underpayments. Technically, exceptions could also be generated from such things such as dates of service (e.g., for a patient who has a pattern of being seen every day M-F, but one week, doesn't show up on Wednesday). An exception would indicate the possibility of a missed date of service (DOS). Fig. 8a illustrates a mapping technique 80 which is implemented for purposes of executing the crosswalk algorithm 74. The mapping 80 is done between the NDC codes in inventory 82 and the billing codes 84 - preferably at least HCPCS codes but CPT codes could be used as well. Many NDC codes can be associated with one "drugID", an internal identifier, and the drug ID is used to create the "mapping" between the NDC and HCPCS. Thus, the mapping may use multiple NDC codes mapped to a drugID then mapped to a set of HCPCS codes. Crosswalking the drugs involves extracting the vial information from the NDC code. This is typically located in the packaging data but is not always consistent. It is important to obtain the weight (e.g., mg) and volume (e.g., ml) for the substance, where applicable. A vial must be marked as single- or multi-dose. Single dose vials typically allow for billing of the entire vial including any discarded amount. HCPCS can bill in multiple forms including weight (e.g., mg) and volume (e.g., ml). Since the NDC code contains both weight and volume information, it is possible to convert the dose to either weight or volume as required by the HCPCS. This allows us to compare the dose.

Initially, the various inventory and billing records are categorized to identify the drugs to which they relate. Then, based on a dose of a drug withdrawn from the Pyxis ® (or Lynx) machine (as identified by an NDC code), the proper coding for billing purposes is determined. This may correspond to one or more HCPCS codes for each NDC. For example, the doses from the NDC codes can summed together to create a total dose. This total dose is then used to determine the proper coding. For example, the nurse may withdraw 13 mg from an 80 mg MDV with NDC-A and then 27 mg from a 40 mg MDV with NDC-B for a total of 40 mg. Once the proper billing coding is determined, the crosswalk algorithm will compare that against what was actually billed for the drug to determine if an anomaly exists.

Accordingly, one or more tables can be set up within a database, and coding can be implemented to map NDC codes to their corresponding HCPCS code(s) within a mapping table 86. This can be a many-to-many relationship. An intermediate drug table preferably exists for mapping from NDC to HCPCS code. This intermediate table currently includes the type of the drug (active ingredient). Each NDC code can have multiple HCPCS that can be used to bill for it since coding guidelines can allow for multiple resolutions per drug. Thus, drugs can be billed at different quantity increments. For certain drugs, there may be strict coding guidelines, or coding guidelines which are deemed to be preferred or correct. Such guidelines can be implemented as part of the mapping process to identify allowed sets of HCPCS billing codes for each drug. In addition, each drug can have different manufacturers, vial sizes, and vial types or packages. For example, some vials are single dose vials (SDV), while others have different packaging or delivery mechanisms such as "pre-filled syringe" which is essentially a single needle for a single patient, "single dose vial" which is a vial that has a shelf life of only a few hours, or "multi dose vial" which has preservatives and can be used for many days. As such, there can be multiple NDC codes corresponding to a given HCPCS code.

A preferred billing resolution algorithm can be provided in the code which, for a given NDC code, takes the largest physical quantity represented by the drug's corresponding HCPCS code(s) and determines how many increments of such quantity can be applied against the dosage represented in inventory. A remainder is then determined, and this process is sequentially repeated for the next largest physical quantity until a billing code resolution sequence can be defined. The system can generate an alert if the HCPCSS code billing resolution sequence does not adhere to protocols which are established, and this feature can be selectively toggled on or off as desired.

As shown in Fig. 8b, a mapping 88 is also performed between patient-related information in inventory 810 and patient-related information in billing 812. Patient crosswalk requires a manual or semi-automated algorithm to determine patient equivalence within the data. The matching may use any or all of (but not limited to) the following: name, date of birth, patient ID (if identical in both data sets), gender, and correlation of dates of service. Data representing patients in inventory is often different than the corresponding data in billing systems, and there are rarely identical designations for each. For example, inventory may have a system patient identifier (e.g., patient ID), while billing may have a medical record number (MRN) for identifying a particular patient. Moreover, patient names could be misspelled or different in the two sets. In the best of cases, the patient ID in inventory is the same as the medical record number in billing, although this is quite rare.

Algorithms and tools are used to attempt to match the patient records within inventory and billing and place them in a corresponding mapping table 814. Initially, an attempt is made to match every patient record in inventory to its corresponding record in billing. To the extent exact matches cannot be found, a loose matching procedure is performed to link those records which remain. Confidence levels can be implemented to ascertain how much percentage error is allowed during such matching. A last step is to attempt to correlate dates of services that a given patient appears in inventory to the corresponding patients that were treated on those dates according to the billing records. This correlation can then rank the records accordingly and provide recommendations regarding matches. Of course, at any time, user intervention can manually override or dictate the correlation between the patient-related records in inventory and billing.

Reference is now made to Fig. 9 which shows a flowchart for the crosswalk algorithm 74. Following start 90, the records in inventory are grouped by date of service 92 and by patient 94. This logical grouping is illustrated in diagram 1000 in Fig. 10. For each patient at 96, the inventory and billing records are grouped by drug ID. This is shown, for example, in the inventory and billing columns 1002 and 1004, respectively, in Fig. 10 wherein each row pertaining to a date of service for a given patient corresponds to a particular drug which was administered. Thus, for example, it may be appreciated that on the Day 1 for Patient A, four different drugs were administered, each having an associated NDC code and an associated quantity. A first drug "NDC-I" was billed at quantity "Qty-1". This drug was administered again under the designation "NDC-2" and billed at a quantity "Qty-2". In total, four drugs were administered to the patient during the day's treatment.

Once the inventory and billing has been grouped by drug ID at 98 (Fig. 9), a single dose vial check is made at 910. That is, there are some drugs which, according to their NDC codes, can only be administered to one patient even if only a portion of the vial is required. When this occurs, an exception is generated if the entire vial size was not billed. The ability to generate exceptions in such circumstances can be toggled on or off. If such an anomaly is of interest, an inquiry is made at 912 with respect to the drug to determine if it requires single dose vial billing. If so, a determination is made at 914 whether any waste is expected and, if so, waste entries are searched for the dosage at 916.

There are various situations where waste might appear in the data, including, for example: 1) inline with the dose transaction, the system may record the amount wasted or "discarded", 2) a special single account in the system can be used to track waste specifically, or 3) waste may be recorded in individual accounts that have identifiers close to the original ID in the system, recorded as separate transactions (e.g., "01234" is the dosing account and "101234" is the waste account - note the exclamation mark in the second identifier). In all but case 2 above, the accounts are grouped during the initial patient crosswalk matching. In case 2, a single account is used for multiple patients, so the day's transactions must be searched for a matching waste entry. As an example, if a patient receives 80 mg of drug A from NDC-I (100 mg SDV), then the transactions for the day are searched for a 20 mg NDC-I transaction to match the vial size. If none is found, an underbill is generated (expected 20 mg). If a 20 mg transaction is found, then no exception is generated. No other processing is performed. The matching only looks for EXACT matches to SDV when using method 2 from above.

Regardless of whether the single dose vial check is implemented, a process begins at 918 to ascertain if there were unmatched items when billing the various drugs for the patient on the various days. The designation "strayed" refers to there being an item on one side (of inventory or billing) that could not be matched to an item on the other side (of inventory or billing). Any such items may be left dangling. If there is an unmatched billing item, it would appear as if an item was billed that should not have been (overbill). If there is an unmatched inventory item, it would appear is if an item was never billed (underbill).

At 920, the expected billing codes are generated for each drug based on the inventory/billing mapping discussed above with reference to Fig. 8. If strict coding has been enabled at 922, a comparison is made at 924 to ascertain at 926 whether such guidelines were adhered to. If there is a mismatch, an exception is generated at 928. Otherwise, flow proceeds at 930 to the next drug administered to the patient for that day. If strict coding is not enabled at 922, then a comparison is made at 932 of the physical quantities billed as identified by the CPT codes. (This could use some clarification. In the "strict coding", we compare the exact codes and quantities. Without "strict coding" enabled, we first determine the proper coding, then calculate the physical quantity represented by that exact coding. Then we look at the physical quantity represented by the actual billing. We already know that these codes represent the same drug, so we simply check these physical quantities against each other. We do not check the physical quantity from inventory here. We have already concluded that by determining the correct coding in 920.) If the physical quantities billed do not match at 934 to those dosages as calculated by the expected coding, then a determination is made at 936 as to whether the amount billed was greater than expected. If so, an overbill exception is generated at 938. If not, an underbill exception is generated at 940. If the values are the same, flow proceeds to process the next drug at 942. This process is repeated iteratively for each patient, for each day, and for each drug, until complete. It should be noted that the process can occur simultaneously once the data is split by patient by using multi-threading techniques and, thus, does not have to be iterative.

As also shown in Fig. 9, dummy entries are processed at 944. "Dummy entries" refer to temporary accounts that some facilities use when a new patient arrives that is not in the inventory system yet. In some practices, for example, the Pyxis ® machine allow users to create temporary patient IDs for those patients who, for whatever reason, do not need to be tracked or have not had an actual ID assigned to them. "Waste" patient IDs can also be assigned so that a practice can track how much of a drug is being disposed of, e.g., withdrawn but not used. There can be multiple actual patients referenced by these dummy accounts. Dummy processing runs through the same processing as normal patients, except that dummy accounts can only match exactly according to the preferred limitation. Inventory items are removed from the list if they have exact matches; otherwise, they are left for the "unmatched" process. Preferably also, no exceptions are generated for dummy entries. Once the unmatched entries have been marked at 946, crosswalk algorithm 74 ends at 948.

It is not uncommon in some practices for the date of service referenced in the billing system to disagree with the date of service represented in the inventory system. This is generally due to user error in data entry. It is contemplated that an algorithm can be implemented that will look at these kinds of discrepancies to generate an exception if it is able, with a requisite degree of confidence, to ascertain that certain records in inventory correspond to certain records in billing, albeit their dates of service might differ.

Various algorithms which can be employed for generating exceptions are now described in the remaining figures. With initial reference to Fig. 11, a histogram outlier rule is diagrammatically represented. This rule may be applied to the number of units billed (as in this representative example) or the actual physical dosage (not depicted) to account for multiple billing codes (e.g., S) for a single drug. Here, histogram 1100 represents the units billed for a given CPT code, representatively "J0000". A similar histogram would exist for each CPT code in the billing database. In histogram 1100 (not to scale), outliers are used to ascertain the existence of anomalies corresponding to a possible billing error which would need to be further investigated. Representatively, three thresholds are investigated. One threshold 1102 corresponds to the number of billing occurrences which is at 2% of the peak number of billing occurrences for the drug of interest. In this case, it may be seen in histogram 1100 that billing code J0000 occurred twenty times in the system when 10 unit increments were billed. Two percent of this peak number of occurrences sets up a threshold number of occurrences for unit quantities, below which an anomaly is generated. That is, it may be seen that on a very few number of occurrences, billing code J0000 appears in the system in connection with quantities billed at 21 units. This is an outlier which would generate exceptions for each occurrence of billing at 21 units that would need to be further investigated to ascertain if these correspond to improper billing occurrences.

In similar fashion, upper and lower thresholds are identified with respect to the unit quantities billed for a given drug. These thresholds are determined by summing up the total number of occurrences of any unit billed (i.e., the sum of the heights of all the bars on the graph). This gives the "total mass" of the histogram. A threshold is set, here 1% from the top and 1% from the bottom — approximately 12.5 here. The lower (1104) and upper (1106) thresholds are set to be 1% of the total mass, or 12.5, which can be rounded up or down as desired. Starting at the lower end, we take any number of units billed until we reach 12. The first item ' 1 ' has 9, so that is under the threshold. The next bar is ' 10' and has 20 occurrences which gets us to 29, which is over the threshold. Starting at the upper end, we work the same way (the graph needs to change here). The first item is '90' which has 7 occurrences. The second item is '21 ' which has 1 occurrence. This totals 8 which is still under the threshold. The next item is '20' which has 17 occurrences. This totals 28 which is over the threshold.

If the first bar on either end has greater than the threshold number of occurrences, no exceptions are generated for that item. For example, if ' 1 ' had 13 occurrences, there would be no exceptions generated for the lower threshold aspect because that number is > 1% of the total mass. A similar analysis applies with respect to the upper threshold. As can be appreciated from histogram 1100, the algorithm may generate multiple exceptions for a given number of units billed because the 2% threshold sub-rule and the upper/lower sub-rules may both generate exceptions.

Fig. 12 depicts a rule (or algorithm) which can be used to scrutinize drug dosages. Here, a series of billing events can be investigated and patterns applied to the billing events to detect anomalies over time. Currently, only one pattern, referred to descriptively as the "spike" pattern, is employed and is illustrated graphically in Fig. 12. Here, spike pattern 1200 charts the units billed for a given patient for a given drug, as identified by the respective HCPCS billing code. The pattern is iteratively applied to every position in a graph of the history of that billing code for that patient. This pattern detects the form "aba" where "b" is the outlier.

In Fig. 12 it may be seen that the representative drug was billed at a quantity of approximately 28 units on January 8, 2008, at a quantity of approximately 5 units on January 15, 2008, and a quantity of approximately 25 units on January 22, 2008. The first and third points of this "spike" pattern are averaged, giving a baseline level 1202, and the difference between this baseline level and the second point (1204) is calculated. The following logic applies to ascertain, with respect to the units billed for a given drug on a given date, whether an anomaly is present based on the spike pattern:

1. A calculation is made of the difference in the edge points (1- AJC), and processing continues only if the difference is less than THRESHOLD A (e.g., 1%). In a generic sense, any pattern has corresponding "levels" associated with it (e.g., ABA, ABBA, AABABB). The first threshold (THRESHOLD A) allows values that are slightly different to be considered equivalent. For example with a THRESHOLD A of 1%, the values 100, 99, and 101 would all be considered equivalent. Increasing the threshold to 50% includes all values 100 +/- 50 (i.e,. 50-150) in the same level (e.g., "A").

If the upper and lower edge points (A and C) are not approximately the same value, then the pattern does not exist. For example, if the pattern is (10, 10, 5, 5), the spike pattern is applied to (10, 10, 5) and (10, 5, 5). In the first case, the edge points are 10 and 5 which are 50% different. In the second case, they are also 10 and 5 which are 50% different. Thus, the "spike" pattern does not exist in this data. Rather than checking for absolute equality (i.e,, A, B, A) a check is made for approximate equality (i.e., A, B, A +/- 1%);

2. The average of the edge points is calculated as X= (A + C)Il;

3. The percentage difference between B and X is calculated as Y=BZX-I;

4. If the absolute value of Y is greater than THRESHOLD B (e.g., 30%), then an exception is generated because a spike has been detected.

Another pattern, which can be referred to as the "transition" pattern, is meant to read changes in a patient's treatment corresponding to the pattern "aabb" where "a" is the original dose and "b" is the new dose, with a transition from a to b identifying an anomaly which may need further investigation. Another pattern, which may be referred to as the "bounce" pattern, may be created as "aababb". Here, the pattern indicates a dosage change from "a" to "b" with an accidental billing of the original dose "a" on the fourth day of service. Other patterns could be created in the future to detect possible anomalies and are not limited to just 2 levels (i.e., there may be patterns such as 'abcdcba"). In addition, depending on the pattern of activity to be explored, the calculation of dose may change from CPT and units billed to drug ID and physical quantity to account for multiple CPT codes for a single drug.

Generically, the pattern processor:

1) starts with the first sample, assign a new "level" (A, B, C, etc.)

2) for the width of the pattern (e.g., 3 in the "spike" pattern), finds any equivalent values (using THRESHOLD A to allow variance in the actual samples) and groups them into the same "level"

3) repeats 2 for all samples

4) repeats 1-3 until all samples have been assigned levels 5) identifies the pattern and apply respective rules. For "spike", the pattern is ABA and the rule is that the difference in the A and B levels is greater than THRESHOLD B. The actual value of the levels is computed as the average value of all samples at that level.

Another algorithm could be implemented to compare the quantity billed for a given drug to the standard range expected based on the drug code. For example, it might be expected that a given drug would only be billed in a unit quantity falling between 300mg-500mg. If it is billed outside this range, an exception would be generated. In addition, certain drugs can only be billed in precise quantities (e.g., the drug Aloxi (palonosetron HCL injection) is always billed at 10 units, or 250 meg) and, if these quantities are not adhered to, corresponding exceptions would also be generated.

For the field of radiation oncology, other algorithms have also been (or can be) devised, and these are summarized below:

1. RadDiagnosis Switch

This is a "meta" rule that determines a patient's diagnosis and applies diagnosis specific sub- rules. The primary diagnosis would be determined from the billing data, and sub rules would be created and executed.

2. RadTreatmentS witch

This is a "meta" rule that determines the type of treatment a patient received and applies specific sub rules. Currently it only detects IMRT with IGRT and applies the RadIMRTIGRT sub-rule.

3. Radiation WeeklyCodesRule

In radiation therapy, a week is considered 5 fractions, or bursts of radiation. Certain codes such as weekly treatment, continuing physics, and port films can be billed every 5 fractions. This rule determines if the practice is over or under billing these codes.

4. RadComplexity Shift

Radiation delivery can be simple, intermediate, complex, or IMRT. During a course of treatment, it is unusual for the complexity to change. This rule raises exceptions anytime the complexity changes. 5. RadIMRTIGRT

This checks various IMRT+IGRT specific rules: a. Excessive IMRT planning - the planning code should occur only once within a treatment cycle. b. Treatment Devices —if treatment devices and dosimetry calculations appear on the same day, they should be equal. c. Excessive IMRT Delivery —there should be only one IMRT delivery per day. d.. Missing/Excessive Weekly Physics/Management - this checks for over and under billing of weekly codes. e.. Missing Guidance - IGRT requires some sort of image guidance, so this checks for that.

6. BundlingRule

On any given date of service, certain codes will "swallow up" other codes. These services performed in some of these lesser codes are often included in larger more valuable codes, and the system can investigate these occurences.

7. NCCIRuIe

The official NCCI database contains "edits" that indicate which codes can be billed together on a single date of service. This rule checks the data against the official NCCI edits.

8. NPerBlock

Given a set of codes and an integer value, you can run a test to verify that the codes in the set can only appear N times within the given block (i.e., data split - patient, date of service, treatment cycle, etc.).

9. ConsecutiveDatesOfTreatment

This rule tests that a set of codes should occur on sequential dates of service, allowing for partial date span at the start and end of date if desired. a. RadConsecutiveDatesOfTreatment - This checks that radiation delivery occurs in 5-day blocks (consecutive), but allows partial at the beginning and end. So, for example, the pattern "3 5 5 5 1" would be acceptable, but "3 3 5 5 1" would raise an exception. 10. Treatement Splitters algorithms a. Radonc - This determines the start and end of a radiation treatment cycle. Initially the algorithm looked for the Planning codes, but it now looks for consecutive blocks of treatments and places the end after the last delivery and the beginning after the end of the previous treatment block. b. Medonc - This would determine the start and end of a course of chemotherapy. The algorithm will most likely look for office visits and patterns matching to existing known regimens.

Algorithms can also be devised to automatically split radiation data into treatment cycles; identify trends in a patient's exceptions by drug (horizontal) or date (vertical), and other steps to improve accuracy of reporting; display the data with exceptions in an intuitive user interface; and analyze exceptions across dates of service to eliminate false positives for incorrect dates of service (or to automatically identify incorrect dates of service)

With the above detailed description in mind, embodiments of a representative computing environment for use in implementing aspects of the invention are now described. The representative computing environment may utilize a general purpose computer system for executing applications in accordance with the described teachings. The computer system may be adapted to execute in any of the well-known operating system environments, such as Windows, UNIX, LINUX, MAC-OS, OS2, PC-DOS, DOS, etc. The system includes a processing unit (e.g., a CPU) for executing instructions, a system memory for storing programs and data currently in use by the system, and an input output (I/O) system. These various components are interconnected by a system bus which may be any of a variety of bus architectures. The system memory may include both non-volatile read only memory (ROM) and volatile memory such as static or dynamic random access memory (RAM). Programmable read only memories (PROMs), erasable programmable read only memories (EPROMs) or electrically erasable programmable read only memories (EEPROMs) may be provided.

Various types of storage devices can be provided as more permanent data storage areas for the application programs and other data. These can be either read from or written to such as contemplated by a secondary (long term) storage. Suitable devices may, for example, include a non-removable, non- volatile storage device in the form of a large-capacity hard disk drive which is connected to the system bus by a hard disk drive interface such as ATA (IDE, EIDE), SCSI, Fire Wire/IEEE 1 94, USB, or Fibre Channel. The hard disk drive generally includes at least one bootable disk which stores the OS that is loaded into RAM during a booting sequence, although the OS can alternatively be stored on removable media.

An optical disk drive for use with a movable optical disk, such as a CD-ROM, DVD-ROM or other optical media, may also be provided and interfaced to the system bus by an associated optical disk drive interface. The computing system may also have one or more magnetic disk drives for receiving removable storage, such as a floppy disk or other magnetic media, which itself is connected to the system bus via magnetic disk drive interface. Remote storage over a network is also contemplated.

One or more of the memory or storage regions mentioned above may comprise suitable media for storing programming code, data structures, database components, computer-readable instructions or other data types for the computer system. Such information is then utilized by the processor so that the computer system can be configured to embody the capabilities described herein.

Software embodying the present invention may be distributed in a variety of known manners, such as on computer-readable media, containing the executable instructions for performing the methodologies discussed herein. Alternatively, the software may be distributed over an appropriate communications interface so that it can be installed on the user's computer system. Furthermore, alternate embodiments which implement the invention in hardware, firmware or a combination of both hardware and firmware, as well as distributing the modules and/or the data in a different fashion, will be apparent to those skilled in the art. It should, thus, be understood that the description is intended to be illustrative and not restrictive, and that many other embodiments will be apparent to those of skill in the art upon reviewing the description.

The computer system may be adapted to communicate with a data distribution network (e.g., LAN, WAN, the Internet, etc.) via communication link(s) so that, for instance, it can communicate with remote servers, clients, etc. Establishing network communications is aided by one or more network device interface(s), such as a network interface card (NIC), a modem or the like suitably connected to the system bus. These can serve as a common interface for various other devices within a LAN and/or as an interface to allow networked computers to connect to external networks. The system preferably also operates with various input and output devices as part of an I/O system. For example, user commands or other input data may be provided by any of a variety of known types of input devices (e.g., keyboard, pointing device, game controller, power pad, digital camera, image scanner, modem, network card, touch screen, or microphone) having associated input interface(s). One or more output devices (e.g., monitor or other suitable display device, printer, fax, recording device, or plotter) with associated interfaces may also be provided. For instance, a display monitor may be connected to the system bus by a suitable display adapter (i.e., video card) having associated video firmware.

Although certain aspects for a user's computer system may be preferred in the illustrative embodiments, the present invention should not be unduly limited as to the type of computers on which it can be implemented, and it should be readily understood that the present invention indeed contemplates use in conjunction with any appropriate information processing device (IPD) having the capability of being configured in a manner for accommodating the invention. Moreover, it should be recognized that the invention could be adapted for use on computers other than general purpose computers (e.g., embedded computers), as well as general purpose computers without conventional operating systems.

Accordingly, the present invention has been described with some degree of particularity directed to the exemplary embodiments of the present invention. While a number of exemplary aspects and embodiments have been discussed, those of skill in the art will recognize certain modifications, permutations, additions and sub-combinations thereof. It is therefore intended that the invention be interpreted to include all such modifications, permutations, additions and sub-combinations as are within its true spirit and scope.

Claims

What is claimed is:

1. A method, comprising: receiving first data corresponding to historical inventory transactions within a medical practice for a selected period; receiving second data corresponding to historical billing transactions within the medical practice for the selected period; providing a computer-readable medium having stored thereon executable instructions for analyzing at least a portion of the first data and the second data to generate an exceptions list of possible billing errors within the medical practice for the selected period, each possible billing error corresponding to an associated billing event; executing said instructions on a computer system to perform an analysis of said first and second data; and investigating transactions surrounding each billing event to verify an existence or absence of a billing error pertaining thereto.

2. A method according to claim 1 wherein said executable instructions comprising an extraction, transaction and load (ETL) engine for pre-conditioning the first and second data prior to generating said exceptions list, thereby ensuring said first and second data is valid, verifiable and in a suitable format prior to said analysis.

3. A method according to claim 2 whereby said ETL engine includes scripts for verifying proper format of the first and second data and selectively transforming improperly formatted data into a proper format.

4. A method according to claim 1 whereby investigating transactions surrounding each billing event comprises, for each respective billing event: identifying the patient involved; identifying the date of service involved; and pulling relevant portions of the patient's chart.

5. A method according to claim 1 further comprising generating a report which includes, for each exception within the exceptions list: an analysis of why the respective billing event occurred; a rebilling recommendation; and imagery from the respective patient's medical record which supports said rebilling recommendation.

6. A method according to claim 5 further comprising associating an analysis code with circumstances surrounding each billing event for which existence of a billing error is verified, and including each said analysis code in said report.

7. A method according to claim 1 wherein each possible billing error within the exceptions list relates to a group of billing events consisting of: billing an incorrect quantity of units of an inventory item; recording an incorrect CPT or HCPCS billing code for a treatment, recording an incorrect NDC code for a treatment, billing the wrong patient for a drug, billing for drug waste, not billing for drug waste, recording an incorrect date of service for a treatment,recording an incorrect administration code for a treatment, failing to bill for a drug, billing for a drug which was not administered to a patient, and billing for a non-reimbursable drug.

8. A method according to claim 1 further comprising associating an analysis code with circumstances surrounding each billing event for which existence of a billing error is verified.

9. A method according to claim 1 further comprising compiling a list of analysis codes each corresponding to a detected set of circumstances within the medical practice which results in a verifiable billing error.

10. A method according to claim 1 wherein each inventory transaction has an associated National Drug Code (NDC code) and each billing transaction pertaining to a selected drug has an associated Healthcare Common Procedure Coding System (HCPCS) code, said executable instructions further operative to perform a first mapping between dosage of NDC codes in inventory and dosage of HCPCS codes in billing prior to analyzing the first and second data with a set of algorithms.

11. A method according to claim 10 whereby, for each drug identified in inventory, a preferred HCPCS code billing resolution sequence is identified, said executable instructions further operative to generate a possible billing error when an actual billing sequence for a selected event fails to adhere to said HCPCS billing resolution sequence.

12. A method according to claim 11 wherein said executable instructions are further operative to create a set of mapping tables within a database, each mapping table associating a set of NDC codes with corresponding set of HCPCS codes, each HCPCS code within said HCPCS code set corresponding to an expected billing code resolution for the drug corresponding to said associated NDC code.

13. A method according to claim 10 wherein said executable instructions are further operative to perform a second mapping between patient-related information in said first data and patient-related information in said second data.

14. A method according to claim 13 whereby said patient related information is selected from a group of patent-related data consisting of patient name, date of birth, patient ID, system patient identifier, patient gender, and patient date of service.

15. A method according to claim 10 wherein said executable instructions are further operative, for each date of service and for each patient, to logically group the first and second data by the drug ID corresponding to each drug administered to the patient.

16. A method according to claim 15 wherein said executable instructions are further operative to ascertain, for each drug which according to its associated NDC code can only be administered to a single patient regardless of quantity used, whether an entire vial of the respective drug was unbilled, and to generate an exception for each such determination.

17. A method according to claim 15 wherein said executable instructions are further operative to ascertain, for each respective patient, an existence of unmatched records in the first and second data.

18. A method according to claim 11 whereby, for each patient, for each day and for each drug, said executable instructions are further operative to determine if an actual billing sequence in the second data deviates from the preferred HCPCS code billing resolution sequence, thereby to generate a possible billing error with respect to each such deviation.

19. A method according to claim 1 whereby analyzing the data further comprises executing a set of algorithms against the first and second data to identify possible billing errors.

20. A method according to claim 19 whereby at least one of said algorithms identifies, with respect to each HCPCS code in the historical billing transactions, a possible billing error when the number of occurrences for a particular quantity billed during the selected period falls beyond upper and lower outlier limits.

21. A method according to claim 19 whereby at least one of said algorithms analyzes quantities historically billed over the selected period for a given patent and for a given drug to ascertain any anomalies in billing activity and identify a possible billing error with respect to each such anomaly.

22. A method according to claim 19 whereby at least one of said algorithms identifies a possible billing error for each anomaly in a patient's treatment pattern.

23. A system, comprising: an inventory data retrieval component for receiving first data corresponding to historical inventory transactions within a medical practice for a selected period; a billing data retrieval component for receiving second data corresponding to historical billing transactions within the medical practice for the selected period; a database component for storing said first and second data in a database; a data conditioning and analysis component interfaced with said inventory and billing data retrieval components, said data conditioning and analysis component analyzing selected records from said first and second data to generate an exceptions list of possible billing errors within the medical practice during the selected period, wherein each possible billing error corresponds to one or more associated billing events; and a reporting component for producing an output report that identifies each verifiable billing error.

24. The system according to claim 23 wherein said output report includes, with respect to each verifiable billing error: an analysis of why the respective billing event(s) occurred; a rebilling recommendation; and imagery from the respective patient's medical record which supports said rebilling recommendation.

25. The system according to claim 24 wherein said output report further includes an analysis code corresponding to the circumstances surrounding each verifiable billing error.

26. The system according to claim 23 wherein said data conditioning and analysis component maps dosage of NDC codes in inventory to dosage of HCPCS codes in billing, and stores at least a first mapping table corresponding thereto in said database.

27. The system according to claim 26 wherein said data conditioning and analysis component further maps patient-related information in said first data to patient-related information in said second data, and stores at least a second mapping table corresponding thereto in said database.

28. The system according to claim 26 wherein said data conditioning and analysis component includes an algorithm for determining, with respect to each drug administered to a given patient on a given day, whether the billing sequence in the second data deviates from a preferred HCPCS code billing resolution sequence, thereby to generate a possible billing error with respect to each such deviation.

29. The system according to claim 26 wherein said data conditioning and analysis component includes an algorithm which, for each drug which according to its associated NDC code can only be administered to a single patient regardless of quantity used, generating an exception upon determining that less than an entire vial was billed.

30. The system according to claim 26 wherein said data conditioning and analysis component ascertains, for each respective patient, an existence of unmatched records in the first and second data.