Systems and methods for ensuring medication therapy - Patents.com

Abstract

A system for customizing user parameters related to a drug treatment receives a first set of parameters associated with the drug treatment indicative of factors associated with the drug treatment in a first format, determines a subset of the first set of parameters based on one or more factors, and converts the subset to a second format, provides the second set of parameters to a second computing device (hereinafter simply referred to as device), receives a third set of parameters from the second device, the third set of parameters being based on the one or more factors and provided in a third format, converts the third set of parameters from the third format to the first format based on the second set of parameters, and presents the converted third set of parameters received from the second device to an interested party at the first device.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of U.S. Provisional Patent Application No. 62 / 867,014, entitled "SYSTEM AND METHODS FOR IMPLEMENTING AN EXCHANGE TO EXPEDITE NEGOTIATIONS," filed June 26, 2019, and U.S. Provisional Patent Application No. 62 / 947,453, entitled "SYSTEM AND METHODS FOR IMPLEMENTING AN EXCHANGE TO EXPEDITE NEGOTIATIONS," filed December 12, 2019, the contents of which are incorporated herein in their entireties.

[0002] The present disclosure relates to a platform that accelerates complex decision-making processes that span multiple organizations and may involve elements of problem-solving, negotiation, and collaboration. [Background technology]

[0003] Entirely new classes of drug treatments are being developed by public research institutes and private innovators to combat a variety of diseases. Breakthroughs in the science of genomics, epigenetics, and systems biology are coming to fruition. The drug pipeline is brimming with breakthroughs including targeted immunotherapy, cell therapy, and gene therapy. Summary of the Invention [Problem to be solved by the invention]

[0004] However, the current market entry process lags behind scientific innovation. Pharmaceutical companies and governments are looking to innovative pricing policies, such as indication- and value-based pricing, for new innovative drugs, but negotiations between the parties take too long even when only two parties are involved. With three or more parties, negotiations become even more complicated and are often not allowed due to antitrust concerns. As a result, there is a logjam of various drug therapies that have been approved by regulators but have not yet reached patients. Patients are not getting the medicines they need, companies are not selling the latest treatments, and governments and suppliers are unable to serve patients. A new negotiation system is needed that reflects the new realities of scientific innovation and marketed treatments. [Means for solving the problem]

[0005] In some embodiments, a computerized system for customizing user parameters related to securing a drug treatment comprises a memory and a processor communicatively coupled to the memory, the processor configured to perform the following steps: receive, from a first computing device, a first set of parameters associated with the drug treatment, where one or more of the first set of parameters are indicative of one or more factors associated with the drug treatment, where the first set of one or more parameters are provided in a first format; and converting the received first set of parameters to a second set of parameters based on information received in the first set of parameters, where converting the first set of parameters to the second set of parameters includes determining a subset of the first set of parameters based on the one or more factors and determining a second format of the first parameters based on the one or more factors. The computerized system performs the steps of providing a second set of parameters to a second computing device; receiving from the second computing device a third set of parameters associated with the drug treatment, where the third set of parameters is based on one or more factors associated with the treatment and where the third set of parameters is provided in a third format; converting the third set of price negotiating parameters from the third format to the first format based on the second set of parameters; and presenting the converted third set of parameters received from the second computing device to a stakeholder at the first computing device.

[0006] In some embodiments, the first set of parameters includes a number of patients eligible for the drug treatment, a duration of the treatment, an expected price of the drug treatment per patient, and an expected reimbursement per patient. In some embodiments, the number of patients eligible for the drug treatment may be one. In some embodiments, the computerized system configured to determine a subset of the first set of parameters is further configured to exclude one or more parameters of the first set of parameters based on a determination that a concealment flag is associated with one or more parameters associated with the first set of parameters. In some embodiments, the one or more factors associated with the drug treatment include a given average patient height, a given average patient weight, and a given average patient surface area, and a duration of the treatment.

[0007] In some embodiments, the claimed computerized system is further configured to determine an average dosage requirement of the drug therapy per patient based on one or more factors associated with the drug therapy. In some embodiments, the computerized system is further configured to determine a number of packs of the drug therapy required for the patient based on the average dosage requirement of the drug therapy and the duration of the therapy. In some embodiments, the third set of parameters includes an offered price per pack of the drug therapy and an offered rebate for the drug therapy.

[0008] In some embodiments, the computerized system is further configured to convert the determined price per pack of the drug treatment to a per patient price of the drug treatment based on one or more factors associated with the drug treatment. In some embodiments, the computerized system is further configured to compare the expected price of the drug treatment to the offered price of the drug treatment and provide an agreement signal to the first computing device and the second computing device in response to determining that the expected price of the drug treatment and the offered price of the drug treatment fall within a predetermined range of each other.

[0009] In some embodiments, the computerized system is further configured to provide a disagreement signal to the first computing device and the second computing device in response to determining that the expected price of the drug treatment and the offer price of the drug treatment are not within a predefined range of each other. In some embodiments, the disagreement signal sent to the first computing device further includes a proposed expected price of the drug treatment based on historical data associated with the first computing device and a difference between the expected price and the offer price. In some embodiments, the disagreement signal sent to the second computing device further includes a proposed offer price of the drug treatment based on historical data associated with the second computing device and a difference between the expected price and the offer price. In some embodiments, the computerized system is further configured to receive an updated expected price of the drug treatment from the first computing device in response to the disagreement signal, and receive an updated offer price of the drug treatment from the second computing device in response to the disagreement signal.

[0010] These and other capabilities of the disclosed subject matter will be more fully understood after reviewing the following figures, detailed description, and claims. It is to be understood that the phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting.

