Patent Application
20180330061
Advances in pharmaceutical and basic medical research have resulted in the availability of specialty drugs and new treatment protocols that give hope to many patients who previously had lacked effective treatment options. However, many of these new treatments are extremely costly, and leave insurers and other entities responsible for paying for patient care in the unenviable position of facing unsustainable costs, or denying access to powerful and beneficial treatments.
For example, specialty pharmaceutical drugs for use in the treatment of cancer, cystic fibrosis, multiple sclerosis, rheumatoid arthritis, and hepatitis C may cost anywhere from approximately ten thousand to approximately one hundred thousand dollars for a full course of treatment. Despite their nearly prohibitive costs, however, these specialty drugs can be life saving for some patients, so that simply denying access to them due to their expense is not an appropriate solution for achieving cost control.
One significant factor discouraging insurers and other healthcare payers from approving specialty drugs and other expensive treatment modalities more readily, is the cost associated with waste. Waste typically occurs because of a mismatch between a prescribed drug or treatment method and the patient receiving the treatment. For instance, certain individuals may have an adverse reaction to a drug, or may be relatively unresponsive to a particular treatment, where another patient would respond more favorably.
In addition to concern with waste, however, insurers and other healthcare payers must be cognizant of the costs associated with delaying approval of advanced treatments for some patients. For example, denial or delay of specialty drug treatment for hepatitis C may result in relatively rapid progression of advanced liver disease in some patients, resulting in the need for interventions that may be even more costly than specialty drug treatment, such as liver transplant, for example. Consequently, there is a need for a treatment recommendation solution that can determine a substantially optimal match of a patient to a medication or other therapeutic treatment, while concurrently identifying those patients who may be at the greatest risk of progressing to an advanced stage of the disease or condition from which they suffer without such treatment.
There are provided treatment recommendation systems and methods, substantially as shown in and/or described in connection with at least one of the figures, and as set forth more completely in the claims.
The following description contains specific information pertaining to implementations in the present disclosure. One skilled in the art will recognize that the present disclosure may be implemented in a manner different from that specifically discussed herein. The drawings in the present application and their accompanying detailed description are directed to merely exemplary implementations. Unless noted otherwise, like or corresponding elements among the figures may be indicated by like or corresponding reference numerals. Moreover, the drawings and illustrations in the present application are generally not to scale, and are not intended to correspond to actual relative dimensions.
As noted above, advances in pharmaceutical and basic medical research have resulted in the availability of specialty drugs and new treatment protocols that give hope to many patients who previously had lacked effective treatment options. However, and as also noted above, many of these new treatments are extremely costly, and leave insurers and other entities responsible for paying for patient care in the unenviable position of facing unsustainable costs, or denying access to powerful and beneficial treatments.
The present application addresses the financial and ethical dilemmas described above, as well as analogous challenges in the provision of healthcare treatment, by providing treatment recommendation systems and methods designed to improve clinical outcomes for insurers and other healthcare payer entities, healthcare providers, and patients. According to one implementation, such a system and method may be used to reduce or eliminate waste by determining a substantially optimal match of a patient to a medication or other therapeutic treatment. Moreover, the systems and methods disclosed in the present application advantageously enable identification of those patients who may be at the greatest risk of progressing to an advanced stage of the disease or condition from which they suffer in the absence of treatment.
In some implementations, the treatments addressed by the disclosed treatment recommendation systems and methods may be relatively new prescription drugs, such as biologics or other costly specialty drugs. It is noted that for the purposes of the present application, a “biologic” or “biological medical product” is any pharmaceutical drug manufactured in, extracted from, or at least partially synthesized from biological sources, in contrast to traditional pharmaceutical drugs that are chemically synthesized. It is further noted that, as used herein, a “specialty drug” is a costly prescription medication, which may be chemically synthesized or produced as a biologic, and is used to treat complex, chronic conditions such as hepatitis C, cancer, multiple sclerosis, and rheumatoid arthritis, for example. The cost associated with use of a specialty drug may range from a few thousand dollars, up to approximately one hundred thousand dollars, or more, for a therapeutic course of treatment.
More generally, however, the treatment recommendations generated by the systems and according to the methods disclosed in the present application may be directed a wide variety of treatment modalities. That is to say, in some implementations, the treatment recommendation systems and methods disclosed in the present application may be utilized to analyze and recommend treatment types other than specialty drug treatment, and/or may evaluate fundamentally different treatment modalities against one another. Examples of other treatment modalities include immunotherapy, gene therapy, proton therapy, robotic surgical technologies, and even the more conventional use of common prescription medications, as well as established chemotherapy and x-ray therapy protocols, to name a few.
As further shown in
According to the implementation shown in
System user 140 may utilize client system 130 to access treatment recommendation software code 110 remotely, or to download treatment recommendation software code 110 to client system 130. In one such implementation, computing platform 102 may correspond to one or more web servers, accessible over a packet-switched network such as the Internet, for example. Alternatively, computing platform 102 may correspond to one or more servers supporting a local area network (LAN), or included in another type of limited distribution network.
It is noted that although
More generally, treatment recommendation system 100 may include one or more computing platforms 102, such as computer servers for example, which may be co-located, or may form an interactively linked but distributed system, such as a cloud based system, for instance. As a result, hardware processor 104 and system memory 106 may correspond to distributed processor and memory resources within treatment recommendation system 100. Thus, it is to be understood that treatment analysis module 112, patient-to-treatment matching module 116, and patient risk forecast model 114 may be stored remotely from one another within the distributed memory resources of treatment recommendation system 100.
It is further noted that although
Treatment recommendation system 200 includes computing platform 202, which is shown to be interactively connected to client system 230 via network communication link 222. Computing platform 202 includes hardware processor 204, and system memory 206 storing treatment recommendation software code 210a. As shown in
As further shown in
Network communication link 222, and treatment recommendation system 200 including computing platform 202 having hardware processor 204 and system memory 206, correspond in general to network communication link 122, and treatment recommendation system 100 including computing platform 102 having hardware processor 104 and system memory 106, in
In addition, treatment recommendation software code 210a including treatment analysis module 212a, patient-to-treatment matching module 216a, and patient risk forecast model 214a, in
Client system 230 and display 238 correspond respectively in general to client system 130 and display 138, in
According to the exemplary implementation shown in
Client hardware processor 234 may be the central processing unit (CPU) for computing platform 232, for example, in which role client hardware processor 234 runs the operating system for client system 230 and executes treatment recommendation software code 210b. In the exemplary implementation of
It is noted that value scores 218, risk 219, and treatment recommendation(s) 228 correspond respectively in general to value scores 118, risk 119, and treatment recommendation(s) 128, in
Also shown in
According to the implementation shown in
The treatment recommendation systems discussed above by reference to
Flowchart 470 begins with receiving use case data and outcome history data for each of one or more treatments (action 471). Referring to
Aggregated data 152 and/or payer data 156 and/or provider data 162 may be received by treatment recommendation software code 110/210a/210b/310 of system 100/130/200/230/330, executed by hardware processor 104/204/234/334. As shown in
Use case data may be data describing the circumstances surrounding application of a particular treatment. Use case data may include the condition being treated, the progression or staging of the condition, the particular treatment chosen, and a duration and/or a drug dosage used to treat the condition, to name a few examples. Outcome history data may be data recording the outcome of a treatment applied in a particular use case. Thus, outcome history data may include the remission or recurrence of the condition, a response timeline of the condition to the treatment, or a result of the treatment, such as recovery of the patient, death of the patient, or abandonment of the treatment, to name a few examples. In addition, outcome history data may include data derived from clinical trials of a particular treatment, and may include risks and other patient safety information obtained during the course of such clinical trials.
As noted above, the one or more treatments for which the use case data and the outcome history data may be received can include prescription drug treatments, including drug treatments utilizing biologics and/or other costly specialty drugs. However, as an alternative to, or in addition to, drug treatments, other treatments for which the use case data and the outcome history data may be received include immunotherapy, gene therapy, proton therapy, robotic surgical technologies, and even the more conventional use of common prescription medications, as well as established chemotherapy and x-ray therapy protocols, for example.
Flowchart 470 continues with extracting medical data for patient subpopulations within a cohort of subjects diagnosed with a condition treatable using the treatments for which use case history and outcome history have been received (action 472). Any or all of aggregated data 152, payer data 156, and provider data 162 can provide medical data, as well as the use case data and the outcome history data discussed by reference to action 471.
As stated above, aggregated data 152 and/or payer data 156 and/or provider data 162 may be received by treatment recommendation software code 110/210a/210b/310 of system 100/130/200/230/330, executed by hardware processor 104/204/234/334. In addition, aggregated data 152 and/or payer data 156 and/or provider data 162 may be processed by software code 110/210a/210b/310, executed by hardware processor 104/204/234/334, to extract the medical data for the various patient subpopulations. As further stated above, aggregated data 152, payer data 156, and provider data 162 may be received by treatment recommendation software code 110/210a/210b/310 via communication network 120.
Medical data may be data describing individual patients of a cohort of subjects having a diagnosis in common, and belonging to a common patient subpopulation. For example, medical data may include the age, gender, general health, and genotype of patients diagnosed with a condition treatable by the treatments for which use case data and outcome history data have been received. In addition, medical data can include any other patient characteristics considered to be relevant to a particular diagnosis.
As a specific but non-limiting example presented for the purposes of conceptual clarity, in a particular implementation in which the diagnosed condition treatable using the treatments for which use case data and outcome history data have been received is hepatitis C, medical data for patient subpopulations within the cohort of subjects diagnosed with hepatitis C may include several parameters. For instance, medical data for a particular patient subpopulation diagnosed with hepatitis C may include the genotype common to the patient subpopulation, whether the patients having the genotype in common have previously received some form of treatment for hepatitis C, and whether the patients having the genotype in common and sharing a common treatment history have presented with cirrhosis of the liver (hereinafter “cirrhosis”).
For the exemplary implementational situation described above, four different subpopulations of patients having the same genotype can give rise to four different sets of medical data corresponding to those subpopulations: (1) patients not previously receiving some form of hepatitis C treatment and without cirrhosis, (2) patients not previously receiving some form of hepatitis C treatment and presenting with cirrhosis, (3) patients having previously received some form of hepatitis C treatment and without cirrhosis, and (4) patients having previously received some form of hepatitis C treatment and presenting with cirrhosis. Each distinct genotype could analogously contribute to four different sets of medical data corresponding to four patient subpopulations.
As a specific exemplary use case, for the hepatitis C focused implementation discussed above, medical data may be extracted for thirty-two (32) distinct patient subpopulations within the cohort of subjects having hepatitis C as a common diagnosis. An exemplary list of those 32 patient subpopulations, as well as exemplary parameters for distinguishing among the subpopulations, is provided as Appendix A of the present application. In other implementations, however, the medical data extracted by treatment recommendation software code 110/210a/210b/310 may include more parameters, such as many more parameters, than the exemplary three parameters described above. Moreover, in implementations focused on treatment of other conditions, medical data may be extracted for more, or fewer, than the exemplary 32 distinct patient subpopulations identified for hepatitis C and listed in Appendix A.
It is noted that one significant challenge to processing aggregated data 152 and/or payer data 156 and/or provider data 162 to extract the medical data is the problem of data alignment. For example, medical data included in aggregated data 152 and/or payer data 156 and/or provider data 162 may be labeled differently, or may even be incorrectly labeled. In addition, in some instances, corresponding data between two or more of aggregated data 152, payer data 156, and provider data 162 may be absent, leading to the problem of incomplete data. To overcome these challenges, computing platform 102/202/232/332 may include an adaptable memory network data structure that advantageously enables alignment of those sometimes incomplete and/or misaligned and/or incorrectly defined data into proper alignment so that medical data identification and extraction is possible.
It is further noted that the number of parameters included in the medical data extracted by treatment recommendation software code 110/210a/210b/310 in action 472, as well as the number of identified patient subpopulations, can evolve as treatment recommendation software code 110/210a/210b/310 engages in machine learning. In other words, hardware processor 104/204/234/334 may further execute treatment recommendation software code 110/210a/210b/310 to adapt and improve its treatment recommendation functionality in response to future aggregated data 152 and/or payer data 156 and/or provider data 162 received from respective treatment data aggregator 150 and/or healthcare payer data source 154 and/or healthcare provider data source 160.
Flowchart 470 continues with transforming the use case data, the outcome history data, and the medical data into value scores 118/218 corresponding respectively to a value of each of the treatments for which the use case data and the outcome history data have been received, for treatment of the condition in each of the patient subpopulations for which medical data has been extracted (action 473). Transformation of the use case data, the outcome history data, and the medical data into value scores 118/218 may be performed by treatment recommendation software code 110/210a/210b/310 of system 100/130/200/230/330, executed by hardware processor 104/204/234/334, and using treatment analysis module 112/212a/212b.
In some implementations, the transformation of the use case data, the outcome history data, and the medical data into a value score 118/218 for a particular treatment and a particular patient subpopulation may be based on a combination of an efficacy of the treatment, an adherence of the treatment, and a safety record of the treatment in the patient subpopulation, for example.
For the purposes of the present application, treatment efficacy, or simply “efficacy” (E), is a measure of the effectiveness of the treatment based on real world evidence. Efficacy is defined as the percentage of patients within a particular patient subpopulation for whom remission or recovery occurs after completion of the treatment protocol. Returning to the example in which hepatitis C is the condition being treated, and where a particular treatment is drug therapy using “Drug A”, efficacy may be expressed as follows:
E(%)=NSVR_12_0/NSP*100 (Equation 1)
Where: SVR 12 is the Sustained Virological Response on a gap of twelve weeks after completion of a prescribed treatment period, NSVR_12_0 is the number of patients within a subpopulation for whom SVR 12 is substantially zero, or negligible, and N5 is the total number of patients in the patient subpopulation receiving the treatment.
Treatment adherence, or simply “adherence” (A), is a measure of the degree with which patients tend to comply with a particular treatment. In the case of drug treatment, one measure of adherence is the ratio of the drug dosage actually consumed by patients over a treatment period to the prescribed dosage over the treatment period. It is noted that adherence is an aggregated measure across all patients within a subpopulation receiving the same treatment. For example, adherence with respect to a drug treatment may be determined using the medication possession ratio (MPR), as known in the art, for a patient subpopulation treated using the same drug.
Treatment safety, or simply “safety” (S), may be determined based on the rate at which known complications of a particular treatment have historically manifested themselves in the patient subpopulation. Moreover, in some implementations, safety may be determined based on the costs associated with intervening to remedy those complications, or with a hospitalization rate of members of the patient subpopulation during or immediately after the treatment.
Value score (V) 118/218 of a particular treatment may be determined using a weighted or non-weighted combination of efficacy, adherence, and safety, as follows:
V=(w1*E+w2*A+w3*S)/[100*(w1+w2+w3)]*10 (Equation 2)
Where w1, w2, and w3, are fractional weighting factors in a range between zero and one, inclusive of one, and are applied respectively to efficacy, adherence, and safety. It is noted that where value score 118/218 is determined using a non-weighted combination of efficacy, adherence, and safety, each of w1, w2, and w3 may be set equal to one (w1=w2=w3=1). It is further noted that in implementations in which value score 118/218 is determined using a weighted combination of efficacy, adherence, and safety, the weighting factors w1, w2, and w3 may be predetermined and fixed within treatment recommendation software code 110/210a/210b/310, or may be selectable or adjustable by a user, such as system user 140. That is to say, in some implementations, system user 140 may have discretion to increase or reduce weighting factors w1, w2, and w3 relative to one another.
In addition to efficacy, adherence, and safety, in some implementations, value score 118/218 may be further determined based on a cost of the treatment and/or overall utilization of the treatment among members of the patient subpopulation, for example. Treatment cost, or simply “cost” (C) is the cost of the treatment over the prescribed treatment period. For example, the cost of a drug treatment administered daily for ten weeks is the cumulative cost of the entire prescribed drug dosage over the ten week treatment period.
Treatment utilization, or simply “utilization” (U), is defined as the number of patients within a given patient subpopulation to whom a particular treatment has been prescribed, divided by the total number of patients making up the patient subpopulation. Thus, utilization of treatment “X” may be expressed as a percentage as follows:
U
X(%)=NX/NTSP*100 (Equation 3)
Where: NX is the number of patients within the patient subpopulation to whom treatment X has been prescribed, and NTSP is the total number of patients making up the patient subpopulation. It is noted that Equation 2 can be modified to include weighted or non-weighted contributions based on cost and/or utilization.
Thus, it is emphasized that in some implementations, system user 140 may select the variables included in Equation 2 and used to determine value score 118/218, and/or may select the weighting applied to the included variables by Equation 2. As a result, treatment recommendation software code 110/210a/210b/310 may be executed by hardware processor 104/204/234/334 to evaluate each treatment for each patient subpopulation in a way that balances the interests of the different parties, i.e., insurers or other healthcare payer entities, healthcare providers, and patients, affected by the resulting treatment recommendation.
Flowchart 470 continues with receiving a query for treatment of the condition treatable using the treatments for which use case history and outcome history have been received, in a patient identified with one of the patient subpopulations (action 474). Such a query may be received by treatment recommendation software code 110/210a/210b/310 of system 100/130/200/230/330, executed by hardware processor 104/204/234/334. For example, in the case of treatment recommendation software code 110/210a executed by hardware processor 104/204, the query may be received via communication network 120, over network communication link 122/222. Alternatively, in the case of treatment recommendation software code 210b/310 executed by hardware processor 234/334, the query may be received via inputs from system user 140 to client system 130/230 or to system 330.
The query may include identification of the condition for which treatment is being recommended, and patient data sufficient to evaluate the treatment, for example. It is noted that computing platform 102/202/232/332 is configured to run complex queries on often large datasets based on a large number of variables. Computing platform 102/202/232/332 includes optimizations in memory networking to enable real-time responsiveness with respect to receipt of a query from system user 140.
For example, in some implementations, computing platform 102/202/232/332 includes an adaptable memory network to run the queries a priori and hashes the results in a hash table. Based on the queries, database access can be substantially minimized, thereby advantageously enabling treatment recommendation system 100/130/200/230/330 to respond more quickly. Such an implementation effectively results in an adaptable hardware implementation of a software cache.
Flowchart 470 continues with forecasting risk 119/219 that the condition will progress to an advanced stage for the patient who is the subject of the query (action 475). Forecasting of risk 119/219 may be performed by treatment recommendation software code 110/210a/210b/310 of system 100/130/200/230/330, executed by hardware processor 104/204/234/334, and using patient risk forecast model 114/214a/214b.
Continuing with the hepatitis C focused exemplary implementation introduced above, the presence of cirrhosis in a patient having hepatitis C can foreshadow or accompany progression to advanced liver disease. As a result, patients who are not yet cirrhotic but for whom the development of cirrhosis is likely, as well as those presenting with cirrhosis, are at higher risk of having their condition progress to advanced liver disease. Thus, in implementations in which the condition for which a treatment recommendation is sought is hepatitis C, patient risk forecast model 114/214a/214b may be used to forecast risk 119/219 that a patient as yet not presenting with cirrhosis, will develop cirrhosis, and is thereby likely to progress to advanced liver disease, perhaps requiring liver transplant.
In some implementations, treatment recommendation software code 110/210a/210b/310 may utilize patient risk forecast model 114/214a/214b to forecast risk 119/219 based on predetermined the cirrhosis predictive parameters. For example, in one implementation, the following parameters may be predetermined to by cirrhosis predictive parameters (pi) for use in forecasting risk 119/219:
Risk 119/219 may be forecast using a weighted combination of such cirrhosis predictive parameters, for example. The values of those weighting factors may be determined through an initial training of patient risk forecast model 114/214a/214b. As an example, cirrhosis prediction data structure 114/214 of initially trained cirrhosis forecast model 112/212 may include the following expression for the probability that cirrhosis is present or substantially imminent for a subject:
Where C is a constant, the pi are the cirrhosis predictive parameters identified above, and the wi are their respective weighting factors determined using logistic regression.
As an even more specific example, when the exemplary cirrhosis predictive parameters listed above on are a complete set of cirrhosis predictive parameters, K may take the form:
K=C+w
1
p
1
+w
2
p
2
+w
3
p
3
+w
4
p
4
+w
5
p
5
+w
6
p
6
+w
7
p
7
+w
8
p
8 (Equation 5.1)
As shown in
It is reiterated that the exemplary risk forecasting described above by reference to action 475 and
In some implementations, flowchart 470 may conclude with generating one or more treatment recommendation(s) 128/228 for the patient based on value scores 118/218 and risk 119/219 (action 476). Treatment recommendation(s) 128/228 may be generated by treatment recommendation software code 110/210a/210b/310 of system 100/130/200/230/330, executed by hardware processor 104/204/234/334, and using patient-to-treatment matching module 116/216a/214b.
It is noted that although the exemplary implementation shown in
Also shown in
It is noted that, “Treatment A” has the highest adherence among treatments “A”, “B”, and “C”, the lowest cost among treatments “A”, “B”, and “C”, and a relatively high efficacy. Consequently, if treatment recommendation(s) 128/228 were generated based on value scores 118/218 substantially alone, either because risk 119/219 is very low or is disregarded, “Treatment A” would likely be recommended to the exclusion of treatments “B” and “C” due to its substantially lower cost. In other words, use of a treatment recommendation system that does not consider risk 119/219 may result in approval of “Treatment A” for a patient, but denial of “Treatment B” having the highest efficacy, due to its higher cost.
However, according to the present inventive principles, risk 119/219 to the patient is factored in to generating treatment recommendation(s) 128/228. Assuming that risk 119/219 is forecast as being relatively high for the patient for whom the query was received in action 474, highest efficacy “Treatment B” is also a recommended treatment, despite its relatively high cost. Consequently, use of system 100/130/200/230/330 to generate treatment recommendation 128/228 can advantageously result in approval of “Treatment B” for the patient due to identification of the patient as being especially in need of a highly effective treatment.
Thus, the systems and methods disclosed in the present application address serious financial and ethical dilemmas posed by decisions to permit or deny patient access to extremely costly but highly effective treatments. The disclosed systems and methods may be used to reduce or eliminate waste by determining a substantially optimal match of a patient to a medication or other therapeutic treatment. In addition, the systems and methods disclosed in the present application advantageously enable identification of those patients who may be at the greatest risk of progressing to an advanced stage of the disease or condition from which they suffer. Consequently, the systems and methods disclosed in the present application can play an important role in enabling seriously and/or chronically ill patients to have greater access to effective treatments for the conditions that afflict them, thereby improving clinical outcomes for insurers, healthcare providers, and patients alike.
From the above description it is manifest that various techniques can be used for implementing the concepts described in the present application without departing from the scope of those concepts. Moreover, while the concepts have been described with specific reference to certain implementations, a person of ordinary skill in the art would recognize that changes can be made in form and detail without departing from the scope of those concepts. As such, the described implementations are to be considered in all respects as illustrative and not restrictive. It should also be understood that the present application is not limited to the particular implementations described herein, but many rearrangements, modifications, and substitutions are possible without departing from the scope of the present disclosure.
