CA2482370A1

CA2482370A1 - Systems, methods and computer program products for obtaining a best available reimbursement price in a pharmaceutical prescription transaction

Info

Publication number: CA2482370A1
Application number: CA002482370A
Authority: CA
Inventors: Kenneth Wayne Hunt
Original assignee: NDCHealth Corp
Current assignee: McKesson Canada Corp
Priority date: 2004-09-23
Filing date: 2004-09-23
Publication date: 2006-03-23
Anticipated expiration: 2024-09-23
Also published as: CA2482370C

Abstract

Systems, methods and computer program products enable pharmacies and other healthcare providers to obtain the best available reimbursement price for filling pharmaceutical prescriptions. The present invention provides for the tracking of reimbursement transaction data, which is utilized to derive a best available price for pharmaceutical prescriptions. One way of determining the best available price is to compare the requested reimbursement unit value to the best unit cost (BUC). The BUC represents the highest price paid by an insurance carrier or group of insurance carriers in a similar transaction, typically qualified by provincial location, drug and insurance carrier, and/or third party processor. The BUC values are utilized to determine if the reimbursement amount requested should be sent back for modification, flagged for a warning message to be sent to the pharmacy after the request has been submitted to the insurance carrier or third party processor, increased to more closely approximate the BUC, or submitted as is. The requested reimbursement amount is then modified accordingly and then sent to the insurance carrier or third party processor for payment. The response from the insurance carrier or third party processor is processed for capture of certain data that may be used to update the BUC values before being sent to the submitting pharmacy or other healthcare provider.

Description

SYSTEMS, METHODS AND COMPUTER PROGRAM
PRODUCTS FOR OBTAINING A BEST AVAILABLE REIMBURSEMENT PRICE IN
A PHARMACEUTICAL PRESCRIPTION TRANSACTION
TECHNICAL FIELD
The present invention relates generally to the electronic processing of reimbursement claims in connection with the fulfillment of a prescription.
BACKGROUND OF THE INVENTION
In many markets, including the Canadian pharmaceutical market, the reimbursement amount requested in a significant percentage of reimbursement claims submitted by pharmacists and other healthcare providers to insurance carriers are not specified in a contractual agreement.
Currently, a pharmacy seeking reimbursement from an insurance carrier submits a claim the amount of which is set by that pharmacy's pricing guidelines. The insurance carrier or third party claim processor then decides whether or not to pay that claim in full, deny the claim, or pay the claim in part. However, in many instances, the insurance carrier or third party processor has some discretion as to the extent the claim will be reimbursed. As a result, what one insurance carrier reimburses one pharmacy for filling a prescription of a particular drug can be more or less than that for a different pharmacy who filled an identical prescription within minutes of the other pharmacy. Too often this can lead to reimbursement claims being undervalued with no means of providing an objective check for the pharmacists to be sure they are maximizing their potential reimbursement of the cost of filling a prescription.
Efforts have been made to help make the reimbursement process less of a guessing game for pharmacists and other healthcare providers, as they constantly reevaluate the prices for their goods and services. As one example, special software has been developed to screen reimbursement claim submissions against a database of drugs and those drugs' corresponding unit prices for reimbursement from government assistance programs. However, even With such software, the pharmaceutical reimbursement process still has pricing and processing problems from the perspective of the pharmacy, especially when dealing with private insurance carriers.
These problems include the use of outdated drug pricing information as well as allowing too much discretion on the part of insurance carriers or third party processors due to the ad hoc nature of the reimbursement process. Consequently, the existing pharmacy decision support and practice management systems do not adequately protect pharmacists and other healthcare providers against undervalued reimbursement claims.
Thus, there is an unsatisfied need in the industry to enhance the ability of pharmacies and healthcare providers to obtain the best available reimbursement price in a pharmaceutical prescription transaction.
SUMMARY OF THE INVENTION
Systems, methods and computer program products of the present invention enable pharmacies and other healthcare providers to obtain the best available reimbursement price for filling pharmaceutical prescriptions. The present invention provides for the tracking of reimbursement transaction data, which is utilized to derive a best available price. One way of determining the best available price is to utilize the reimbursement transaction data to compare the requested reimbursement unit value to the best unit cost (BUC). The BUC is a unit price derived from the highest price paid by an insurance carrier or group of carriers over a defined period of time, such as a day. Pharmacies and other healthcare providers utilize the BUC values to determine if the reimbursement amount they are requesting should be sent back for modification, flagged for a warning message to be sent to the pharmacy after the request has been submitted to the insurance carrier or third party processor, increased to more closely approximate the BUC, or submitted as is. If so, the requested reimbursement amount is modified accordingly and then sent to the insurance carrier or third party processor for payment.
The present invention largely eliminates the guessing game engaged by pharmacies when submitting reimbursement requests of not knowing if they are asking as much as they could in a reimbursement claim. The present invention ensures they are maximizing their potential reimbursement amount by comparing the amount requested to the BUC and adjusting the requested amount if appropriate before the reimbursement claim is sent to the insurance carrier or third party processor for payment. The response from the insurance carrier or third party processor is processed for capture of certain data that may be used to update the BUC before being sent to the submitting pharmacy or other healthcare provider.
A method for processing a prescription reimbursement claim that includes pricing data and payer data in accordance with an embodiment of the present invention comprises receiving a

2 prescription reimbursement claim, applying a pricing edit to the pricing data of the reimbursement claim to approximate a best available price for the reimbursement claim based at least in part on previously accepted reimbursement claims, sending the edited reimbursement claim to a payer identified by the payer data, receiving data from the payer representative of an accepted reimbursement claim amount, and updating the pricing edit based on the accepted reimbursement amount. According to one aspect of the present invention, the step of applying the pricing edit may include identifying a reference value based at least in part on the payer data.
The pricing edit may also include determining a unit cost of the prescription from the pricing data. The unit cost value may then be compared to the reference value that is associated with the payer.
In accordance with another aspect of the present invention, the step of applying the pricing edit may include modifying the pricing data of the prescription reimbursement claim to approximate the best available price paid by the payer within a predefined time interval. The pricing edit may include the step of normalizing the pricing data units to the reference value 1 S units.
In accordance with another aspect of the present invention, the method may further comprise updating the pricing edit includes determining if the accepted reimbursement claim amount represents a higher price than a reference value. Updating the pricing edit may include changing the reference value if the accepted reimbursement claim amount is higher than the reference value, and/or changing the reference value if the accepted reimbursement claim amount is lower than the reference value.
In accordance with another embodiment of the present invention, a computer-implemented system for processing a prescription reimbursement claim that includes pricing data and payer data comprises a pre-edit module that applies a pricing edit to the pricing data of the reimbursement claim to obtain a best available price for the reimbursement claim, and a post-edit module that receives data representative of an accepted reimbursement claim amount and updates the pricing edit based on the accepted reimbursement amount. The pre-edit module may comprise a plurality of sub-edit modules, each sub-edit module being a pricing edit. One of the plurality of sub-edit modules may include a fixed benefit pricing edit. In accordance with an aspect of the present invention, the pre-edit module can select at Least one sub-edit module to

