Invention for Systems and Methods for Determining Patient Financial Responsibility for Multiple Prescription Products

Invented by Roger G. Pinsonneault, McKesson Corp

The McKesson Corp invention works as follows

Systems and Methods are Provided for Determining Patient Financial Responsibility for Multiple Prescription Products across Multiple Healthcare Transactions. The computer of a service provider can receive several healthcare transactions and evaluate them to determine whether they include a group transaction total and a transaction. The computer of the service provider can compare the transaction numbers to the total number of transactions in a group to determine whether all transactions have been received. The transactions are then sent to the claims processor for adjudication. The service provider computer will identify each patient’s co-pay and calculate the total patient pay based on that group. The total amount of patient pay can then be sent to a computer connected to a healthcare service provider.

Background for Systems and Methods for Determining Patient Financial Responsibility for Multiple Prescription Products

Over the last few years, health insurance plans provided by private insurers and government-sponsored insurers have become increasingly complex. It can also happen when a patient is trying to fill out a prescription. These insurers will not only cover the cost of the product prescribed, but may also require the patient to pay a copayment. Co-pays may be different depending on the type of product (e.g. name brand versus generic). The insurers might also have a deductible, which the patient or family of the patient must pay before they cover the prescription drug. The insurer may also cover certain products, while denying coverage to others. Finaly, each insurer can have one or more sets of rules, copay levels, deductibles, and product coverage groups depending on the type coverage provided to a specific patient.

This makes it difficult for prescribers (e.g. doctors, nurses or nurse-practitioners) and pharmacists to anticipate the cost of a product when it is prescribed. This cost information is important for the patient to know in advance to determine whether they will complete all prescriptions and receive the benefit from each product prescribed.

The following description will be more detailed with respect to the drawings that accompany this document, which show exemplary embodiments. These concepts may be implemented in many different ways and are not limited to these exemplary embodiments. They have been provided to make this disclosure thorough and complete and to fully convey to those in the field the scope of concepts. “Like numbers refer to similar, but not necessarily identical, elements across the board.

The embodiments of the present invention include systems and method that allow the determination of patient responsibility for multiple prescription drugs as part of processing the healthcare transaction, in real-time or close to real-time. A pharmacist, a doctor, a nurse, a physician’s assistant or another prescriber (e.g. a hospital, doctor, or physician’s staff) may electronically transmit to a computer of a service provider multiple healthcare transactions. These include a predetermination or benefits transaction, a healthcare claim transaction or prescription claim or billing, a healthcare order transaction or an ePrescription transaction. Each healthcare transaction can include information about the patient and the medication/product prescribed, as well as a transaction number and the total group transaction count. The computer of the service provider can evaluate the healthcare transactions to determine the transaction number and the total group transaction count. The service provider computer can determine whether the transaction number is equal to the total group transaction. Once the transaction number is equal to the total group transactions, in certain embodiments the service provider computer can send each individual healthcare transaction which makes up the total transaction count of the group to a claims processing computer for adjudication.

The claims processor computer can send the service provider computer each adjudicated answer for each healthcare transaction in the group after each healthcare transaction has been adjudicated. The service provider computer can identify the patient-pay amount in each adjudicated response in the group, and then calculate a total patient-pay amount that covers the healthcare transactions within the group based on the individual patient-pay amounts. The service provider computer can transmit to the healthcare provider computers the adjudicated responses for each healthcare transaction within the group, along with the calculated total patient pay amounts. The total patient payment amount can be appended in a message to one or more adjudicated answers to healthcare transactions. The service provider computer can also automatically, and without a request being received from the healthcare provider, send reversal transactions for each healthcare transaction to the claims processor.

System Overview

FIG. According to an example embodiment, FIG. 1 shows an example system 100 that supports healthcare transactions, prescription billing, and verifications of patient coverage eligibility. The exemplary system facilitates determining the patient’s financial responsibility for prescription products in the context of a healthcare transaction. This includes, but is not limited to: an eligibility verification, a predetermination benefits transaction or healthcare claim, prescription claim, billing or claim request, healthcare order, or electronic prescription transaction. 1. As shown in FIG. As shown in FIG. As shown in FIG. As shown in FIG. hereinafter. Alternatively, each of the pharmacy/healthcare provider computer 104A and prescriber/healthcare provider computer 104B may be specifically discussed with reference to designations on FIG. 1.

