Patent Application
20220238210
The disclosed embodiments generally relate to systems and methods used to reduce medial supply costs for healthcare providers by effectively leveraging tier pricing programs brought forth by suppliers.
Hospital spending is the primary driver of the increasing healthcare spending in the U.S., costing over one trillion dollars. The high healthcare cost erodes disposable income and the wealth of many American families. Hospitals, in the meantime, struggle to stay financially viable. Many large healthcare systems have observed double-digit growth in revenue in the past few years, but revenue growth is outpaced by a much faster increasing operating expense, which eventually leads to declined operating income. A close examination of hospital cost structure reveals that spending on tangible medical supplies alone may account for 30% to 40% of a hospital's expenses, the second largest cost category after labor, and it is growing faster than labor costs. As such, it is critical for healthcare organizations and group purchasing organizations (GPOs) to have a method and system that allows them to make optimal purchasing decisions to minimize the procurement cost of medical supplies.
Healthcare organizations establish contracts with a set group of healthcare clinical products suppliers, either directly or through GPOs. These suppliers are called contract suppliers or contract vendors. Contract vendors offer healthcare organizations complicated contracts that have multiple pricing tier options, known as tier pricing. Tier pricing is a form of quantity discount. Suppliers offer quantity discounts to reduce operating costs, induce larger purchases, and/or gain market share. It is well studied in the supply chain and marketing literature that quantity discount in general also improves the profits of buyers. This benefit, however, has not been realized for healthcare providers.
Tier contracts offered by healthcare clinical products suppliers are one of the most complex pricing schemes with many distinctive challenges. First, a tier requirement is often built upon multidimensions, involving consumption level, market share, the number of suppliers, and facility and IDN level of measures. These dimensions are intertwined, creating a few to more than a dozen of tier prices in each contract offered by suppliers. In addition, many suppliers segment their product lines and negotiate contracts on individual product categories; for example, a supplier may have a three-tier contract in total joint implants but a completely different seven-tier contract in electrophysiology products. A large healthcare organization may have dozens of categories; within a category are a variety of pricing schedules offered by individual manufacturers. Moreover, a category-based contract may cover dozens to over a hundred of items with varying discount rates for the same tier. This is in contrast to other industries where suppliers typically apply the same discount rate across all products. Furthermore, within a contract, multiple facility, IDN, and even GPO level tiers coexist along with various market share requirements based on different number of suppliers. An IDN-level tier is not necessarily better than a facility-level tier, barring the same market share requirements. Facilities in an IDN may opt for different facility-level tiers, but the IDN as a whole cannot have both facility and IDN tiers from the same contract. Therefore, a facility may have to abnegate a favorable facility-level tier in order for the IDN to achieve a lower total cost. The GPO-level tiers follow the same rule, except that it is very difficult to meet the onerous market share requirements. To realize the significant cost saving opportunities provided by tier pricing, healthcare organizations need a new and innovative method and system to evaluate all tier options in a holistic manner, optimize product and supplier selection decisions, and eventually minimize the procurement cost of medical supplies.
Another challenge that hospitals face is physician preference items (PPIs). Purchasing decisions in most industries are driven by product quality, cost, and supplier's service commitment. Hospital procurement is different and strongly influenced by physician preferences. Many of the most expensive supplies in surgery procedures, such as cardiac, orthopedic, and spine, are items for which physicians have strong preferences. Physicians generally possess limited knowledge about the cost of medical supplies and often underestimate the cost of high-cost items. Physician preference is widely criticized for inflating supply costs, which has motivated considerable amount of research addressing hospital-physician conflicts and organizational alignments. A core question that has yet to be answered is to what extent exactly physician preferences impact a hospital's bottom line, which PPIs shall be standardized, and to what vendors' products the PPIs be standardized. Studies show that physicians are more willing to work with hospitals on product standardization when they are informed of the cost implication of alternative products.
Embodiments disclosed herein are not limited to any specific devices. The drawings described herein are for illustration purposes only and are not intended to limit the scope of the embodiments.
Although the embodiments disclosed herein are susceptible to various modifications and alternative forms, specific embodiments are shown by way of example in the drawings and are described herein in detail. It should be understood, however, that drawings and detailed description thereto are not intended to limit the scope of the claims to the particular forms disclosed. On the contrary, this application is intended to cover all modifications, equivalents and alternatives falling within the spirit and scope of the disclosure of the present application as defined by the appended claims.
This disclosure includes references to “one embodiment,” “a particular embodiment,” “some embodiments,” “various embodiments,” or “an embodiment.” The appearances of the phrases “in one embodiment,” “in a particular embodiment,” “in some embodiments,” “in various embodiments,” or “in an embodiment” do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.
Reciting in the appended claims that an element is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) for that claim element. Accordingly, none of the claims in this application as filed are intended to be interpreted as having means-plus-function elements. Should Applicant wish to invoke Section 112(f) during prosecution, it will recite claim elements using the “means for” [performing a function] construct.
As used herein, the term “based on” is used to describe one or more factors that affect a determination. This term does not foreclose the possibility that additional factors may affect the determination. That is, a determination may be solely based on specified factors or based on the specified factors as well as other, unspecified factors. Consider the phrase “determine A based on B.” This phrase specifies that B is a factor that is used to determine A or that affects the determination of A. This phrase does not foreclose that the determination of A may also be based on some other factor, such as C. This phrase is also intended to cover an embodiment in which A is determined based solely on B. As used herein, the phrase “based on” is synonymous with the phrase “based at least in part on.”
As used herein, the phrase “in response to” describes one or more factors that trigger an effect. This phrase does not foreclose the possibility that additional factors may affect or otherwise trigger the effect. That is, an effect may be solely in response to those factors, or may be in response to the specified factors as well as other, unspecified factors.
As used herein, the terms “first,” “second,” etc. are used as labels for nouns that they precede, and do not imply any type of ordering (e.g., spatial, temporal, logical, etc.), unless stated otherwise. As used herein, the term “or” is used as an inclusive or and not as an exclusive or. For example, the phrase “at least one of x, y, or z” means any one of x, y, and z, as well as any combination thereof (e.g., x and y, but not z). In some situations, the context of use of the term “or” may show that it is being used in an exclusive sense, e.g., where “select one of x, y, or z” means that only one of x, y, and z are selected in that example.
In the following description, numerous specific details are set forth to provide a thorough understanding of the disclosed embodiments. One having ordinary skill in the art, however, should recognize that aspects of disclosed embodiments might be practiced without these specific details. In some instances, well-known, structures, computer program instructions, and techniques have not been shown in detail to avoid obscuring the disclosed embodiments.
Throughout the document, the terms “medical supplies”, “hospital supplies”, “healthcare clinical products”, and “clinical products” are used interchangeably. The terms “healthcare system” and “healthcare organization” are used to describe a healthcare integrated delivery network (IDN) or integrated delivery system (IDS). The term “hospitals” and “facilities” are used interchangeably, referring individual healthcare facilities within an IDN unless the content clearly states otherwise. The term “healthcare providers” is a general term that refer to IDNs, hospitals under an IDN (e.g., “member hospitals”), and other types of healthcare facilities. The terms “suppliers”, “vendors”, and manufacturers” are used interchangeably throughout this disclosure.
It is to be understood the disclosed embodiments are not limited to particular devices or methods, which may, of course, vary. It is also to be understood that the terminology used herein is for the purpose of describing particular embodiments only, and is not intended to be limiting. As used in this specification and the appended claims, the singular forms “a”, “an”, and “the” include singular and plural referents unless the content clearly dictates otherwise. Furthermore, the word “may” is used throughout this application in a permissive sense (i.e., having the potential to, being able to), not in a mandatory sense (i.e., must). The term “include,” and derivations thereof, mean “including, but not limited to.” The term “coupled” means directly or indirectly connected.
Embodiments disclosed herein present a system and method to help healthcare organizations quantify the financial impact of PPIs, standardize healthcare clinical products, and most importantly, reduce the costs of medical supplies. Significant cost saving opportunities are offered not only to large healthcare systems with dozens or even hundreds of facilities, but also to small healthcare providers that have one or two facilities. It is particularly valuable to the healthcare organizations where purchasing decisions are centralized, either within the organization or through a GPO, and are to be optimized at the organization level instead of for individual facilities.
A tier conditions coder 231 transforms the above tier requirements into six-dimensional vectors and each vector comprises supplier name, tier name, base of the market share requirement (i.e., facility level or IDN level), minimum unit market share requirement of this supplier, maximum number of vendors in the combined market share requirement, and minimum combined unit market share requirement. One of the major challenges to capture the cost saving opportunities is the complex structure of tier conditions, which are made up of a number of factors (e.g., the number of suppliers, market share, etc.) and have no standards. The coder 231 standardizes the structure of tier requirements and provide distinct advantages described herein. For instance, in some embodiments, standardization of the structure of tier requirements using multi-dimensional vectors may allow a computer system to assess the tier requirements (e.g., tier conditions) more efficiently in determining and solving for various parameters such as costs of hospital supplies, as described herein. Without the use of multi-dimensional vectors, solving for the various described parameters using a computer system may be time-consuming and costly and involve various manual inputs that can slow down the process and reduce efficiency of the computer system.
A product substitution database generator 232 generates a one-way product substitution database by analyzing the product equivalency charts provided by suppliers (stored in supplier database 210), and the equivalency matrix known to hospitals (stored in facility database 220). Healthcare clinical products, such as coronary stents and artificial knees, have stringent quality requirements, are highly complex, require special handling, and are modified frequently. Many hospitals have established teams consisting of doctors, nurses, and procurement specialists to assess products and their equivalency relationships, but rapid technology and medical innovations make it hard for hospitals to keep track of all the changes and new functionalities of clinical products. The problem is aggravated by manufacturers' unwillingness to share data, meticulously making their products unique, and blocking products from being comparable. As a result, hospitals often have to rely on manufacturers to indicate alternative products that they offer to substitute products provided by competitors. And since no two products are exactly identical and a seemingly trivial variation may compromise the safety and outcome of patients, similar products from different manufacturers generally cannot be assumed interchangeable. This is a unique phenomenon in healthcare due to the criticality nature of clinical products; for example, product A may substitute product B, but a reverse substitution is not allowed. In addition, not all products have equivalents; a supplier may have equivalents for some of the products offered by another supplier but can rarely replace a competitor's entire product portfolio, even only for a single clinical category. This makes the supplier selection especially challenging as any product substitute decisions made towards a supplier must take into account the impact on the cost of the remaining products that have no alternatives.
A plurality of vectors (storing tier requirements) generated by the tier conditions coder 231, the product substitution mapping generated by the product substitution database generator 232, the product lists and the tier prices extracted from the supplier database 210, and the hospitals' product demand data extracted from the facility database 220, are provided to a hospital supply spend optimizer 240, which comprises a hospital spend optimization module 241 and a mixed integer linear programming (MILP) model solver 242. The optimizer 240 calculates the minimum medical supply costs 251 for each hospital and the IDN as a whole, optimal spends on individual suppliers 252, product and quantity to be purchased from each supplier 253, tier prices qualified and assigned to each facility 254, and product substitute decision table 255. The product substitute decision table 255 is reviewed by physicians. If a physician insists on using the current clinical products (i.e., physician preferred items), a physician preferences constraint 261 is input to the optimizer 240.
The core of the hospital spend optimization module 241 is a MILP optimization model that minimizes the total acquisition cost of healthcare clinical products for an IDN as a whole. To describe the MILP model, consider an IDN comprising a set of hospitals, denoted by H. The purchasing decision is centralized at the IDN level. Let S be the set of suppliers. Each supplier s E S offers a discount schedule: Ks={1, 2, . . . }, indexed by k. A tier kϵKs is delineated by k(u,v,w,z), where u describes the required minimum market share of vendor s in a clinical product category, v represents the least combined market share, w indicates the maximum number of vendors for the combined market share, and z shows whether the market share is measured at a facility or an IDN level.
Let I be the set of products including the items currently purchased by hospitals and all the products offered by suppliers. The supplier sϵS offers a portfolio of products IsϵI. An array R records one-way product substitution relationships; a pair (i,j)ϵR indicates that item jϵIs
To minimize the total costs of medical supplies for an IDN, the hospital spend optimization module 241 minimizes the following equation:
ΣhϵHΣsϵSΣiϵI
where
xhik is the optimal quantity to be purchased by facility h at tier price k regarding item i, ∀hϵH, iϵIs, kϵKs, sϵS.
Expression (1) calculates the total costs of medical supplies in an IDN.
The optimization module 241 takes into account a plurality of constraints, including:
ΣkϵK
ΣiϵI
ΣjϵIyhij≥dhi ∀hϵH,iϵI,(i,j)ϵR (4)
ΣkϵK
where
ehsk is a binary variable; ehsk equals 1 if facility h is assigned to tier k of supplier s, and 0 otherwise, ∀hϵH, sϵS, kϵKs.
yhij is the optimal quantity of item i to be substituted by item j at facility h, ∀hϵH, iϵIs, kϵKs′, s, s′ϵS, s≠s′.
A facility in an IDN may qualify for multiple tiers offered by a supplier, but a facility shall be assigned at most one tier of a given supplier. Constraint (2) achieves this purpose by restricting a facility from having more than one tier selected from a supplier. Constraint (3) guarantees that no quantity is allocated to a tier which a facility does not qualify for or adopt. Constraints (4) and (5) state that all the demand must be satisfied.
Suppliers typically offer two levels of discount schedules: facility schedule and IDN schedule. Consider first the facility-based discount schedule, indicated by k(z)=“facility”. The following constraint ensures that if a tier k is selected, the total quantity purchased by a facility from supplier s must meet the minimum market share requirement placed on that tier. The minimum market share requirement of the supplier at tier k is indicated by k(u).
ΣiϵI
∀hϵH,kϵKs,sϵS (6)
If hospitals are restricted from purchasing more volume than the forecast demand dhi, the minimum market share requirement in constraint (6) can be simplified to a fixed minimum quantity and rewritten as:
ΣiϵI
∀hϵH,kϵKs,sϵS (7a)
The minimum combined market share requirement typically involves another one or two suppliers in addition to supplier s. When k(w)=2 (i.e., the combined market share of two suppliers), the following constraints must be met:
ΣiϵIhss′k−1)·M
∀hϵH,kϵKs,s,s′ϵS,s≠s′ (8)
e
hsk≤Σs′ϵS∩s′≠shss′k∀hϵH,kϵKs,sϵS (9)
where
hss′k is an interim binary variable; hss′k is 1 if the combined market share of suppliers s and s′ is equal to or higher than the minimum market share requirement, k(v), placed on tier k by supplier s, and 0 otherwise.
Similarly, when k(w)=3 (i.e., the combined market share of three suppliers), the following constraints must be met.
ΣiϵIhss′s″k−1)·M
∀hϵH,kϵKs,s,s′,s″ϵS,s≠s′≠s″ (10)
e
hsk≤Σ(s′,s″)ϵS∩(s′≠s″≠s)hss′s″k
∀hϵH,kϵKs,s,s′ϵS,s≠s′ (11)
where
hss″s″k is a binary variable; hss″s″k is 1 if the combined market share of three suppliers (s, s′, and s″) is equal to or higher than the minimum market share requirement placed on tier k by supplier s, and 0 otherwise.
Constraints (8) and (10) prevent a facility from choosing a tier of which the minimum combined market share requirement is not met.
Consider now the IDN-based discount schedule. To qualify for an IDN tier, the consolidated purchase of all hospitals must meet the minimum single market share requirement placed by supplier s, as described in the constraint below:
ΣhϵHΣiϵI
∀hϵH,kϵKs,s,sϵS (12)
The combined market share requirement at the IDN level may also involve two or three suppliers including supplier s. When k(w)=2 (i.e., the combined market share of two suppliers), the following constraints must be met:
ΣhϵHΣiϵI
q
sk≤Σs′ϵS∩s′≠sθss′k ∀kϵKs,sϵS (14)
where
θss′k is a binary variable; θss′k is 1 if the combined market share of suppliers s and s′ across all hospitals in an IDN meets the minimum market share requirement placed on tier k by supplier s, and 0 otherwise.
qsk is a binary variable; qsk equals 1 if the IDN qualifies for tier k offered by supplier s, and 0 otherwise.
In the case where the combined market share is measured on three suppliers (i.e., k(w)=3), the following constraints are added:
ΣhϵHΣiϵI
∀kϵKs,s,s′,s″ϵS,s≠s′≠s″ (15)
q
sk≤Σ(s′,s″)ϵS∩(s′≠s″≠s)ζhss′s″k ∀kϵKs,s,s′ϵS,s≠s′ (16)
where
ζss′s″k is a binary variable, describing whether the combined market share of three suppliers (s, s′, and s″) satisfy the minimum market share requirement placed on tier k by supplier s.
Constraints (13) and (15) guarantees that an IDN tier cannot be considered unless the minimum combined market share requirement is met.
Another complication in the medical supply tier contract is the mutually exclusive relationship between the IDN and the facility discount schedules. Constraint (2) and the following constraint combine to ensure that only one of the two discount schedules is selected.
ΣhϵHehsk≤|H|·qsk ∀ϵKs,sϵS,k(z)=IDN (17)
The MILP model (1)-(16) addresses the product substitute decision, products and quantity to be purchased from each supplier, and the optimal tier prices that each facility shall adopt such that the total medical supply costs of the IDN are minimized. The MILP model solver 242 may apply an out-of-the-box solver, such as IBM ILOG CPLEX, Gurobi, FICOR Xpress, SCIP, etc., to find an optimal or near-optimal solution to the MILP model disclosed herein for a single stand-alone hospital, a regional IDN with dozens of facilities, or even a nationwide IDN with over a hundred of member hospitals.
In the case where certain physician preferred items cannot be substituted with alternatives, the physician preference restriction 261 is input to the hospital supply spend optimizer 240. The following constraint is an example to ensure that the facility purchases physician preferred items.
ΣkϵK
where
θhi is the forecast annual demand of physician preferred item i at facility h, ∀hϵH, iϵI.
Turning to
An example process 600 for evaluating the impact of physician preference items on hospital procurement costs is presented in
The updated product substitution mapping is again reviewed to determine whether the recommended alternative products are acceptable to physicians, as described at steps 654 and 655. If a pair, including the product currently in use and the recommended replacement, is acceptable, the process repeats from step 654 unless all the pairs have been reviewed. If a pair is not acceptable, a new physician preference restriction is incorporated into the hospital supply spend optimizer and the process repeats from step 650.
At 702, in the illustrated embodiment, a computer system acquires data for vendor contracts in an integrated delivery network (IDN) where the data for vendor contracts includes tier conditions and tier prices for vendors associated with the IDN.
At 704, in the illustrated embodiment, the computer system acquires product demand data for member hospitals in the IDN.
At 706, in the illustrated embodiment, the computer system transforms the tier conditions into multi-dimensional vectors based on the data for vendor contracts to standardize the tier conditions.
At 708, in the illustrated embodiment, the computer system establishes a product substitution mapping based on the product demand data.
At 710, in the illustrated embodiment, the computer system implements a mixed integer programming model that minimizes supply costs for the member hospitals based on the multi-dimensional vectors, the product substitution mapping, and the tier prices.
At 712, in the illustrated embodiment, the computer system solves the mixed integer programming model to validate product prices charged by vendors to the member hospitals.
At 714, in the illustrated embodiment, the computer system solves the mixed integer programming model to generate specified procurement decisions based on the use of substitute products.
At 716, in the illustrated embodiment, the computer system solves the mixed integer programming model for product standardization and incorporating physician preferences.
At 718, in the illustrated embodiment, the computer system solves the mixed integer programming model to quantify the impact of physician preference items on the cost of hospital supplies.
Turning now to
In various embodiments, processing unit 850 includes one or more processors. In some embodiments, processing unit 850 includes one or more coprocessor units. In some embodiments, multiple instances of processing unit 850 may be coupled to interconnect 860. Processing unit 850 (or each processor within 850) may contain a cache or other form of on-board memory. In some embodiments, processing unit 850 may be implemented as a general-purpose processing unit, and in other embodiments it may be implemented as a special purpose processing unit (e.g., an ASIC). In general, computing device 810 is not limited to any particular type of processing unit or processor subsystem.
As used herein, the term “module” refers to circuitry configured to perform specified operations or to physical non-transitory computer readable media that store information (e.g., program instructions) that instructs other circuitry (e.g., a processor) to perform specified operations. Modules may be implemented in multiple ways, including as a hardwired circuit or as a memory having program instructions stored therein that are executable by one or more processors to perform the operations. A hardware circuit may include, for example, custom very-large-scale integration (VLSI) circuits or gate arrays, off-the-shelf semiconductors such as logic chips, transistors, or other discrete components. A module may also be implemented in programmable hardware devices such as field programmable gate arrays, programmable array logic, programmable logic devices, or the like. A module may also be any suitable form of non-transitory computer readable media storing program instructions executable to perform specified operations.
Storage 812 is usable by processing unit 850 (e.g., to store instructions executable by and data used by processing unit 850). Storage 812 may be implemented by any suitable type of physical memory media, including hard disk storage, floppy disk storage, removable disk storage, flash memory, random access memory (RAM-SRAM, EDO RAM, SDRAM, DDR SDRAM, RDRAM, etc.), ROM (PROM, EEPROM, etc.), and so on. Storage 812 may consist solely of volatile memory, in one embodiment. Storage 812 may store program instructions executable by computing device 810 using processing unit 850, including program instructions executable to cause computing device 810 to implement the various techniques disclosed herein.
I/O interface 830 may represent one or more interfaces and may be any of various types of interfaces configured to couple to and communicate with other devices, according to various embodiments. In one embodiment, I/O interface 830 is a bridge chip from a front-side to one or more back-side buses. I/O interface 830 may be coupled to one or more I/O devices 840 via one or more corresponding buses or other interfaces. Examples of I/O devices include storage devices (hard disk, optical drive, removable flash drive, storage array, SAN, or an associated controller), network interface devices, user interface devices or other devices (e.g., graphics, sound, etc.).
Various articles of manufacture that store instructions (and, optionally, data) executable by a computing system to implement techniques disclosed herein are also contemplated. The computing system may execute the instructions using one or more processing elements. The articles of manufacture include non-transitory computer-readable memory media. The contemplated non-transitory computer-readable memory media include portions of a memory subsystem of a computing device as well as storage media or memory media such as magnetic media (e.g., disk) or optical media (e.g., CD, DVD, and related technologies, etc.). The non-transitory computer-readable media may be either volatile or nonvolatile memory.
Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.
The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed herein. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims.
| Number | Date | Country | |
|---|---|---|---|
| 63142455 | Jan 2021 | US |