3 apply based at least in part on the pricing data. The system may further comprise a database including a pricing table, wherein the pricing table includes best available price data.
In accordance with another embodiment of the present invention, a computer-readable medium storing computer-executable instructions for performing the steps of receiving a prescription reimbursement claim, applying a pricing edit to the pricing data of the reimbursement claim to approximate a best available price for the reimbursement claim based at least in part on previously accepted reimbursement claims, sending the edited reimbursement claim to a payer identified by the payer data, receiving data from the payer representative of an accepted reimbursement claim amount, and updating the pricing edit based on the accepted reimbursement amount. The computer-readable medium may further store computer-executable instructions for modifying the pricing data of the prescription reimbursement claim to approximate the best available price paid by the payer within a predefined time interval. In addition, the computer-readable medium may further store computer-executable instructions for determining a unit cost of the prescription from the pricing data when applying the pricing edit.
The computer-readable medium may further store computer-executable instructions for comparing the unit cost to a reference value that is associated with the payer.
BRIEF DESCRIPTION OF THE DRAWINGS
Having thus described the invention in general terms, reference will now be made to the accompanying drawings, which are not necessarily drawn to scale, and wherein:
FIG. 1 is a block diagram illustrating an exemplary system in accordance with certain exemplary embodiments of the present invention.
FIG. 2 is a block diagram illustrating an exemplary edit module in accordance with certain exemplary embodiments of the present invention.
FIG. 3 is a flow chart illustrating an exemplary pre-edit process in accordance with certain exemplary embodiments of the present invention.
FIG. 4 is a flow chart illustrating an exemplary best unit cost pricing sub-edit process in accordance with certain exemplary embodiments of the present invention.
FIG. 5A is a flow chart illustrating an exemplary post-edit price capture process in accordance with certain exemplary embodiments of the present invention.

4 FIG. 5B is a flow chart illustrating an exemplary post-edit best unit cost update process in accordance with certain exemplary embodiments of the present invention.
DETAILED DESCRIPTION OF THE INVENTION
The present inventions now will be described more fully hereinafter with reference to the accompanying drawings, in which some, but not all embodiments of the invention are shown.
Indeed, these inventions may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided so that this disclosure will satisfy applicable legal requirements.
The present invention provides systems and methods for prescription reimbursement processing intended to provide pharmacies and other healthcare providers with the best available reimbursement price. The systems and methods of the present invention process prescription reimbursement transactions through screening processes often referred to as edits to determine if the requested reimbursement reflects the best available price for that particular transaction at that particular time before the transaction is submitted to the insurance carrier (or a third party processor, referred to by a Bank Identificatian Number or BIN, administering claims on behalf of one or more insurance Garners). After the submission. to the BIN, the present invention captures the appropriate transaction data for processing updates and analysis, and sends appropriate messages to pharmacists or other healthcare providers providing recommendations for use in preparing future reimbursement claim submissions (e.g., the claim was accepted, rejected in full, rejected in part, substituted for an alternative amount, too low, etc.). The invention provides flexibility for activating and deactivating certain edits, and for setting and adjusting various parameter settings to determine which messages are returned to the pharmacist or other healthcare provider and the content of those messages.
Exemplary embodiments of the present invention will hereinafter be described with reference to the figures, in which like numerals indicate like elements throughout the several drawings. FIG. 1 is a block diagram illustrating an exemplary operating environment for implementation of certain embodiments of the present invention. The exemplary operating environment encompasses a pharmacy point-of service (POS) device 102, a host server 104 and payer systems 108, which are each configured for accessing and reading associated computer-readable media having stored thereon data and/or computer-executable instructions for

5 implementing the various methods of the present invention. Generally, network devices and systems include hardware and/or software for transmitting and receiving data and/or computer-executable instructions over a communications link and a memory for storing data and/or computer-executable instructions. Network devices and systems may also include a processor for processing data and executing computer-executable instructions, as well as other internal and peripheral components that are well known in the art. As used herein, the term computer-readable medium describes any form of memory or a propagated signal transmission medium.
Propagated signals representing data and computer-executable instructions are transferred between network devices and systems.
As shown in FIG. 1, a pharmacy POS device 102 rnay be in communication with the host server 104 via a network 106. The pharmacy POS device 102 may be configured for receiving prescription claim data, creating prescription transactions there from and transmitting said prescription transactions to the host server 1.04. Prescription claim data includes any data that is typically provided by a patient, pharmacist and/or other healthcare provider in relation to filling a prescription and/or requesting approval or authorization for payment from a payer 216 or claim adjudicator. A payer 216 may be an insurance company, a financial institution or another financial service provider. Prescription claim data may be input to the pharmacy POS device 102 by a pharmacist or other healthcare provider or may be received by the pharmacy POS
device 102 in electronic form from an electronic prescription service (not shown). The pharmacy POS device 102 may be configured for handling other types of prescription transactions.
Prescription transactions are electronic records or messages intended to facilitate the communication of prescription information. For example, prescription claim transactions are intended to communicate prescription claim data between pharmacies and payers 216. Although prescription claim transactions will be discussed hereinafter, it should be understood that the various systems and method of the invention may be practiced in connection with other types of prescription transactions or independently of prescription transactions (e.g., raw prescription data). The content and format of a prescription claim may vary depending on which standard or protocol is used. In general, however, prescription claim transactions will identify at least the drug product to be dispensed (e.g., by a drug identification number, also referred to as DIN), the

6 quantity to be dispensed and the days supply, whether the prescription claim relates to a new prescription or a refill prescription and billing-related information.
Prescription claim transactions may be transmitted from the pharmacy POS
device 102 to the host server 104 in batch, real-time or near real-time. In certaiil embodiments, the host server 104 may serve as a clearinghouse for multiple payer systems 108. Payer systems 108 may include systems operated on behalf of insurance companies, financial institutions and other financial service providers. In its capacity as a clearinghouse, the host server 1.04 parses prescription claim transactions and forwards them to the appropriate payer system 108 for processing. Approval, authorization or rejection messages may be returned to the host server I O 104 from the payer systems 108 and such messages may be forwarded by the host server 104 to the pharmacy POS device 102.
In serving as a clearinghouse, the host server 104 may also be configured for performing pre-processing and post-processing of prescription claim transactions. Pre-processing and post-processing refers to real-time or near real-time validation and management of prescription claim data to aid in maximizing prescription claim reimbursement and minimize claim submission errors. Pre-processing and post-processing may generate messaging alerts and/or retrospective reports supporting usual and customary price comparisons, and numerous other edits for facilitating rapid and accurate validation of prescription claims.
In accordance with the present invention, the host server 104 may be configured for performing various edits including pricing edits. Pricing edits are the screening processes that monitor whether the best available reimbursement price is being submitted to the payer system 108. An individual price screening process can be referred to as a sub-edit.
In the case where the host server 104 functions as a clearinghouse, the pricing edits may be implemented as pre processing and/or post-processing edits. In other embodiments, the host server 104 may not serve as a clearinghouse for prescription claim transactions and may be dedicated to performing such tasks as edits. The edits of the present invention may be designed to generate alerts (including reject messages) that are transmitted to the pharmacy POS device 102 when a potentially undervalued or overvalued reimbursement claim is detected. Reject messages may indicate that a prescription claim has been rejected, provide a pharmacist with information about the potential best available price and/or may encourage the pharmacist to verify the prescription