[0011] Various objects, features, and advantages of the disclosed subject matter can be more fully understood with reference to the following detailed description of the disclosed subject matter when considered in conjunction with the following drawings, in which like reference numerals identify like elements and in which: [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 illustrates a block diagram of a system 100 in accordance with some embodiments of the present disclosure. [Diagram 2]FIG. 2 illustrates an interface of the negotiation engine 108 provided to a payer in accordance with some embodiments of the present disclosure. [Diagram 3] FIG. 13 illustrates an interface for creating a new deal space in a negotiation engine, according to some embodiments of the present disclosure. [Figure 4] FIG. 13 illustrates an interface for creating a new deal within a new deal space created in a negotiation engine, according to some embodiments of the present disclosure. [Diagram 5] FIG. 2 illustrates an example interface of a deal space of a negotiation engine in accordance with some embodiments of the present disclosure. [Figure 6] FIG. 6 illustrates a “Term Cap Refund” interface initiated from interface 500 of FIG. 5 according to some embodiments of the disclosure. [Figure 7] FIG. 6 illustrates a “Treatment Interruption Refund” interface initiated from interface 500 of FIG. 5 according to some embodiments of the present disclosure. [Figure 8] FIG. 13 is a diagram of an interface showing an overview of a deal proposal before it is submitted to a pharmaceutical company, according to some embodiments of the present disclosure. [Figure 9] FIG. 1 illustrates a negotiation engine interface provided to a pharmaceutical company in accordance with some embodiments of the present disclosure. [Figure 10] FIG. 13 illustrates an interface presented to a pharmaceutical company to respond to a proposed negotiation, according to some embodiments of the present disclosure. [Figure 11] FIG. 13 illustrates an interface presented to a payer during negotiation according to some embodiments of the present disclosure. [Figure 12] FIG. 2 illustrates an example flowchart of a negotiation process between two parties, according to some embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] According to embodiments of the present disclosure, a system and method are disclosed that accelerates complex decision-making processes among multiple organizations and encompasses elements of problem solving, negotiation, and collaboration.

[0014] Entirely new classes of drug treatments are being developed by public research institutes and private innovators to combat a variety of diseases. Breakthroughs in the science of genomics, epigenetics, and systems biology are coming to fruition. The drug pipeline is brimming with breakthroughs including targeted immunotherapy, cell therapy, and gene therapy.

[0015] However, these new types of drug therapies cannot reach the market as fast as they are being developed. Typically, the negotiation process between pharmaceutical companies that manufacture the drugs and governments (also called payers) that purchase the drugs lags behind scientific innovation. Pharmaceutical companies and payers are seeking innovative pricing policies, such as indication- and value-based pricing, for treatment plans based on new drug therapies. However, negotiations between the various parties involved take too long. For combination therapies, where three or more parties are involved, negotiations become even more complicated and are often not allowed due to antitrust concerns.

[0016] As a result, there is a logjam of treatments that have been approved by regulators but not yet reimbursed. Patients are not getting the drugs they need, companies are not selling the latest treatments, and payers and providers are unable to serve patients. A new negotiation system is needed that reflects the new realities of scientific innovation and the treatments on the market.

[0017] FIG. 1 illustrates a block diagram of a system 100 according to some embodiments of the present disclosure. The system 100 may include m payer computing devices 102A-102m, n pharmaceutical company computing devices 104A-104n, and o third parties 110A-110o. In some embodiments, each computing device 102A-102m is associated with a different payer, each computing device 104A-104n is associated with a different pharmaceutical company, and each computing device 110A-110o is associated with a different third party. In some embodiments, more than one user is authorized to access information routed through each of the computing devices 102A-m, 104A-n, and 110A-o. Administrators at each of the computing devices 102A-m, 104A-n, and 110A-o may divide the associated authorized users associated with each computing device into various teams. Such division helps to enable automatic routing of information directly to authorized users associated with that information. In some embodiments, the administrator groups users into logical entities based on the products to which the users may have access privileges. In some embodiments, a pharmaceutical company associated with one of the computing devices 102A-m may include an oncology team and a cardiovascular team within the organization associated with the pharmaceutical company. Within oncology, one team may be responsible for breast cancer products and another team may be responsible for lung cancer products. In some embodiments, teams may be established for the same product for different indications, e.g., team A of the pharmaceutical company associated with computing device 102A may be responsible for Keytruda for melanoma and team B of the pharmaceutical company associated with computing device 102A may be responsible for Keytruda for lung cancer. Tables 1-3 show examples of teams created within pharmaceutical company 102A and payer 104A, where negotiations are for product A for indication A and product B for indication A.

[0018] [Table 1] Table 1

[0019] [Table 2] Table 2

[0020] [Table 3] Table 3

[0021] In some embodiments, multiple computing devices 102A-m, 104A-n may be part of the same pharmaceutical company or payer. In some embodiments, these users may be divided into teams to facilitate distribution of information as described. In some embodiments, an administrator of the negotiation engine 108 defines different levels of permissions that may be granted to various users that are part of the pharmaceutical company or payer. For example, the permissions may be based on geographic restrictions and restrictions on drug treatments. Thus, a user may have the permission to view all negotiations taking place with the government of a particular country or a particular region. In some embodiments, these permissions may allow a user to view negotiations of a particular pharmaceutical company or payer. In some embodiments, the permissions may include viewing all negotiations without having any permission to edit or make changes to the negotiation. In some embodiments, the permissions may include viewing even parameters of the negotiation that are hidden from other negotiating parties. For example, the payer may choose to hide the initial price of the negotiation from the pharmaceutical company, but a third party user with proper authorization may be able to view the price of the negotiation entered by the payer.

[0022] In some embodiments, a set of permissions may be used to create a role. The assignment of permissions may be done dynamically. A role encompasses a set of permissions that can be changed at any time without changing the role itself. Roles can be created in the system at any particular time based on an administrator's decision to have the role or based on the needs of the client. Some exemplary roles are Admin Read Only, Admin User, Payer Admin User, Payer User, Payer Read Only User, Pharma Admin User, Pharma Read Only User, Pharma User. An Admin Read Only User may be defined as a user that does not have the ability to create / modify / delete any artifacts based on the administrator application. An Admin User may be defined as a user that has full access to all artifacts of the administrator application. A Payer Admin User may be defined as a payer user that is a "negotiation engine administrator" within the payer's organization. A Payer User may be defined as a payer user that has the ability to perform negotiations. A Payer Read Only User may be defined as a payer user that has read-only access to negotiations. Pharma admin users, pharma users, and pharma read-only users may be defined, as well as their corresponding payer users. In some embodiments, standard privileges specific to payer users and pharma users may be defined. In some embodiments, advanced privileges specific to an "administrator" user of the negotiation engine 108 may be defined.