As desired each of the healthcare providers computers 104A, 104B, services provider computer 106 and/or claims processing computer 108 can include one or multiple processing devices configured to access and read associated computer-readable mediums that have stored on them data and/or instructions for implementing different methods, such as those described herein.

Additionally in certain exemplary implementations, the service provider 106 can be in communication one or multiple cumulative pricing modules 180. These modules may have access to and/or communicate with one or several suitable data storage devices such as database 182. The cumulative pricing module may receive data or healthcare transactions directly from the service provider computer. The cumulative pricing module 180 can evaluate the data after receiving the healthcare transaction data. It will determine whether multiple healthcare transactions have been submitted for a particular patient (e.g. via a group transaction total count or another group transaction identifier), and if the current healthcare data is part of that group. The cumulative pricing module may compare the current healthcare transaction with the total group transaction counts to determine whether all transactions have been received. The cumulative pricing module 180 will then facilitate the transmission of all healthcare transactions in the group to the claims processor computers via the service provider computer.

The cumulative pricing module can retrieve patient pay amounts (e.g. patient co-pays) from the adjudicated answers in a group. It then calculates the total patient payment amount using the retrieved patient payments from each adjudicated answer. The cumulative pricing module can generate or add a message to any of the adjudicated answers for the group of healthcare transaction. The message can include the total amount that the patient pays for the prescribed products within the group of healthcare transaction. The adjudicated responses for each healthcare transaction in the group of health care transactions can be sent from the service provider’s computer to the healthcare provider’s computer 104, from where the healthcare transactions were originated. The cumulative pricing module may generate automatically and without receiving a specific request from the healthcare computer 104 a reverse transaction for each healthcare transaction in the group. The cumulative pricing module may facilitate transmission of the group reversal transaction from the service provider computers 106 to one or more claim processors 108. Although FIG. While FIG. Moreover, FIG. In certain embodiments, while FIG.

Generally, network systems and devices, such as the healthcare provider computers (104A, 104B), service provider computer (106), cumulative pricing module (180) and claims processor computer (108), may be equipped with or associated with appropriate hardware and/or programs for transmitting or receiving data or computer-executable commands over one or multiple communications links or networks. These network devices and system may also include any number processors to process data and execute computer-executable instruction, as well other internal and peripheral parts that are well known. These network devices and system may also include, or be in communication with, any number of memory devices that can store data and/or computer executable instructions. Each network device can be a computer by executing computer executable instructions. The term “computer-readable medium” is used in this document. “Any form of suitable memory or device

As shown in FIG. As shown in FIG. 1, the healthcare provider computers (104A and 104B), service provider computer (106), claims processor computer (108), and cumulative pricing module (180) may be connected to each other through one or several networks. This network 110 can include private or public networks such as the Internet, or publicly switched telephone networks. The components of the network 110, including the healthcare provider computers (104A and 104B), service provider computer (106), claims processor computer (108), and cumulative pricing module (180) will be described in more detail.

Each healthcare computer 104 can be associated with any healthcare provider such as a hospital, clinic or hospice. The exemplary healthcare provider computer 104A can be found in a pharmacy office (104A), or a doctor’s office (104B). This is only an example and not meant to be restrictive. The healthcare provider computers 104A-104B can be any processor-driven device suitable for processing healthcare requests from patients, consumers or prescribers, and communicating information related to healthcare transactions to service provider computer 1006. Examples include a server, mainframe, desktop, personal computer, digital assistants, personal digital assistants, digital tablets, Internet appliances, application-specific circuits, microcontrollers, minicomputers, and any other processor-based devices. In some embodiments, the healthcare provider computers 104A and/or 104B can be used as a point-of-sale device for a healthcare provider. The computer-implemented instruction execution by the healthcare provider computer may form a particular machine or special purpose computer that can be used to process healthcare requests from patients and communicate healthcare transactions to service provider computer. In certain embodiments, the control and/or operations of each healthcare provider computers 104A or 104B can be distributed across several processing components.