7 claim data. The edits are also designed to capture certain prescription claim data for subsequent analysis and reporting related to future edits.
The pharmacy POS device 102 may be any processor-driven device, such as a personal computer, laptop computer, handheld computer and the like. In addition to a processor 110, the pharmacy POS device 102 may further include a memory 112, input/output (I/O) interfaces) 114 and a network interface 116. The memory 112 may store data files 118 and various program modules, such as an operating system (OS) 120 and a practice management module 122. The practice management module 122 may comprise or interface with computer-executable instructions for performing various routines, such as those for creating and submitting prescription claim transactions. For purposes of the present disclosure, the prescription writing functionality is assumed to be incorporated in the practice management module 122, though one of ordinary skill in the art will appreciate that a separate program operating alone or in association with the practice management module 122 may provide the prescription creation and submission functionality discussed herein. IIO interfaces) 114 facilitate communication between the processor 110 and various I/O devices, such as a keyboard, mouse, printer, microphone, speaker, monitor, etc. The network interface 116 may take any of a number of forms, such as a nehvork interface card, a modem, etc. These and other components of the pharmacy POS device 102 will be apparent to those of ordinary skill in the art and are therefore not discussed in more detail herein. Those of ordinary skill in the art can appreciate that certain embodiments of the present invention discussed below can also be implemented at a pharmacy's headquarters with terminals in the individual chain stores, through a server providing functionality to a group of pharmacies, or through means other than a pharmacy POS device 102.
Similarly, the host server 104 may be any processor-driven device that is configured for receiving and fulfilling requests related to prescription claim transactions.
The host server 104 may therefore include a processor 12C, a memory 128, inputloutput (I/O) interfaces) 130 and a network interface 132. The memory 128 may store data files 134 and various program modules, such as an operating system (OS) 136, a database management system (DBMS) 138 and an edit module 140. The edit module 140 may comprise computer-executable instructions for performing various edit functions and for managing related messaging and reporting functions.
The host server 104 may include additional program modules (not shown) for performing other pre-processing or post-processing edits and for providing clearinghouse services. Those of

8 ordinary skill in the art will appreciate that the host server 104 may include alternate and/or additional components, hardware or software. In addition, the host server 104 may be connected to a local or wide area network (not shown) that includes other devices, such as routers, firewalls, gateways, etc.
The host server 104 may include or be in communication with one or more database 105.
The database 105 may store various parameters, counters, tables a.nd other data used in the various edits of the present invention. The database 105 may also store reports, averages, and other data relating to the results of the edit. The database 105 may also store any other data used or generated by the host server 104, such as data used in other pre-processing and post-processing edits and reports generated thereby. Although a single database 105 is referred to herein for simplicity, those of ordinary skill in the art will appreciate that multiple physical and/or logical databases may be used to store the above mentioned data. For security, the host server 104 may have a dedicated connection to the database 105, as shown.
However, the host server 104 may also communicate with the database 105 via a network 106.
The network 106 may comprise any telecommunication an.d/or data network, whether public or private, such as a local area network, a wide area network, an intranet, an Internet and/or any combination thereof and may be wired and/or wireless. Due to network connectivity, various methodologies as described herein may be practiced in the context of distributed computing environments. Although the exemplary pharmacy POS device 102 is shown for simplicity as being in communication with the host server 104 via one intervening network 106, it is to be understood that any other network configuration is possible. For example, the pharmacy POS device 102 may be connected to a pharmacy's local or wide area network, which may include other devices, such as gateways and routers, for interfacing with another public or private network 106. Instead of or in addition to a network 106, dedicated communication links may be used to connect the various devices of the present invention. Further, one of ordinary skill in the art will appreciate that the network 106 can operate as a switching station that routes reimbursement claims from subscribers to the various edit screening processes to which they have subscribed and routing others (e.g., non-subscribers) directly to the payer systems 108.
Those with ordinary skill in the art will appreciate that the operating environment shown in and described with respect to FIG. 1 is provided by way of example only.
Numerous other operating environments, system architectures, and device configurations are possible. For