[0023] In some embodiments, governments, non-governmental donors, hedge funds, insurance companies, financial institutions, high net worth individuals, or other intermediaries may be examples of third parties that may step in to guarantee payer payments from emerging markets. In some embodiments, hedge funds may be examples of third parties that may be willing to purchase some of the risk associated with negotiations between payers and pharmaceutical companies. In some embodiments, data providers may be examples of third parties that may "declare" to provide data that will be used to settle payments between payers and pharmaceutical companies. In the example of FIG. 1, m, n, and o may be any large finite integer greater than or equal to 1. Payers and pharmaceutical companies may be connected to the negotiation engine 108 via a network 106. In some embodiments, the network 106 may be any one of a wireless local area network, a local area network, the Internet, or any other form of network.

[0024] The negotiation engine 108 receives and evaluates proposals from both parties (payers 102A-m and pharmaceutical companies 104A-n). The negotiation engine 108 may be run and maintained by an administrator that is not associated with any of the payers 102A-m, pharmaceutical companies 104A-n, or third parties 110A-o. The administrator may provide access to the negotiation engine 108 to the pharmaceutical companies and payers. In some embodiments, the administrator keeps a running record of all products being offered by each of the pharmaceutical companies 104A-n at a particular time. In some embodiments, the list of products includes a detailed view of the product list, product characteristics, as well as a list of product packs applicable to the product, with the ability to add new products, modify existing products, and remove products.

[0025] In some embodiments, the administrator also receives a base set of assumptions agreed upon by one or more of the pharmaceutical companies 104A-n and one or more of the payers 104A-m. The base set of assumptions may include the average patient weight, the average patient body surface area, and the date on which the assumptions were made. These assumptions may be customized for each product by including the average number of product packs administered to a patient per year. A product pack is a unit of product determined based on the average dosage administered to a patient within a predefined set of time periods. In some embodiments, the administrator may determine the product pack and the price of the product pack based on a dosing schedule associated with the product. The dosing schedule is received from one of the pharmaceutical companies 102A-m along with information associated with the new product. The dosing schedule includes the start cycle, cycle length, end cycle, and dosing for all days within a cycle consisting of the number of product administrations per day, as well as the single dosage. In some embodiments, when adding a new product, the pharmaceutical company may add the new product to the treatment plan. The treatment plan may include one product (monotherapy) or multiple products (combination therapy). At any point, an administrator may create a new treatment, including attributes such as diagnosis, treatment plan code, market, treatment type (single agent or combination), product 1, product 1 primary pack, product 1 dosage calculation method, product 2 (if combination treatment), product 2 primary pack, product 2 dosage calculation method, etc.

[0026] In some embodiments, the interface of the negotiation engine 108 provided to the payers may be different than the interface of the negotiation engine provided to the pharmaceutical companies. In some embodiments, the negotiation engine 108 may be hosted on a web server that is remote to the payers 102A-m and pharmaceutical companies 104A-n. In some embodiments, the negotiation engine may include different operating modes. In some embodiments, the negotiation engine may include two or more environments for users (payers 102A-m and pharmaceutical companies 104A-n). The first operating mode (also called a sandbox environment) may be a simulation environment. The sandbox environment may replicate the interfaces presented to both payers and pharmaceutical companies. However, access to the sandbox environment is restricted to those working at or associated with the organization that has been provided access. The sandbox is simply a trial environment, and deals proposed within the sandbox environment are for testing purposes only and have no consequences.

[0027] The second mode of operation (also called the terminal environment) is a real-world environment that may result in binding transactions. The terminal environment allows users to express commitments that can be presented to other organizations that may be invited to participate in the negotiation process.

[0028] Payer and drug data, as well as communications between payers 102A-m and pharmaceutical companies 104A-n, are preferably encrypted.

[0029] Various aspects of the negotiation engine 108 interface are described with respect to FIGS. 2-16. Any negotiation or transaction regarding a drug treatment or treatment plan may be initiated from the payer end via the negotiation engine's payer interface. In the negotiation engine's payer interface, negotiations may be grouped by "indication or disease," as described in more detail below. For example, a payer may initiate a negotiation regarding multiple myeloma, and all negotiations regarding multiple myeloma are grouped in the same space, regardless of the treatment used. Additionally, negotiations or transactions regarding a drug treatment or treatment plan may be initiated from the pharmaceutical company end via the negotiation engine's pharmaceutical company interface. In the interface provided to the pharmaceutical company, negotiations may be grouped by the drug offered. For example, a pharmaceutical company may group any or all negotiations involving a particular drug (e.g., Keytruda), regardless of the diagnosis for which those drugs may be prescribed. The payer specifies negotiation parameters such as contract term, structure, treatment plan, currency, and pricing units, which are described in more detail below.

[0030] FIG. 2 illustrates an interface of the negotiation engine 108 provided to a payer according to some embodiments of the present disclosure. Any one of the payers 102A-m can access the negotiation engine 108 using authentication information provided to the payer by a third party responsible for managing the negotiation engine 108. After the payer logs into the negotiation engine 108, an interface similar to interface 200 is presented to the payer. Interface 200 includes a button 202 that may be used to initialize a new deal space. Interface 200 also illustrates summaries 204, 206, and 208 of all deal spaces that are at various stages of progress. A deal space is a collection of ongoing negotiations that have been initiated for a particular diagnosis. As shown in FIG. 2, deal space summary 204 illustrates an overview of ongoing deals for non-small cell lung cancer. The deal space summary 204 illustrates the number of ongoing negotiations, the number of companies involved, the number of products under negotiation, and the number of eligible patients. Similar to trade space overview 204, trade space overviews 206 and 208 provide an overview of ongoing negotiations related to advanced melanoma and multiple myeloma. Trade space overviews 204, 206, and 208 also include information regarding the trade space owner. The trade space owner may be an authorized user responsible for negotiations related to an identified diagnosis.

[0031] FIG. 3 illustrates an interface for creating a new trading space in a negotiation engine, according to some embodiments of the present disclosure. The interface 300 illustrated in FIG. 3 is generated when a user creates a new trading space by clicking the button 202 in the interface 200 of FIG. 2. The first thing required to open a new trading space is a diagnosis for which a medication is required. In some embodiments, the diagnosis may be selected from a drop-down menu 302 available in the interface 300. In some embodiments, the diagnoses available in the drop-down menu 302 may be provided based on products and medications made available by administrators of a database by various pharmaceutical companies.