Each client module 138A or 138B can be an Internet browser, or any other software suitable for interfacing with the service provider computer. For example, a user 120, such as a pharmacist, pharmacy assistant, nurse practitioner, physician, nurse, or other pharmacy, hospital or physician’s office employee, may utilize the respective client module 138A and 138B in preparing and providing a healthcare transaction, such as a predetermination of benefits request, healthcare claim transaction, prescription claim or billing request, healthcare order transaction, or e-prescription transaction (e.g., electronic prescription order transaction, e-script, or e-prescription), to the service provider computer 106 for delivery to: i) the appropriate claims processor computer 108 or other third-party for adjudication or other coverage/benefits determination, or ii) the appropriate other healthcare provider computer, such as from the prescriber/healthcare provider computer 104B to a pharmacy/healthcare provider computer 104A for dispensing of the prescribed medication. The healthcare provider computers 104A, 104B, may use the respective client modules 138A, 138B, to receive or retrieve data, messages or responses from the system 100 and/or the service provider computer. In certain embodiments, for example, the client modules 138A or 138B can be used to receive from the service provider computers 106 a healthcare transaction (or rejection), a prescription status notification (or adjudication), and/or a response to that healthcare transaction.

The one or two I/O interfaces 128A or 128B can facilitate communication between a healthcare provider’s computer 104A or 104B, and one or several input/output devices. For example, the user interface devices such as a keyboard or mouse, graphical display, keypad or control panel, touchscreen display, remote control or microphone that allow interaction with the healthcare provider’s computer 104A or 104B. The one or more I/ O Interfaces 128A or 128B, for example, may facilitate the entry of information related to a healthcare transaction, by an employee 120, such as a pharmacist, physician or nurse, hospital employee or nurse practitioner affiliated with a hospital, pharmacy, physician’s or clinic or another similar healthcare provider. The network interfaces 130A/130B facilitate the connection of the healthcare provider computers 104A/104B with one or several suitable networks. For example, the network shown in FIG. 1. “In this regard, the healthcare provider computers 104A and/or 104B can receive and/or transmit information to other components of the network system 100, such the service provider computer 1006.

Referring back to FIG. The service provider computer may be any processor-driven device configured to receive, process, and fulfill requests from the healthcare providers computers 104A or 104B, cumulative pricing module 180 and/or claims processor computer. These requests can relate to pharmacy benefits and billing, electronic prescription submission and/or to other healthcare transactions. In some exemplary embodiments the service provider computer may act as a switch/router to route healthcare transactions or other healthcare requests sent by healthcare provider computers 104, to the appropriate one of the many claims processor computers. The service provider computer may, for example, route healthcare transactions from the healthcare provider computers (104A and/or 104B) to a claims processing computer 108. This computer could be a PBM, an insurer, Medicare, Medicare Part D, accountable care organizations, or any other third-party payer. In another example, the service provider computer 106 may route healthcare transactions communicated from a prescriber/healthcare provider computer 104B (or other prescriber of medication, products, and/or services) to the pharmacy/healthcare provider computer 104A.

In certain embodiments, a service provider computer may include a host server, host modules 154 or other software to facilitate the reception of a health transaction from a pharmacy/healthcare provider computer or 104A, and/or routing the healthcare transaction received by the host computer, claims processor computer, or both. In various embodiments, the service provider computer may communicate with any number of healthcare provider PCs 104A and/or 104B and/or cumulative pricing modules 180 and/or claims processing computers 108.

The service provider computer 106 can include any number or special purpose computers, other machines, microcontrollers and/or application-specific circuits. It may also include personal computers, minicomputers mainframe computers servers, networked devices, and/or processor-driven devices. In some embodiments, computer-implemented or computer-executed instructions are used to control the operation of the service computer 106. These instructions may be executed by one of more processors that are associated with the computer. This can result in a special purpose computer or another machine that facilitates the receipt, routing and/or processing healthcare transactions. One or more processors controlling the operation of the service computer 106 can be integrated into the computer or in communication with it via one or several networks. In some exemplary embodiments the control and/or operations of the service provider 106 can be distributed across several processing components.

The service provider module may be able to perform pre-edits, pre-analysis, or other pre-processing on a received health care transaction before routing the healthcare transaction (such as a claim for healthcare) to a suitable claims processing computer 108, or sending an ePrescription to a pharmacy/healthcare provider computer, 104A. The service provider module may also be able to perform post-edits to an adjudicated answer or reply that is received by a claims processing computer 108 in relation to a healthcare transaction before routing the adjudicated answer to one of healthcare provider computers, 104A or 104B. In certain embodiments, the service module 156 can also perform functions that are described in relation to the cumulative price module 180. The service provider module can perform a wide range of pre-edits or post-edits as required in different embodiments.

Click here to view the patent on Google Patents.