9 example, the invention may in certain embodiments be implemented in a non-networked environment, in which a stand-alone pharmacy POS device 102 executes one or more edit modules) 140. Accordingly, the present invention should not be construed as being limited to any particular operating environment, system architecture or device configuration.
FIG. 2 is a block diagram illustrating an exemplary edit module 140 in accordance with certain exemplary embodiments of the present invention. The exemplary operating environment of the edit module 140 encompasses a pre-edit 204 and a post-edit 212. As shown in FIG. 2, the pharmacist or other healthcare provider (i.e., the payee 202) enters prescription claim data, the content and format of which may vary depending on which standard or protocol is used, into the pharmacy POS device 102. In general, prescription claim transaction data will identify at least the drug product to be dispensed (e.g., by the DIN), the quantity to be dispensed and the days supply, whether the prescription claim relates to a new prescription or a refill prescription and billing-related information (including its customer's insurance carrier and requested reimbursement amount for filling that prescription). The pharmacy POS device 102 then sends the transaction data over the network 106 to the host server 104 where the transaction data is then processed by the pre-edit 204 of the edit module 140.
The pre-edit 204 processes the transaction data in accordance with the present invention to check that the payee 202 is maximizing its reimbursement before sending that claim to the insurance carrier or BIN (i.e., the payer 216). The Best Unit Cost (BUC) pricing sub-edit 206, cost to operator (CTO) pricing sub-edit 208, and fixed benefit pricing sub-edit 210 are examples of pricing sub-edits that assist the payee 202 in maximizing its reimbursement.
In accordance with certain exemplary embodiments of the present invention, the BUC
pricing sub-edit 206 is invoked whenever the reimbursement claim falls outside the scope of a provincial formulary. A provincial formulary is a government issued list of drugs with a defined unit price that the government will reimburse pharmacies. However, one of ordinary skill in the art can appreciate that the BUC pricing sub-edit could be invoked independent of the scope of the provincial formulary. The BUC pricing sub-edit compares the per unit drug price (e.g., price per pill or price per package) of tlqe submitted claim to a best unit price previously received for similar transactions. Action taken in response to the comparison aids the payee 202 in receiving the best available reimbursement price. The BUC pricing sub-edit will be discussed in further detail below.

The CTO pricing sub-edit 208 is invoked when the reimbursement claim submitted is listed on the provincial formulary, but the payee's replacement cost is higher than allotted on the provincial formulary. In that case, the reimbursement claim amount submitted is the replacement cost, and not the allotted amount on the provincial forrnulary.
The claim is then submitted to the payer 216 for reimbursement. The fixed benefit pricing sub-edit 210 is invoked when the reimbursement claim submitted is less than that allotted on the provincial formulary.
In this scenario, the price listed on the provincial formulary will be used to complete the reimbursement claim. The CTO and fixed benefit pricing sub-edits 208 and 210 may not be utilized in all embodiments of the present invention, but are included as exemplary of the various sub-edits that may be combined with the BUC pricing sub-edit 206 in accordance with the present invention. Therefore, the processes of the CTO and fixed benefit pricing sub-edits 208 and 210 will not be discussed in further detail.
Once the reimbursement claim has been processed by the applicable sub-edit modules) and has been transmitted to the specified payer 216 the claim is then processed by the payer 216 and either granted, denied in full, or denied in part. A response indicating whether the claim is granted, denied in full or denied in part is sent back to the payee 202 through the host server 104.
At the host server 104, the post-edits) 212 process the response, where it is preferred that at least part of the response data is compiled to monitor the best accepted price for both a particular insurance corner and BIN during a particular time interval, which is then used to update the appropriate database 105 for transactions in subsequent time intervals.
FIG. 3 is a flow chart illustrating an exemplary pre-edit 204 process in accordance with certain exemplary embodiments of the present invention. When the transaction data is received by the edit module 140 it is sent to the pre-edit 204. The pre-edit 204 links the transaction data to the insurance carrier's particular network, normalizes the reimbursement claim value to a per unit value, and selects which of several pricing and/or non-pricing sub-edits to execute (e.g., the BUC pricing sub-edit 206, CTO pricing sub-edit 208, or fixed benefit pricing sub-edit 210).
Beginning at step 302, the transaction is linked to a specific pricing group, sponsor and location utilizing the BIN and DIN information provided in the transaction data, both of which are used to identify where the transaction will be routed. In accordance with certain exemplary embodiments of the present invention, this can be done numerous ways including the utilization of a pricing group table, sponsor table, location table, and a pharmacy ID
table stored in the database 105. A price group table is a table of BUC values which are the current best available reimbursement prices accepted for a particular carrier/BIN and DIN
combination, though the BUC values can be provided according to other criteria such as BIN and DIN
alone. The pricing group tables store BUC values as well as various parameters and sponsor edit preferences (discussed below) for a sponsor (i.e., pharmacy chain or groups of pharmacies) that subscribe to the edit system service and have agreed to pool their data. A sponsor table lists pharmacy chains. A location table lists all specific pharmacy locations within a particular subscribing chain, and a pharmacy ID table lists all the BIN numbers associated with a particular pharmacy location.
At step 304 the reimbursement claim value provided in the transaction data is normalized to a transaction unit cost (TUC) value. In accordance with certain exemplary embodiments of the present invention before normalization can occur, the transaction data must be checked to see if a professional fee was entered separately from the price of the prescription submitted for reimbursement. If there was no professional fee entered in the transaction data as a separate data item, then a customary professional fee associated with that particular location will be assumed, and the cost submitted will be reduced by the assumed amount before the TUC
value is determined. Next, in accordance with certain exemplary embodiments of the present invention, the TUC value is calculated using the following formula:
TUC = (Submitted Cost + Submitted Cost Up-charge) / Submitted Quantity.
If the result is a negative (likely because a professional fee was incorrectly assumed) then the TUC value is set to zero, which will likely be rejected and sent back to the payee 202 for corrective action.
Step 306 links the specific sponsor's edit preferences, which are known as the sponsor pricing parameters, to the transaction data. These parameters include various qualifiers, percent qualifiers, threshold values, counters, etc., are all utilized in the various sub-edit and post-edit processes discussed in further detail below. The description and use of the parameters discussed in the illustrative embodiment are discussed below.
In general, these parameters are arbitrary values that are adjustable to alter the performance of the edit system, its sub-edits and/or post-edit functions. The parameter settings are setup, updated and/or overseen by a system administrator(s). The system administrators) can be a member of the sponsor's staff, the host's staff, an independent part, or any combination of people with appropriate authorization and access to the system. After sufficient adjustments have been made over time, these parameters can become set and yield expected outcomes for particular reimbursement claims submitted by a particular payee 202.
Therefore, the parameters determine how the sub-edits and/or post-edit will function. Those of ordinary skill in the art will appreciate that the numerous combinations of parameter values can change the outcomes in the sub-edits andlor post-edit functions which in turn, change the outcome of the entire system for two otherwise identical claim submissions.
As an illustrative example, transactions A and B are identical reimbursement claim submissions except their specified parameters are different in that transaction A's parameters used in determining if a submitted claim value should be substituted for a greater value before being sent to the payer 210 are set so that the percentage increase of the submitted value is done in larger increments than those done in transaction B. In this scenario, transaction A has the possibility that the payer 210 would reimburse the claim at a higher price, than the claim in transaction B. On the other hand, the substituted value in transaction A may have been incremented in too large a step as to overshoot the best available reimbursement price. In that case, transaction B could be reimbursed in full by the payer 210, while transaction A would likely be partially reimbursed, receiving a lower value than originally requested.
In accordance with certain exemplary embodiments of the present invention, the parameters can be stored in the pricing table or other locations in the database 105 prior to a claim submission. The parameters that affect a particular payee 202 can be stored in various combinations, allowing the system to be customized in a variety of different ways. For example, the parameter settings can be customized for types of transactions, individual pharmacies, groups of pharmacies, groups of transactions as well as other various combinations that one of ordinary skill in the art will appreciate.
Step 308, which can be enabled or disabled by the payee 202, checks to see if the drug provided in the transaction data satisfy the government formulary pricing criteria. A provincial formulary is a government issued list of drugs with a defined unit price that the government will reimburse pharmacies. To satisfy the government formulary criteria, the drug with a defined unit price must be listed on the provincial formulary as qualifying for at least partial reimbursement by the government on the date of the prescription was filled.
If the drug is not listed on the formulary or does not qualify for reimbursement on the formulary, the manipulated transaction data is sent to the BUC pricing sub-edit 206 for further processing, as discussed below. If other sub-edits are enabled and the drug is listed on the provincial formulary and qualifies for government reimbursement, then step 3I2 is invoked.
Step 312 determines if the TUC value should be subjected to pricing sub-edits other than the BUC pricing sub-edit, such as CTO pricing, fixed benefit pricing and/or various other pricing or non-pricing related sub-edits, as indicated by step 314. In accordance with certain exemplary embodiments of the present invention, examples of non-pricing sub-edits would be sub-edits that provide a check that the pharmacist entered the type of drug the sponsor would prefer to sell, etc.
Those of ordinary skill in the art will appreciate the numerous combination of edits and sub-edits could be utilized to perform a variety of checks and adjustments to the claim transaction data before and after it has been submitted to the payer 216.
FIG. 4 is a flow chart illustrating an exemplary BUC pricing sub-edit process in accordance with certain exemplary embodiments of the present invention. In accordance with this embodiment of the present invention, the BUC pricing sub-edit 206 is one of a plurality of potential sub-edits that can be enabled by the payee 202 to be performed in the pre-edit 204 of the edit module 202. The BUC pricing sub-edit is a screening process for determining the maximum reimbursement a pharmaceutical payee 202 would likely receive from an insurance payer 216 at a particular time based on historical data of prices previously approved by the designated payer 216. The BUC pricing sub-edit compares the per unit drug price (e.g., price per pill or price per package) of the submitted claim to a best unit price previously received for similar transactions. The action taken in response to this per unit comparison aids the payee 202 in receiving the best available reimbursement price. The pricing group table stored in the database 105 provides the BUC values that are used to compare the culxent transaction with what has been previously accepted.
As shown in FIG. 4, steps 402, 406, 408 determine in sequence if the transaction data from the payee 202 has a previous BUC value in the pricing table in the form of one of a BUC
override, carrier BUC or BIN BUC in preferential order. The BUC override value is a BUC
value specified according to a specific sponsor preference designated by the payee 202 or system administrator to be use instead of the carrier BUC or BIN BUC values. The carrier BUC value is the previous time interval's best accepted transaction price for that particular carrier. The B1N
BUC value is the previous time interval's best accepted transaction price for that particular BIN.
One of ordinary skill in the art will appreciate that other BUC values could be stored in the pricing table and various orders of preferences could be specified as to which BUC value is preferred to use for the price comparison processes described below. If an appropriate BUC
value is found in the pricing table, then the BUC value is set to that value in corresponding steps 404, 408 or 412. If not, then the BUC pricing sub-edit 206 is abandoned and step 426 is invoked to complete the sub-edit. Consequently, the payee's 202 entered claim will be submitted to the payer system 108 unchanged.
If a BUC value for a particular transaction is located in one of steps 404, 408 or 4L2, then step 414 determines an appropriate BUC action. Step 416 then compares the TUC
value to the BUC value. If the TUC value is greater than or equal to the BUC value then the process is complete, and step 426 is invoked to complete the sub-edit. Otherwise the major and minor BUC action criteria are checked (if both are enabled by the payee 202). Both the major and minor BUC actions determine what appropriate action should be taken with regards to the current TUC value (e.g., reject the current TUC, substitute and submit a different TUC value, or capture and submit the current value, etc.), The major BUC action 420 suggests large changes, if any, to the TUC value to get closer to the compared BUC value. Whereas, the minor BUC
action 424 suggests smaller changes, if any, to get the TUC value closer to the BUC value.
Those with ordinary skill in the art will appreciate that there may be fewer or more BUC actions, each one with a different effect on the TUC value, for it to more accurately reflect the BUC
value. Those of ordinary skill in the art will appreciate that multiple BUC
actions can be applied to modify the TUC value in a variety of different preferential orders.
If the major BUC action 420 is enabled, then step 418 checks to see if the cost difference (i.e., the value between the TUC value and the BUC value meets the major BUC
criteria, which in this exemplary embodiment has two requirements, though one of ordinary skill in the art will appreciate numerous mathematical criteria that could be required. First, the absolute value of the cost difference should be greater than the major absolute difference qualifier. The major absolute difference qualifier is a predetermined parameter value arbitrarily set and adjustable by the payee 202 or system administrator or stored as a sponsor preference in the database 105. The second criteria is as follows:
Cost Difference / (Transaction Quantity x TUC) > Major % Difference Qualifier.
The major percent (%) difference qualifier is also a predetermined parameter value arbitrarily set and adjustable by the payee 202 or system administrator and stored as a sponsor preference in the database 105. If those two criteria are met, then step 420 is invoked and the major BUC action is performed after which the edit process will complete by invoking step 426. The major BUC
action of step 420 preferably performs one or more of the following functions based on the edit results. These functions include: reject the order and send a message back to the payee 202 instructing them to adjust the entries in some way; automatically substitute the requested reimbursement amount with a more appropriate value and submit the order to the specified insurance payer's system 108; capture the submitted information and send it to the specified insurance payer's system 108 unchanged; or capture the submitted information and send it to the specified insurance payer's system 108 unchanged and flag the transaction for the post-edit 212 to attach a warning message to be displayed to the payee 202 after the information submitted has been sent back from the specified insurance payer's system 108.
With regards to performing these major BUC action functions, the major BUC
action's 420 determination of when to reject, when to submit a claim unchanged, when to flag the transaction for a warning message, or when to invoke a substitution and what value to substitute utilizes the parameters defined by the payee 202 or system administrator. One of ordinary skill in the art will appreciate that in determining when to perform any of the major BUC action's functions, the parameter values can be utilized in a variety of ways with varying complexity, including comparing the set parameter values to calculated values (such as the cost difference between the TUC and BUC values), or processing the parameter values through numerous mathematical criteria to determine the appropriate action to take.
For example, to determine when to substitute a TUC value .for a higher value, stored or pre-set parameter values could be utilized to increase a TUC value by a certain percentage (defined by the entered parameters) of itself when the cost difference is greater than a certain amount (also defined by the entered parameters). With the payee 202 setting the parameter values, the payee can customize the pf;rformance of the major BUC action 420 (e.g., vary the criteria for when a reject is to be performed, vary the amount substituted when a substitute is performed, etc.) to achieve the overall system performance desired.
If the criteria requirements in step 418 are not met and the minor BUC action 424 is enabled, then step 422 will be invoked. Step 422 also has two criteria, though one of ordinary skill in the art will appreciate numerous mathematical criteria that could be required. The first criteria is that the absolute value of the cost difference should be greater than the minor absolute difference qualifier. The minor absolute difference qualifier is a predetermined parameter value arbitrarily set and adjustable by the payee 202 or system administrator or stored as a sponsor preference in the database 105. The second criteria is as follows:
Cost Difference/ (Transaction Quantity x TUC) > Minor % Difference Qualifier.
The minor percent (%) difference qualifier is a parameter value arbitrarily set and adjustable by the payee 202 or system administrator and stored as a sponsor preference in the database 105. If these two criteria are met then step 424 is invoked and the minor BUC action 424 is performed after which the edit process will complete by invoking step 426. Pas in the major BUC action 420, the minor BUC action 424 preferably performs one or more of the following functions based on the edit results. These functions include: reject the order and send a message back to the payee 202 instructing them to adjust the entries in some way;
automatically substitute the requested reimbursement amount with a more appropriate and submit the order to the specified insurance payer's system 108; capture the submitted information and send it to the specified insurance payer's system 108 unchanged; or capture the submitted information and send it to the specified insurance payer's system 108 unchanged and flag the transaction for the post-edit 212 to attach a warning message to be displayed to the payee 202 after the information submitted has been sent back from the specified insurance payer's system 108.
With regards to performing these minor BUC action functions, the minor BUC
action's 424 determination of when to reject, when to submit a claim unchanged, when to flag the transaction for a warning message, or when to invoke a substitution and what value to substitute utilizes the parameters defined by the payee 202 or system administrator. One of ordinary skill in the art will appreciate that in determining when to perform any of the minor BUC action's functions, the parameter values can be utilized in a variety of ways with varying complexity, including comparing the set parameter values to calculated values (such as the cost difference between the TUC and BUC values), or processing the parameter values through numerous mathematical criteria to determine the appropriate action to take.
For example, to determine when to substitute a TUC value for a higher value, stored or pre-set parameter values could be utilized to increase a TUC value by a certain percentage (defined by the entered parameters) of itself when the cost difference is greater than a certain amount (also defined by the entered parameters). With the payee 202 setting the parameter values, the payee can customize the performance of the minor BUC action 424 (e.g., vary the criteria for when a reject is to be performed, vary the amount substituted when a substitute is performed, etc.) to achieve the overall system performance desired.
If neither sets of criteria in steps 418 or 422 are met or enabled, then step 426 will be invoked and the sub-edit will complete, and either another sub-edit could begin or the transaction data could be submitted to the payer 216. Once the information has been submitted to the specified insurance payer's system 108 and the claim has been granted, denied in full, or denied in part, that data is sent back to the payee 202 through the post-edit 212.
FIG. 5A and FIG. 5B are both flow charts illustrating exemplary post-edit price capture and post-edit BUC update processes, respectively. The processes displayed in these charts and outlined below show how the data sent back from the payer system 108 (including the accepted or rejected reimbursement claim amount) is processed in the post-edit 212 utilizing sponsor specified parameters, the results from the pre-edit 204 and other transaction data. Specifically, the price capture process of FIG. 5A demonstrates how the post-edit captures (i.e., records) the per unit cost value the payer 216 reimbursed and determines whether or not it is the best per unit cost value accepted by the payer 2I6 for that particular time interval. The BUC update process of FIG. 5B demonstrates how the best per unit cost value accepted by the payer 216 for that particular time interval, as identified by the price capture process of FIG.
5A, is utilized to update the various BUC values to be used for comparisons to future similar reimbursement claim submissions.
FIG. 5A is a flow chart illustrating an exemplary post-edit price capture process in accordance with certain exemplary embodiments of the present invention. In the post-edit 212, the transaction information is recorded for comparison and updating the current table values used by the pre-edit 204: These recorded values are compiled to monitor the best accepted price for a particular insurance carrier on a particular day, which is then used to update the tables for the subsequent day's transactions. While the embodiment disclosed herein calculates the BUC
values on a daily basis for use the following day, the BUC can be based on transaction data from multiple days and can be updated at intervals other than daily, such as hourly, weekly or in real time. According to FIG. 5A, step S04 links the transaction to specific pricing group, sponsor and location tables utilizing the BIN, DIN information, and other transaction data. This can be done numerous ways including the use of a database 105 which contains the pricing group table, sponsor table, location table and the pharmacy ID table.
Step 506 adjusts the transaction data's accepted reimbursement claim value to derive an accepted TUC value. In accordance with certain exemplary embodiments of the present invention, if there was no professional fee entered in the transaction data as a separate data item, then a customary professional fee associated with that particular location will be assumed, and the cost submitted will be reduced by the assumed amount before tl~e accepted TUC value can be determined. Next, step 508 determines whether the transaction is a valid transaction to capture (e.g., transactions with an accepted TUC value of zero are not captured). If the transaction is not valid for capture, then step 510 is invoked which abandons the current transaction and proceeds to step 502 to wait for the next transaction to reach the post-edit 212. If after a specified time interval no new transactions are received, then step 538 updates the BUC
values from the previous time interval, as discussed in more detail below in the BUC update process.
If the transaction is suitable for capture, then step 512 checks to see if the price had been reduced due to the days supply or quantity maximums. These reductions are due to the claimed prescription exceeding a limit on the quantity of a prescription allowed for full reimbursement (e.g., the insurance will only pay for a one month supply and the prescription is for a two month period) This results in the payee 202 only being reimbursed up to a certain amount of the prescription and not the whole amount originally submitted into the system. In that situation, the accepted price is not an accurate reflection of the limit of what the payer 216 would pay for the full claim amount. Although one of ordinary skill in the art will appreciate ways to incorporate factors like these into the unit cost calculation process. If the accepted price was reduced because of those factors, then the transaction is not captured and step 510 is invoked to wait for the next transaction. If it was not reduced because of those factors, then step 514 calculates the accepted TUC.

Once the accepted TUC value has been calculated then both the BIN BUC and carrier BUC must be compared to see if either needs updating. To do this.. step 516 retrieves the BIN
BUC value. The BIN BUC value is the previous time interval's best accepted (i.e., reimbursed) transaction price for that particular BI7V. Step 518 compares to the accepted TUC value to the BIN BUC value. If this transaction was accepted at the price that it was submitted (or higher) and it is priced lower than the BIN BUC, then this transaction will not be used to update the BIN
BUC value because it is possible the pharmacy could receive a higher price. If that is the case, then step 534 will retrieve the carrier BUC. The carrier BUC which is the previous time interval's best accepted transaction price for that particular carrier, and proceed to the carrier BUC capture process in step 535 discussed below. However, if the transaction was accepted at a price greater than the BIN BUC value then step 520 is invoked.
Step 520 makes sure the accepted TUC value meets certain absolute and percentage variance thresholds, which are arbitrarily set and adjustable by the payee 202 or system administrator to allow for greater flexibility in improving the accuracy of the post-edits 212 price capture process. These thresholds are used to reduce the number of anomalies that are captured. For example, if the transaction exceeded one of the thresholds, then step 522 may be invoked at which point the transaction will not be used and is flagged to allow analysis of the excluded transaction. After being flagged the transaction is sent through the carrier BUC capture process discussed below. If the accepted TUC value meets the threshold requirements, then step 524 checks to see if the accepted TUC is the best cost (i.e., the highest accepted cost) of the particular time interval. If it is not, then the BIN BUC capture process is abandoned and the transaction proceeds to the carrier BUC capture process discussed below.
If the accepted TUC value is the current best cost of the present time interval, then step 526 is invoked, which checks to see if the batch BIN BUC should be lowered.
The batch BIN
BUC is the highest BIN BUC value captured for that particular BIN for the present time interval.
The batch BIN BUC should be lowered if two criteria are satisfied. The first criteria is that the accepted TUC value is lower than the previous time interval's BIN BUC, and the second criteria is that the accepted cost is lower than the submitted cost. If both criteria are met then step 532 is invoked. At step 532, if the accepted TUC value is less than the previous time interval's BIN
BUC value, then a flag is set that indicates that the current time interval's batch BIN BUC could potentially be used to set the BIN BUC lower in the BUC update process at the end of the current time interval discussed below. Then the batch BIN BUC is set to the accepted TUC value. After the batch BIN BUC value is lowered, the transaction proceeds to the carrier BUC capture process discussed below.
If the criteria in step 526 is not met, then step 528 is invoked to see if the batch BIN BUC
should be increased. For the batch BIN BUC to be increased, the accepted TUC
value should be higher than the previous time interval's BIN BUC. If so, then step 530 is invoked, where the batch BIN BUC is set to the accepted TUC value and the transaction proceeds to steps 534 and 535 to begin the earner BUC capture process discussed below. However, if the accepted TUC is not higher than the previous time interval's BIN BUC, then the transaction proceeds to the carrier BUC capture process (beginning at steps 534 and 535).
In steps 534 and 535, the capture process described above for the BIN BUC (in steps 516, 518, 520, 522, 524, 526, 528, 530, 532) is done again for the carrier BUC. In step 534, the carrier BUC value is retrieved, after which the carrier BUC capture process begins in step 535.
In step 535 the accepted TUC value is compared to the carrier BUC value. If this transaction was accepted at the price that it was submitted (or higher) and it is priced lower than the earner BUC, then this transaction will not affect the carrier BUC (i.e., the pharmacy should have asked for a higher price). If that is the case, then the transaction will proceed to step 536 for average cost capture discussed below. However, if the transaction was accepted at a price greater than the carrier BUC value then the accepted TUC is checked to see if it meets certain absolute and percentage variance thresholds. These thresholds, which are arbitrarily set and adjustable by the system administrator to allow for greater flexibility in testing the accuracy of the price capture process, can reduce the number of anomalies that are captured. If the transaction exceeded one of the thresholds, the transaction will not be used, and the transaction is flagged to allow analysis of the excluded transaction. After being flagged the transaction is sent through the average cost capture process in step 536 discussed below. If the accepted TUC meets the threshold requirements, then the accepted TUC is checked to see if it is the best cost (i.e., the highest cost) of the particular time interval. If it is not, then the carrier BUC capture process is abandoned, and the transaction proceeds to the average cost capture process discussed below.
If the accepted TUC is the current best cost of the present time interval, then the batch carrier BUC value is checked to see if it should be lowered. The batch carrier BUC value is the best accepted transaction cost for that particular carrier in the present time interval. The batch carrier BUC should be lowered if two criteria are satisfied. The first criteria is that the accepted TUC is lower than the previous time interval's carrier BUC, and the second criteria is that the accepted cost is lower than the submitted cost. If this transaction is less than the previous time interval's carrier BUC, then a flag is set that indicates that the present time interval's batch BIN
BUC could be used to set the carrier BUC lower in the BUC update process discussed below. If both criteria are met, then the batch carrier BUC is set to the lower value (i.e., the present time interval's batch BIN BUC). After the batch carrier BUC value is lowered, the transaction proceeds to the average cost capture process in step 536 discussed below.
If the criteria is not met, then the batch carrier BUC is checked to see if it should be increased. For the batch carrier BUC to be increased, the accepted TUC should be higher than the previous time interval's carrier BUC. If so, then the batch carrier BUC is set to the accepted TUC value, and the transaction proceeds to step 536 to begin the average cost capture process discussed below. However, if the accepted TUC is not higher than the previous time interval's carrier BUC, then the transaction proceeds to the average cost capture process directly.
At step 536, the average cost capture process is performed. This process is utilized in certain embodiments of the present invention, and is used for gathering data for analysis on how to better enhance the system for its users. One of ordinary skill in the art will appreciate that this average cost capture process could later be incorporated into the post-edit price capture process as well as the BUC update process to help determine how to appropriately set the BUC value.
The first step in the average cost capture process is to reduce the number of anomalies that are captured by checking to see that the captured transaction meets required absolute and percentage variance thresholds. If the transaction exceeded one of the thresholds then the transaction will not be used, and it is flagged to allow analysis of the excluded transactions.
If the transaction is within the thresholds, then the transaction is added as another row in a BIN
average table. It is also added as another row in a carrier average table. These values are held in these tables for analysis at a later time.
FIG. 5B is a flow chart illustrating an exemplary post-edit BUC update process in accordance with certain exemplary embodiments of the present invention. The process in FIG.
5B demonstrates what the system does at the end of a specified time interval when no more transactions will be received by the post-edits) 212 for processing for that specified interval. In accordance with certain exemplary eW bodiments of the present invention, the updates are conducted in a batch format (at one time), but one skilled in the art could implement the same updates in a real time format. Step 538 and 540 start the process to update the BIN BUC and carrier BUC to be used for the next time interval's transactions. The next step 542 checks to see if the current time interval's batch carrier BUC is greater than the previous time interval's carrier BUC. If it is, then step 544 is invoked which replaces the earner BUC value with the current time interval's batch carrier BUC value. This is an example of a BUC value update. However, if the current time interval's carrier BUC is not greater than the previous time interval's carrier BUC, then step 544 is skipped, and step 546 is invoked.
Step 546 checks to see if a carrier BUC that was updated for the current time interval is greater than the previous time interval's BIN BUC. If it is, then step 548 is invoked to replace the BIN BUC value with the current time interval's highest carrier BUC value.
However, if none of the current time interval's carrier BUC values are greater than the previous time interval's BIN BUC, then the previous time interval's BIN BUC must be checked to see if it should remain the same value or be reduced. Thus, step 548 is skipped, and step 550 is invoked.
1 S In accordance with certain exemplary embodiments of the present invention, step 550 checks three criteria. First, it checks to see if the current time interval's batch carrier BUC is greater than the previous time interval's carrier BUC. Next, step 550 checks to see if the batch BUC was previously flagged in step 535 as adjusted lower. Every consecutive time interval where the carrier BUC is lowered is counted. The third criteria checks if the carrier had a number of time intervals where the carrier BUC was reduced equal to a number specified by a reduce carrier BUC parameter located in the pricing group table or another part of the database 105 where the sponsor edit preferences (i.e., sponsor pricing parameters) are stored. The number of intervals required is reduced depending on how stale the carrier BUC is using the following formula:
Days Until Stale Price Group Capture Parameter - Days since Carrier BUC
Updated) /
Days Until Stale Price Group Capture Parameter * Days Required to Reduce Carrier BUC Parameter in the Pricing Group Table.
If the above formula results in a value less than I, then 1 is used. If all three criteria in step 550 are satisfied,' then step 552 is invoked. If riot, then step 552 is skipped, arid step 554 is invoked.