[0032] FIG. 4 illustrates an interface for creating a new deal within a new deal space created in the negotiation engine according to some embodiments of the present disclosure. After a new deal space is created, a user may create a new negotiation within the new deal space by clicking a button 402 in the interface 400. To start a new negotiation, the negotiation engine 108 requires certain information that is considered essential for the negotiation. First, the payer should define the contract period 404 of the negotiation. In some embodiments, the start and end dates of the contract period 404 may be selected using a calendar function implemented in the negotiation engine 108. Next, the payer should select from a list 406 drug treatments that may be used to treat the selected diagnosis identified by the deal space. The data in the list 406 is populated using information provided to the administrator by the various computing devices 104A-n associated with the pharmaceutical company in the interface. The interface 400 also includes additional options 408. In some embodiments, the additional options 408 may include an option for specifying a maximum number of rounds of negotiation between the payer and the pharmaceutical company. After all information has been entered, the user may press button 410 to begin the negotiation.

[0033] FIG. 5 illustrates an exemplary interface of a trade space of a negotiation engine according to some embodiments of the present disclosure. In some embodiments, an interface 500 of the negotiation engine 108 illustrates a trade space for Keytruda MSD. The trade space interface 500 includes various sections. Section 502 is the header of the trade space. Section 502 includes a subsection 508 that includes some of the basic information specified when creating the trade space from window 400 of FIG. 4. Section 502 includes medications for specific diagnoses. Subsection 508 of section 502 includes the selected contract term, the name of the person initiating the negotiation, the currency in which the negotiation will be conducted, and the number of rounds specified when creating the trade space. Each of these options may be changed at any time using the pencil icon shown next to each of the displayed options.

[0034] Section 504 of interface 500 shows an interface for receiving an entered price to start a new negotiation. Section 504 includes a pricing tab 532. Pricing tab 532 includes a pricing unit drop-down menu 522 with multiple options (e.g., yearly price, quarterly price, monthly price, and cycle price). Cycle price reflects treatment of one patient for one cycle. In some embodiments, one cycle of patient treatment is three weeks. There may be a fourth week where the patient does not consume any drug. In some embodiments, the dosage of the drug may change as the cycle progresses. Monthly price reflects treatment of one patient for one month. Quarterly price reflects treatment of one patient for one quarter. Yearly price reflects treatment of one patient for one year.

[0035] The pricing policy dropdown 520 includes different patient policies for pricing. In some embodiments, the payer may add preferences for certain treatments over other treatments, and the interface may allow the payer to specify multiple preferences. The first pricing policy is patient volume. Patient volume pricing is based on the number of patients being treated. Because patient volume pricing is based on the number of patients, the price offer may vary depending on the total volume of patients being treated. Input fields 524 and 534 show inputs for receiving pricing details for patient volume. At 524, the payer may specify a patient minimum volume. At 534, the payer may specify a patient maximum volume, and at 526, the payer specifies a price for the entered patient volume. In some embodiments, the patient maximum volume field may be left empty if the price does not vary with volume. In some embodiments, the payer may want to split the patient volume pricing. In such cases, the payer may enter a patient volume split and a corresponding new price for a volume-based pricing proposal. At 528, the payer has the option to "hide the target price" from the pharmaceutical company. In some embodiments, the option to hide the target price may be a global or individual setting. For example, in some countries, all data or specific data may always be hidden or always visible, while in other countries, payers or pharmaceutical companies may be free to choose what they want to do. Selecting this option hides the target (combined) price from other negotiation parties. In some embodiments, an additional offer may be defined in the patient's volume pricing offer. This additional offer may be a "term cap." The interface for "term cap" may be initiated by pressing button 536. This term cap rebate considers an additional offer in addition to the volume offer (e.g., in case of uncertainty in expected market share). This interface is described in more detail in FIG. 6.

[0036] The second pricing policy in the drop-down menu 520 is a duration of treatment pricing policy. A duration of treatment pricing policy is based on the duration a patient is treated. As a result, the price of the treatment policy varies from patient to patient based on the duration the patient has been on treatment. In some embodiments, the duration of treatment may be divided into years, quarters, months, and cycles. In addition to the volume division, the duration of treatment is also available in the patient's volume pricing policy, allowing for the option of duration division.

[0037] The interface 500 of Figure 5 includes a performance tab 538 next to the time limit tab 536. The performance tab specifies a price offer, which can be based on (treatment) performance. The performance tab interface is explained in more detail in Figure 7.

[0038] Section 510 of interface 500 of FIG. 5 includes a brief description of the medication on which the negotiation is based. This brief description is often referred to as a summary of product characteristics (SPC). Part of the SPC includes a description of the patients who are eligible for the medication. In some embodiments, the SPC is information provided to an administrator of negotiation engine 108 by the pharmaceutical company when the medication was created. In some embodiments, this section 510 includes a subsection 512 that allows the payer to modify the patient eligibility criteria for the medication. In some embodiments, section 510 includes a subsection 514 that allows the payer to set an estimated volume of patients who will be provided with the medication.

[0039] Section 506 of interface 500 visualizes the dosing schedule of a drug treatment as it is administered to a patient. In some embodiments, the dosing schedule consists of one or many dosing periods, each period representing a modified dosage of at least one product in the treatment. In some embodiments, the dosing schedule is provided to the administrator when a drug treatment is added to the negotiation 108. In some embodiments, the dosing schedule setting modal allows the user to specify the start cycle, end cycle (or an indefinite cycle), cycle length, name override (by default, the name is generated from the start and end of the cycle, i.e., Cycle1-3), dosing for all days in the cycle consisting of the number of product administrations per day, as well as the single dosage.