Step 552 replaces the carrier BUC value with the current time interval's batch carrier BUC value.
It also resets the counter tracking the intervals the carrier BUC was lowered to zero.
Step 554 checks to see if the highest carrier BUC that was updated for the current time interval is less than the previous time interval's BIN BUC. This is done because every BIN
represents multiple insurance carriers. Thus, if one of those insurance carriers BUC values was updated and is higher than the BUC value that insurance carrier's respective BIN, then the BIN
BUC value must also be updated. If the BIN BUC value must be updated, then step 556 is invoked, which replaces the BIN BUC value with the current time interval's highest carrier BUC
value. However, if none of the current time interval's carrier BUC values are not greater than the previous time interval's BIN BUC, then step 556 is skipped and the next step 558 is invoked.
Step 558 checks to see if there are any more carrier BUC values or BIN BUC
values to update.
If there are, then the process repeats starting at step 540. If there axe not, then step 560 is invoked. Step 560 checks to see if the carrier BUC values are stale. If a carrier BUC has not been updated after a certain number of time intervals (specified as a parameter set by either a payee's 202 or system's administrator), then that carrier BUC value is stale.
A stale BUC value is a BUC value that is unlikely to be an accurate representative of the best available reimbursement value. Stale BUC values need to be reset to allow them to reacquire a value that better reflects the maximum price reimbursed. Thus, every carrier BUC is checked to see how often it is updated. If a carrier BUC has not been updated or confirmed with a transaction unit cost for more than specified in the days until stale price group capture parameter located in the pricing group table or another part of the database 105 where the sponsor edit preferences (i.e., sponsor pricing parameters) are stored, and it is the highest carrier BUC for the BIN associated with it, then that carrier BUC is stale. If the carrier BUC is stale, step 562 is invoked. If not, step 562 is skipped, and step 568 is invoked to conduct average calculations.
Step 562 refreshes (i.e., updates) a stale carrier BUC by reducing the stale carrier BUC to next highest carrier BUC (associated -avith the same BIN) that is not stale.
However, if every carrier BUC is stale then the carrier BUC is not updated. The next step 564 checks to see if the carrier BUC was refreshed. If not, then step 566 is skipped, and step 568 is invoked to conduct average calculation. If the carrier BUC was refreshed, then step 566 will refresh the BIN BUC
by reducing the BIN BUC to the highest carrier BUC value associated with it, and then step 568 will be invoked. ' ' ' Step 568 performs average calculations before the post-edit 212 completes its updates.
The average calculations process is utilized in certain embodiments of the present invention and is used for gathering data for analysis on how to better enhance the system for its users. One of ordinary skill in the art will appreciate that these average calculations could later be incorporated into the BUC update process to help determine how to appropriately set the BUC
value. The average calculations first cleanup the averaging transaction tables by removing the oldest transactions that are in excess of the maximum number of transactions to process parameter specified in the price group's capture parameters located in the pricing group table. The cleanup process also removes any transactions that are older than a period between the current time interval back through a specified number of intervals, which is specified in the maximum number of days to average parameter located in the pricing group table or another part of the database 105 where the sponsor edit preferences (i.e., sponsor pricing parameters) are stored. If the remaining number of transactions is Less than the specified minimum number of transactions to average from the price group's capture parameters, then a new average cannot be set. If the remaining number of transactions is greater than the specified minimum number of transactions to average from the price group's capture parameters, then a new average of the remaining parameters is calculated. Step 568 is repeated as necessary for different classes of transactions.
Once all averaging calculations have been completed, the post-edit 212 update is exited.
Once the post-edit has finished its price capture processes, the payer's 216 response along with a system return message is sent to the payee 202. There are different system return messages sent depending on whether the system was performed a warning, capture, or substitute action in the pre-edit 204. Therefore, the contents of the message the edit system will attach and send to the payee 202 are designated by whichever selected action occurred in the major or minor BUC actions (steps 420 or 424 in the BUC pricing sub-edit). Once that information is passed to the payee 202, the system has completed that particular transaction.
Many modifications and other embodiments of the inventions set forth herein will come to mind to one skilled in the art to which these inventions pertain having the benefit of the teachings presented in the foregoing descriptions and the associated drawings.
Thus, it will be appreciated by those of ordinary skill in the art that the present invention may be embodied in many forms and should not be limited to the embodiments described above.
Therefore, it is to be understood that the inventions are not to be limited tb the specific embodiments disclosed and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terms are employed herein, they are used in a generic and descriptive sense only and not for purposes of limitation.

Claims

THAT WHICH IS CLAIMED:

1. A method for processing a prescription reimbursement claim that includes pricing data and payer data, comprising:
receiving a prescription reimbursement claim;
applying a pricing edit to the pricing data of the reimbursement claim to approximate a best available price for the reimbursement claim based at least in part on previously accepted reimbursement claims;
sending the edited reimbursement claim to a payer identified by the payer data; and receiving data from the payer representative of an accepted reimbursement claim amount and updating the pricing edit based on the accepted reimbursement amount.

2. The method of Claim 1, wherein applying the pricing edit includes identifying a reference value based at least in part on the payer data.

3. The method of Claim 1, wherein applying the pricing edit includes determining a unit cost of the prescription from the pricing data.

4. The method of Claim 3, wherein applying the pricing edit includes comparing the unit cost to a reference value that is associated with the payer.

5. The method of Claim 1, wherein applying the pricing edit includes modifying the pricing data of the prescription reimbursement claim to approximate the best available price paid by the payer within a predefined time interval.

6. The method of Claim 1, wherein updating the pricing edit includes determining if the accepted reimbursement claim amount represents a higher price than a reference value.

7. The method of Claim 6, wherein applying the pricing edit includes normalizing the pricing data units to the units of the reference value.

8. The method of Claim 6, wherein updating the pricing edit includes changing the reference value if the accepted reimbursement claim amount is higher than the reference value.