[0040] Section 530 of interface 500 displays consumption assumptions for the selected medication treatment. The consumption assumptions section 530 has multiple purposes. First, section 530 visualizes the primary packs of each of the product parts of the negotiation. The concept of primary packs to negotiate pricing for a particular pack and derive prices for other packs based on algebraic formulas is common in the industry. The consumption assumptions 530 can visualize the pre-rebate (list) prices of each of the product parts of the negotiation. Links are exposed to the user to examine the nature of the price (i.e., date and pricing source, as shown on the right). The list prices are sourced from known reliable pricing sources specific to the market (country). The consumption assumptions 530 visualizes the average number of packs consumed by one patient given the product as part of a complex treatment for a particular period of time. Using this information, the consumption assumptions section 530 visualizes the cost of treating one patient for a particular period (a year in this example) for each of the product parts of the negotiation, and the total cost of treatment if a zero rebate was offered. Finally, the consumption assumptions section 530 can associate pricing units 532 with the period specified in the consumption assumptions period. In some embodiments, if the user wants to negotiate a monthly rebate, the consumption assumptions section 530 reflects a monthly number.

[0041] The negotiation engine 108 includes a translator to calculate the average number of packs administered to a patient during a particular time period. By including the average number of packs, an administrator can easily convert the price of the time period to the price of the packs and vice versa. These numbers are shown in the consumption assumptions section 530.

[0042] FIG. 6 illustrates a "Time Cap Reimbursement" interface initiated from interface 500 of FIG. 5 according to some embodiments of the disclosure. Interface 600 of FIG. 6 receives input in input field 606 requesting a price reimbursement (1-100%) for patients based on evidence that a certain percentage of patients, specified in input field 608, are expected to continue treatment after the time period specified in input fields 602 and 604. The payer has an option in "Notes" section 610 to specify and define the input received in interface 600. The payer also has the option to conceal this specified reimbursement from the pharmaceutical company by selecting option 612.

[0043] FIG. 7 illustrates a “Treatment Discontinuation Rebate” interface initiated from interface 500 of FIG. 5 according to some embodiments of the present disclosure. The Treatment Discontinuation Rebate interface is initiated from the performance tab of interface 500 of FIG. 5. In some embodiments, pricing offers may be made based on the performance of the drug regimen. Interface 700 of FIG. 7 receives input in input field 706 requesting a price rebate (1-100%) for patients based on evidence that a certain percentage of patients, specified in input field 708, are expected to discontinue treatment due to side effects / toxicity or lack of response to a particular treatment regimen after a period of time specified in input fields 902 and 704. The payer has the option in “Notes” section 710 to specify and define the input received in interface 900. The payer also has the option to conceal this specified rebate from the pharmaceutical company by selecting option 712.

[0044] After the payer has specified all the required information in the interfaces presented in Figures 2-7, the payer may submit the proposal to the pharmaceutical company for review. In some embodiments, the payer may save the current state of the entered negotiation and return to finalizing the negotiation by pressing save button 516. The payer may initiate the submission by pressing submit button 518 in interface 500 of Figure 5. Before the payer submits the conditional commitment, a pop-up window similar to interface 800 of Figure 8 is displayed to the payer. Figure 8 is an interface that shows an overview of the deal proposal before it is submitted to the pharmaceutical company according to some embodiments of the present disclosure. Section 802 of interface 800 of Figure 8 summarizes the pricing policy, pricing unit, and pricing currency specified in the interface of Figure 5. Checkboxes 804 and 806 are present to confirm that the accuracy and correctness of the data, as well as the privacy agreement, have been approved. After the payer has reviewed the information and approved the privacy policy, the pricing proposal may be submitted to the other negotiation parties by pressing button 808.

[0045] FIG. 9 illustrates a negotiation engine interface provided to a pharmaceutical company according to some embodiments of the present disclosure. Any one of the pharmaceutical companies 104A-n can access the negotiation engine 108 using authentication information provided to the pharmaceutical company by a third party responsible for managing the negotiation engine 108. After the pharmaceutical company logs into the negotiation engine 108, an interface similar to interface 900 is presented to the pharmaceutical company. Interface 900 includes a header 902 indicating negotiations in which the pharmaceutical company is involved. Section 904 organizes the negotiations that the pharmaceutical company has been invited to participate in by diagnosis. As shown in FIG. 9, record 914 summarizes the negotiations proposed by initiator 914 for the diagnosis specified by 904. Record 914 indicates the negotiation for product 916 initiated by initiator specified in 906. Record 914 also specifies the treatment plan 908, the number of rounds 910 the negotiation has passed through, and the current state 912 of the negotiation.

[0046] Figure 10 illustrates an interface presented to a pharmaceutical company to respond to a proposed negotiation according to some embodiments of the present disclosure. The interface 1000 of Figure 10 is similar to the interface 500 of Figure 5, except for a pricing section 1002. The pricing section 1002 includes a subsection 1004 that displays initial negotiation suggestions for the drug therapy proposed by the payer. In some embodiments, if the payer decides to conceal the initial offer price and related parameters of the drug therapy, the price section of subsection 1004 displays "Undisclosed."

[0047] Subsection 1006 of pricing section 1002 receives the offer price of the drug treatment from the pharmaceutical company. For the convenience of the pharmaceutical company, the negotiation engine 108 can receive the price of the drug treatment in a price per primary pack in field 1008. The negotiation engine 1008 can convert the price per pack provided by the pharmaceutical company to a price per year in field 1010 using the translator, consumption assumptions, and dosing schedule described with respect to FIG. 5. In the case of multiple drug treatments, this price per year is sent to the payer so that the payer can calculate the overall cost of the medication regimen. After the pharmaceutical company has entered the offer price of the drug treatment that the payer is interested in, the pharmaceutical company can submit the price to the payer by pressing button 1012.

[0048] FIG. 11 illustrates an interface presented to a payer during negotiations, according to some embodiments of the disclosure. The interface 1100 of FIG. 11 is a modified version of the interface 500 of FIG. 5. After all parties involved in the negotiation have entered proposals, the first round of negotiations is considered finished. The interface 1100 includes an indicator 1102 that displays an evaluation of the proposals to determine whether there is an overlap between the proposals or whether there is a match between the proposals. In some embodiments, if there is no match between the proposals, the interface 1100 of the negotiation engine 108 may include a color scale (red-yellow-green) indicator instead of the indicator 1102, along with a slider that indicates the position of the negotiation within the range of the likelihood of success. In some embodiments, the color scale is a scale (more similar to an analog thermometer than a digital thermometer) rather than a single color. Different elements of the negotiation that change (price, volume, performance offers, etc.) can affect the position of the marker on the color scale and can change its position at different rates. For example, the threshold value may include a randomly generated correction factor, so that the negotiation parties do not have to know what is going on behind the scenes. If the payer price is $100 and the pharma price is $110, the color scale in the pharma interface of the negotiation engine 108 may be green (based on the assumption that both prices will fall). Similarly, if the pharma shows its price as $120, the color scale will be yellow, and if the pharma price is $130, the color scale will be red.