9. The method of Claim 1, wherein updating the pricing edit includes changing the reference value if the accepted reimbursement claim amount is lower than the reference value.

10. A computer-implemented system for processing a prescription reimbursement claim that includes pricing data and payer data, comprising:
a pre-edit module that applies a pricing edit to the pricing data of the reimbursement claim to obtain a best available price for the reimbursement claim; and a post-edit module that receives data representative of an accepted reimbursement claim amount and updates the pricing edit based on the accepted reimbursement amount.

11. The system of Claim 10, wherein the pre-edit module comprises a plurality of sub-edit modules, each sub-edit module being a pricing edit.

12. The system of Claim 11, wherein one of the plurality of sub-edit modules includes a fixed benefit pricing edit.

13. The system of Claim 11, wherein one of the plurality of sub-edit modules includes a cost to operator pricing edit.

14. The system of Claim 11, wherein the pre-edit module selects at least one sub-edit module to apply based at least in part on the pricing data.

15. The system of Claim 11, further comprising a database including a pricing table, wherein the pricing table includes best available price data.

16. The system of Claim 15, wherein the best available price data in the pricing table is associated with payer data.

17. A computer-readable medium storing computer-executable instructions for performing the steps of:
receiving a prescription reimbursement claim;
applying a pricing edit to the pricing data of the reimbursement claim to approximate a best available price for the reimbursement claim based at least in part on previously accepted reimbursement claims;
sending the edited reimbursement claim to a payer identified by the payer data; and receiving data from the payer representative of an accepted reimbursement claim amount and updating the pricing edit based on the accepted reimbursement amount.

18. The computer-readable medium of Claim 17, wherein the computer-readable medium further stores computer-executable instructions for modifying the pricing data of the prescription reimbursement claim to approximate the best available price paid by the payer within a predefined time interval.

19. The computer-readable medium of Claim 17, wherein the computer-readable medium further stores computer-executable instructions for determining a unit cost of the prescription from the pricing data when applying the pricing edit.

20. The computer-readable medium of Claim 19, wherein the computer-readable medium further stores computer-executable instructions for includes comparing the unit cost to a reference value that is associated with the payer.

21. The computer-readable medium of Claim 17, wherein the computer-readable medium further stores computer-executable instructions for changing the reference value if the accepted reimbursement claim amount is lower than the reference value when updating the pricing edit.