[0049] In some embodiments, if the initiator of the negotiation is a payer, the interface 1100 of the negotiation engine 108 displays a pricing recommendation section (not shown) in the pricing commitments tab, above or below the pricing offer. In some embodiments, the pricing recommendation section includes one or more price tiers along with a graphical representation of the probability of success. In some embodiments, the probability of success may be based on a conditional commitment specified by the payer. For example, the conditional commitment may specify a percentage of match or other price percentage limit. In some examples, the conditional price may be based on a monetary amount. In some examples, the initiator of the negotiation may have the ability to introduce a commitment based on a commitment from the other party to the negotiation. In some embodiments, if the negotiation engine 108 determines that the pricing specified in the previous round should not change, if the payer maintains the same price, "Price should not change" is displayed in the pricing commitments tab along with a probability of success widget. The probability of success may be different from the previous round, assuming there is a certain probability that the pharmaceutical company will accept the price change recommendation.

[0050] In some embodiments, if the initiator of the negotiation is a payer, the interface of the negotiation engine 108 associated with the payer displays a Continue Treatment Recommendation section above or below the Continue Treatment Pledge in the Time Limit tab. In some embodiments, the Continue Treatment Recommendation section includes information such as the number of cycles before the Continue Treatment Rebate applies, the rebate percentage, the percentage of the patient population expected to continue treatment, and a probability of success widget. In some embodiments, if the price change algorithm of the negotiation engine 108 determines that the Continue Treatment information specified in the previous round should not change, a message "Continuance Treatment Pledge should not be changed" is displayed along with a probability of success widget in the Time Limit tab. In some embodiments, the probability of success can be different from the previous round, assuming that there is a certain probability that the payer will accept the price change recommendation. In some embodiments, the price change algorithm of the negotiation engine 108 determines that the Continue Treatment Pledge should be removed and incorporated into the pharmaceutical company's pricing pledge. In that case, an appropriate message is displayed to the pharmaceutical company along with a probability of success widget in both the Pricing tab and the Time Limit tab.

[0051] In some embodiments, if the initiator of the negotiation is a payer, the interface of the negotiation engine 108 displays a treatment interruption recommendation section above or below the treatment interruption pledge in the performance tab. In some embodiments, the treatment interruption recommendation section includes information such as the number of cycles before treatment interruption rebates are applied, the rebate percentage, the percentage of the patient population expected to discontinue treatment, and a probability of success widget. In some embodiments, if the price change algorithm of the negotiation engine 108 determines that the treatment interruption information specified in the previous round should not change, a message "Treatment interruption pledge should not be changed" is displayed along with the probability of success widget in the performance tab. In some embodiments, the probability of success can be different from the previous round, assuming that there is a certain probability that the payer will accept the price change recommendation. In some embodiments, the price change algorithm may determine that the treatment interruption pledge should be removed and incorporated into the pharmaceutical company's pricing pledge. In some embodiments, an appropriate message is displayed to the pharmaceutical company along with the probability of success widget in both the pricing and performance tabs.

[0052] In some embodiments, the price change algorithm of the negotiation engine 108 detects that the payer should change the pricing policy or pricing unit in the next round. The payer interface displays such a message to the user just below the rounds section of the screen.

[0053] In some embodiments, the probability of success widget described at the round level displays the overall probability of success of the round. In some embodiments, the probability of success widget at the pledge level (e.g., pricing / treatment continuation / treatment discontinuation) is a percentage widget that displays the delta success factor that each pledge recommendation attributes to the overall negotiation success probability.

[0054] The platform indicates whether a match has been achieved (based purely on price). It may include price offers where the price is acceptable to all parties but depends on the actual patient treatment duration and response. If the payer decides to click button 1104, further information regarding the prices offered by the other parties involved becomes available. The pricing model interface provided by the pharmaceutical company is explained in more detail in FIG. 11.

[0055] If no match exists, the negotiation engine 108 distinguishes between components of the deal for which a match may exist and those for which no match exists, in some embodiments, the negotiation engine moves both parties closer to a more equitable solution.

[0056] FIG. 12 illustrates an example flow chart of a negotiation process between two parties according to some embodiments of the present disclosure.

[0057] At 1202, the negotiation engine 108 receives from a first computing device a first set of parameters associated with the drug treatment, one or more of the first set of parameters indicative of one or more factors associated with the drug treatment, the first set of parameters being provided in a first format. As shown in FIGS. 3-7, in some embodiments, the first set of parameters associated with the negotiation may include information such as the name of the drug, the dosing schedule, the duration of the drug treatment, the number of patients eligible for the drug treatment, the price of the drug treatment, the expected reimbursement for the price of the drug treatment, and the pricing policy for the drug treatment. In some embodiments, some of this information (e.g., the name of the drug, the dosing schedule, the criteria for eligible patients) may be entered by the pharmaceutical company when creating the drug treatment in the negotiation engine 108. In some embodiments, other information such as the number of eligible patients, the duration of the drug treatment, the expected price, and the expected reimbursement for the price may be received from a payer.

[0058] At 1204, negotiation engine 108 determines a subset of the first set of parameters based on one or more factors. In some embodiments, as illustrated with respect to FIGS. 5-7, the payer may decide to conceal some parameters from the pharmaceutical company when creating the negotiation proposal. In such embodiments, the payer may request negotiation engine 108 to conceal the price of the drug from the pharmaceutical company by selecting option 528 from interface 500, and to conceal the expected reimbursement from the pharmaceutical company by selecting option 612 in interface 600 and option 712 in interface 700.

[0059] At 1206, the negotiation engine 108 determines a second form of the subset of the first parameters based on one or more factors. In some embodiments, the price entered by the pharmaceutical company for the drug treatment may be in per capita terms. However, the pharmaceutical company prefers to receive and provide prices in per pack terms. The negotiation engine 108 may convert the per patient price received from the payer (first form) to a price per primary pack (second form) using information such as the dosing schedule and primary pack size provided by the pharmaceutical company when creating the drug treatment.

[0060] At 1208, the negotiation engine 108 provides the second set of parameters to the second computing device. The negotiation engine 108 may provide the received and modified parameters to the pharmaceutical company for input.

[0061] At 1210, the negotiation engine 108 receives from the second computing device a third set of parameters associated with the drug treatment, the third set of parameters being based on one or more factors associated with the treatment, the third set of parameters being provided in a third format. In some embodiments, after the parameters are provided to the pharmaceutical company, the pharmaceutical company can review the information and provide its own input regarding pricing of the drug treatment requested by the payer. In some embodiments, the pharmaceutical company may have access to information from the payer when making a decision, and in some cases, the information may be concealed from the pharmaceutical company. The pharmaceutical company still has access to certain basic parameters, such as duration of drug treatment, number of eligible patients, etc., that help the pharmaceutical company provide a price for the drug treatment.

[0062] At 1212, the negotiation engine 108 converts the third set of parameters from the third form to the first form. In some embodiments, a payer may enter a price for the medication in a preferred form (per primary pack terms), which is then converted to the payer's preferred form (per capita terms) using the dosing schedule, primary pack size, and duration of the medication.

[0063] At 1214, the negotiation engine 108 presents the third set of parameters received from the second computing device and converted to the first computing device. In some embodiments, the information received from the pharmaceutical company, after being modified, is sent to the payer for confirmation. In some embodiments, the negotiation engine 108 may provide an indicator based on the difference between the process provided by the payer and the process provided by the pharmaceutical company to highlight the status of the negotiation.

[0064] The subject matter described herein can be implemented in digital electronic circuitry, or computer software, firmware, or hardware, including the structural means disclosed herein and structural equivalents thereof, or combinations thereof. The subject matter described herein can be implemented as one or more computer program products, such as one or more computer programs tangibly embodied in an information medium (e.g., a machine-readable storage device) or embodied in a propagated signal for execution by or control of the operation of a data processing apparatus (e.g., a programmable processor, a computer, or multiple computers). Computer programs (also referred to as programs, software, software applications, or code) can be written in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, including as stand-alone programs suitable for use in a computing environment, or as modules, components, subroutines, or other units. A computer program does not necessarily correspond to a file. A program can be stored in part of a file holding other programs or data, in a single file dedicated to that program, or in multiple linked files (e.g., a file storing one or more modules, subprograms, or portions of code).A computer program can be deployed to be executed on one computer or on multiple computers, either at one site or distributed across multiple sites, and interconnected by a communications network.

[0065] The processes and logic flows described herein, including steps of the methods of the subject matter described herein, can be performed by one or more programmable processors executing one or more computer programs to perform functions of the subject matter described herein by processing input data and generating output. The processes and logic flows can also be performed by, and apparatus of the subject matter described herein can be implemented as, special purpose logic circuitry, such as, for example, a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC).

[0066] Examples of processors suitable for executing computer programs include both general-purpose and special-purpose microprocessors, and any one or more processors of any kind of digital computer. Typically, a processor receives instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer also includes one or more mass storage devices (e.g., magnetic disks, magneto-optical disks, or optical disks) for storing data, or is operatively coupled to receive or transmit data to or from such mass storage devices, or both. Information media suitable for embodying computer program instructions and data include all forms of non-volatile memory, such as, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and optical disks (e.g., CD and DVD disks). The processor and memory can be supplemented by, or incorporated in, special-purpose logic circuitry.

[0067] To provide for interaction with a user, the subject matter described herein can be implemented on a computer that includes a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user, as well as a keyboard and a pointing device (e.g., a mouse or trackball) that the user can use to provide input to the computer. Other types of devices can also be used to provide for interaction with a user. For example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user can be received in any form, including acoustic input, speech input, or tactile input.

[0068] The subject matter described herein can be implemented in a computing system including back-end components (e.g., a data server), middleware components (e.g., an application server), or front-end components (e.g., a client computer including a graphical user interface or a web browser that a user can use to interact with an implementation of the subject matter described herein), or any combination of such back-end, middleware, and front-end components. The components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local-area network (LAN) and a wide area network (WAN) (e.g., the Internet).

[0069] It is to be understood that the disclosed subject matter is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The disclosed subject matter is capable of other embodiments and of being practiced and carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein are for the purpose of description and should not be regarded as limiting.

[0070] As such, those skilled in the art will appreciate that the conception on which the present disclosure is based may be readily utilized as a basis for the designing of other structures, methods, and systems for carrying out the purposes of the disclosed subject matter. It is important, therefore, that the claims be regarded as including such equivalent constructions insofar as they do not depart from the spirit and scope of the disclosed subject matter.

[0071] While the disclosed subject matter has been described and illustrated in the foregoing example embodiments, it will be understood that the disclosure has been made by way of example only, and that numerous changes in the details of implementation of the disclosed subject matter can be made without departing from the spirit and scope of the disclosed subject matter, which is limited only by the scope of the following claims.

Claims

1. 1. A computerized system for customizing user parameters related to securing a drug treatment, comprising: Memory, a processor communicatively coupled to the memory, the processor comprising: receiving one or more hypotheses associated with the patient, the one or more hypotheses associated with the patient comprising: an indication that there is an agreement between the pharmaceutical treatment provider and a plurality of purchasers of the pharmaceutical treatment regarding one or more assumptions associated with the patient; The patient's average body surface area, The average weight of the patients, and The date associated with said agreement receiving the receiving, in a first network communication from a first computing device, a purchase offer for the pharmaceutical treatment from a purchaser of the plurality of purchasers, the purchase offer for the pharmaceutical treatment including a first set of parameters, the first set of parameters comprising: the number of patients eligible for said drug treatment; and Expect a refund, receiving the forming a second set of parameters; determining a second format for the second set of parameters, the second format including an expected price per pack of the pharmaceutical treatment; receiving, in a second network communication, from a second computing device, an offer to provide the pharmaceutical treatment, the offer to provide the pharmaceutical treatment including a third set of parameters including an offer price for a supply of the pharmaceutical treatment per pack; converting the third set of parameters from a third format to a first format, the converting comprising converting an offer price of a supply of the pharmaceutical treatment per pack to a per patient price of the pharmaceutical treatment; and displaying the third set of transformed parameters via the second computing device.

2. 2. The computerized system of claim 1, wherein the number of patients eligible for the drug treatment is one.

3. The computerized system of claim 1 , wherein the one or more assumptions associated with the patient further include a predetermined average patient weight and a duration of treatment.

4. 4. The computerized system of claim 3, further configured to determine an average dosage requirement of the drug treatment for each patient based on the one or more assumptions associated with the patient.

5. 5. The computerized system of claim 4, further configured to determine the number of packs of the drug treatment required for a patient based on the average dosage requirement of the drug treatment per patient and the duration of the treatment.

6. 6. The computerized system of claim 5, wherein the third set of parameters includes an offered price for a supply of the pharmaceutical treatment per pack of the pharmaceutical treatment and an offered rebate for the pharmaceutical treatment.

7. comparing the expected price per pack of the pharmaceutical treatment to the offered price per pack of the pharmaceutical treatment; 7. The computerized system of claim 6, further configured to: provide a first consent signal to the first computing device and provide a second consent signal to the second computing device in response to determining that the expected price per pack of the pharmaceutical treatment and the offered price per pack of the pharmaceutical treatment are within a predetermined range of each other.

8. 8. The computerized system of claim 7, further configured to: provide a first disagreement signal to the first computing device and provide a second disagreement signal to the second computing device in response to determining that the expected price per pack of the pharmaceutical treatment and the offered price per pack of the pharmaceutical treatment are not within the predetermined range of each other.

9. 10. The computerized system of claim 8, wherein the first disagreement signal further comprises a proposed expected price per pack of the pharmaceutical treatment based on historical data associated with the first computing device and a difference between the expected price per pack of the pharmaceutical treatment and the offered price per pack of the pharmaceutical treatment.

10. 10. The computerized system of claim 9, wherein the second disagreement signal further comprises a proposed offer price per pack of the pharmaceutical treatment based on historical data associated with the second computing device and a difference between the expected price per pack of the pharmaceutical treatment and the offer price per pack of the pharmaceutical treatment.

11. receiving an updated expected price per pack of the pharmaceutical treatment from the first computing device in response to the first disagreement signal; 11. The computerized system of claim 10, further configured to receive an updated offered price per pack of the pharmaceutical treatment from the second computing device in response to the second disagreement signal.

12. further configured to determine a probability of success of negotiation between the one of the plurality of buyers and the supplier; 2. The computerized system of claim 1, wherein the probability of success is a percentage of the price offered by the buyer and the price requested by the supplier.

13. 13. The computerized system of claim 12, further configured to display a recommendation to the one of the plurality of buyers based on the probability of success, the recommendation including a recommendation adjustment for a subsequent negotiation round.

14. The computerized system of claim 12, wherein the first set of parameters further includes an expected price per patient for the pharmaceutical treatment.

15. The computerized system of claim 12, further comprising excluding one or more parameters from the first set of parameters based on a determination that a concealment flag is associated with one or more parameters associated with the first set of parameters.

16. A computer-implemented method for negotiating the purchase of a pharmaceutical treatment between a supplier of the pharmaceutical treatment and a purchaser of the pharmaceutical treatment, comprising: receiving one or more hypotheses associated with the patient, the one or more hypotheses associated with the patient comprising: an indication that there is an agreement between the pharmaceutical treatment provider and a plurality of purchasers of the pharmaceutical treatment regarding one or more assumptions associated with the patient; The patient's average body surface area, The average weight of the patients, and The date associated with said agreement receiving the receiving, in a first network communication from a first computing device, a purchase offer for the pharmaceutical treatment from a purchaser of the plurality of purchasers, the purchase offer for the pharmaceutical treatment including a first set of parameters, the first set of parameters comprising: the number of patients eligible for said drug treatment; and Expect a refund, receiving the forming a second set of parameters; determining a second format for the second set of parameters, the second format for the second set of parameters including an expected price per pack of the pharmaceutical treatment; receiving, in a second network communication, from a second computing device, an offer to provide the pharmaceutical treatment, the offer to provide the pharmaceutical treatment including a third set of parameters including an offer price for a supply of the pharmaceutical treatment per pack; converting the offer price of the supply of said pharmaceutical treatment per pack into a price per patient of said pharmaceutical treatment; and displaying the third set of transformed parameters via the second computing device.

17. When executed by a processor, the processor: receiving one or more hypotheses associated with the patient, the one or more hypotheses associated with the patient comprising: an indication that there is agreement between a pharmaceutical treatment provider and a plurality of purchasers of the pharmaceutical treatment regarding one or more assumptions associated with the patient; The patient's average body surface area, The average weight of the patients, and The date associated with said agreement receiving the receiving, in a first network communication from a first computing device, a purchase offer for the pharmaceutical treatment from a purchaser of the plurality of purchasers, the purchase offer for the pharmaceutical treatment including a first set of parameters, the first set of parameters comprising: the number of patients eligible for said drug treatment; and Expect a refund, receiving the forming a second set of parameters; determining a second format for the second set of parameters, the second format for the second set of parameters including an expected price per pack of the pharmaceutical treatment; receiving, in a second network communication, from a second computing device, an offer to provide the pharmaceutical treatment, the offer to provide the pharmaceutical treatment including a third set of parameters including an offer price for a supply of the pharmaceutical treatment per pack; converting the offer price of the supply of said pharmaceutical treatment per pack into a price per patient of said pharmaceutical treatment; displaying the third set of transformed parameters via the second computing device; and A computer-readable medium for storing instructions to cause a computer to perform the steps of:

18. further configured to determine a probability of success of negotiation between the one of the plurality of buyers and the supplier; 20. The computer readable medium of claim 17, wherein the probability of success is a percentage of a price offered by the purchaser and a price requested by the supplier.

19. 20. The computer-readable medium of claim 18, further configured to display a recommendation to the one of the plurality of buyers based on the probability of success, the recommendation including a recommended adjustment for a subsequent negotiation round.

20. The computer-readable medium of claim 17, wherein the first set of parameters further comprises an expected price per patient of the pharmaceutical treatment.

21. The computer-readable medium of claim 17, further comprising excluding one or more parameters from the first set of parameters based on a determination that a concealment flag is associated with one or more parameters associated with the first set of parameters.

Images