WO2020168018A1

WO2020168018A1 - Medication return platform for managing returns of excess medications

Info

Publication number: WO2020168018A1
Application number: PCT/US2020/018016
Authority: WO
Inventors: Darin T. Okuda
Original assignee: University of Texas System; University of Texas at Austin
Current assignee: University of Texas System; University of Texas at Austin
Priority date: 2019-02-13
Filing date: 2020-02-13
Publication date: 2020-08-20
Anticipated expiration: 2021-08-13

Abstract

A medication return platform for managing returns of excess medications receives shipments of excess medications from users and re-distributes and/or disposes the excess medications. To facilitate the return process, the medication return platform may compensate users for returned medications. Compensation may be received from subscribers that purchase unexpired excess medications for re-distribution. The medication return platform may distribute user health information collected during the medication return process to providers and subscribers to provide accurate feedback on the benefits and side effects of medications.

Description

MEDICATION RETURN PLATFORM FOR MANAGING RETURNS OF EXCESS

MEDICATIONS

RELATED APPLICATIONS/PRIORITY CLAIMS

[0001] This application claims the benefit under 35 USC 119(e) and 120 of U.S. Provisional Application No. 62/804,848 filed Feb 13, 2019, and which is incorporated herein by reference.

FIELD

[0002] The disclosure relates generally to systems and methods of returning, verifying, authorizing, managing and re-distributing excess pharmaceuticals.

BACKGROUND

[0003] Treating life altering medical conditions is extremely expensive. Patients and insurance companies must cover costs for treatment including disease modifying therapies (DMTs), prescribed symptomatic treatments, scheduled and unscheduled office visits, urgent care or emergency room evaluations, hospitalizations, physical, occupational, or speech therapies, supportive devices, healthcare costs associated with adverse reactions to prescribed

immunomodulatory or immunosuppressive treatments, long-term care, and the like. In many cases, the most significant costs are obtaining new, state of the art pharmaceuticals and other DMTs. Manufacturers justify the high costs of DMTs based on the tremendous R&D costs associated with new drug development, the low success rate of drug development programs, and the ability of a new agent to dramatically transform the treatment landscape and offset other healthcare costs.

[0004] Manufactures may have near monopoly power to charge whatever they want for newly developed drugs for a limited period of time. Therefore, the cost of DMTs are well above inflation. For example, the increase in annual costs for multiple sclerosis (MS) DMTs is about 5- 7 times higher than prescription drug inflation. Between 2008 and 2012, the sales of the available treatments for MS increased from $4 billion to approximately $9 billion annually. For many conditions, several treatments exist and most patients must try more than one drug before discovering an effective treatment for their condition. The tendency of patients to switch between existing therapies and try new drugs once they are approved compounds the high cost of DMTs.

[0005] Once a physician prescribes a particular DMT, patients are typically able to acquire a 1 to 3-month supply of the prescribed drug. In the event a decision is made to switch to another treatment, the remaining supply of the previously filled prescription is wasted. Typically, the amount of surplus medication that a patient may have may range from 1 to 89 days. In many cases, patients may receive a refill for their treatment a week into their prescription. Therefore, in many instances, patients may obtain more than 90-day surplus supply of medication. Excess medication may also be obtained by patients who continue on a treatment while waiting for insurance approval for their next DMT. These patients may need to refill their original drug even after they are prescribed a new treatment because timely approvals of new DMTs by insurance companies are uncertain. Once the new DMT is approved, the patient may be stuck with an excess supply of the original drug. Additionally, some patients may continue to refill their medication without taking it. Patients who represent to family and their physician that they are taking their medication without actually taking it may have up to six months or more of unused medication.

[0006] Once distributed to patients, the use of excess medications is unregulated and there is no legal market for re-distributing unused medication. Unused DMTs are commonly discarded in the trash, flushed down the toilet, stored within refrigerators in the homes of patients, and the like. Additionally, within some condition support groups, DMTs may be given to other members to use or even to try before a treatment switch is requested by their healthcare provider. In other instances, excess drugs are exchanged illegally on online forums. The true prevalence of patients switching to another disease modifying therapy is unknown but the current evidence suggests that approximately 35% of patients transition to another treatment annually. Testing DMTs that are not approved by healthcare providers can lead to dangerous side effects. Additionally, with no efficient system for returning or re-distributing unused DMT tens of millions of dollars worth, if not more, of excess DMTs are wasted every year.

[0007] The proper disposal of unused medication is a critical component of the drug lifecycle. Despite the importance of proper disposal and re-distribution of excess drugs, most unused DMTs are illegally re-distributed, disposed in a local landfill, or flushed into a local water supply. Illegal re-distribution creates health and safety risks for patients that self-medicate. Discarding drugs in the trash and/or flushing medications by patients who have no experience with chemical waste and/or knowledge of drug specific disposal guidelines leads to harmful environmental impacts. DMTs are powerful chemicals that can significantly alter biological systems. Drug metabolites can have significant impacts on animals and microorganisms within the environment. Despite highly effective water treatment facilities, small concentrations of pharmaceuticals have consistently been found in our water sources and treated drinking water. Few studies have investigated the long term impact of exposure to trace amounts of DMTs so unique combinations of various compounds could have unanticipated effects on humans, wildlife and other aspects of the environment. SUMMARY

[0008] In one aspect, disclosed herein are methods of managing excess medications comprising: providing a medication return platform having a graphical user interface that is remotely accessible by a plurality of users; receiving, by the medication return platform, user data including medical information and excess distributed medication information from a user included in the plurality of users; verifying, by the medication return platform, accuracy of the excess distributed medication information; generating, by the medication return platform, a shipping label and a return authorization from for the user; receiving, from the user, a completed return authorization form and a shipment of medication sent using the shipping label; matching, by the medication return platform, the verified excess distributed medication information with the shipment of medication; and distributing, by the medication return platform, compensation for the shipment of medication.

[0009] In one aspect, the medical information includes condition history and treatment history relating to multiple sclerosis, glioblastoma multiforme, Parkinson’s disease, rheumatoid arthritis, systemic lupus erythematosus, psoriatic arthritis, ankylosing spondylitis, multiple myeloma or other forms of cancer, neuromyelitis optica spectrum disorder, sleep disorders, cystic fibrosis, hematological malignancies, Alzheimer’s disease or other neurodegenerative or neurological conditions, hemophilia, hepatitis, HIV/AIDS, Crohn’s disease, ulcerative colitis, solid organ tumors, organ transplants, hereditary amyloidosis, metabolic deficiencies, hormonal

deficiencies, pulmonary hypertension, hypercholesterolemia, spinal muscular atrophy, muscular dystrophies, or other muscle disorders.

[0010] In one aspect, the graphical user interface is provided by smartphone, tablet or personal computer. In one aspect, the compensation is a donation to a charity selected by the user. In one aspect, the compensation is an electronic payment to the user comprising a bank wire, automatic deposit, account credit, or redeemable points.

[0011] In one aspect the verifying further comprises: transmitting the excess distributed medication information to a provider; receiving, from the provider, verification information about the excess distributed medication; receiving, from the user, an image of a medication described in the excess distributed medication information; and matching the verification information received from the provider with the image of the medication and the excess distributed medication information.

[0012] In one aspect, the image of the medication includes a LOT number and expiration information. In one aspect, the provider is a healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, or government healthcare system.

[0013] In one aspect, the method further comprises: receiving compensation information from the user; and authorizing, by the medication return platform, the compensation for the shipment of medication in response to verifying a condition of the shipment of medication and validating the compensation information.

[0014] In one aspect, the method further comprises: generating, by the medication return platform, a subscriber notification including one or more pieces of data included in the user data; distributing, by the medication return platform, the subscriber notification to a subscriber; in response to the distributing, receiving payment for the shipment of medication from the subscriber; and distributing, by the medication return platform, the shipment of medication to the subscriber.

[0015] In one aspect, the subscriber is a patient, healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, or government healthcare system.

[0016] In one aspect, disclosed herein are systems for managing excess medications, comprising: a processor and memory connected to each other; a display connected to the processor; and a plurality of lines of instructions stored in the memory and executed by the processor that is configured to: provide, on the display, a medication return platform having a graphical user interface that is remotely accessible by a plurality of users; receive, by the system for managing excess medications, user data including medical information and excess distributed medication information from a user included in the plurality of users; verify, by the system for managing excess medications, accuracy of the excess distributed medication information; generate, by the system for managing excess medications, a shipping label and a return authorization from for the user; receive, from the user, a completed return authorization form and a shipment of medication sent using the shipping label; match, by the system for managing excess medications, the verified excess distributed medication information with the shipment of medication; and distribute, by the medication return platform, compensation for the shipment of medication.

[0017] In one aspect, the medical information includes condition history and treatment history relating to multiple sclerosis, glioblastoma multiforme, Parkinson’s disease, rheumatoid arthritis, systemic lupus erythematosus, psoriatic arthritis, ankylosing spondylitis, multiple myeloma or other forms of cancer, neuromyelitis optica spectrum disorder, sleep disorders, cystic fibrosis, hematological malignancies, Alzheimer’s disease or other neurodegenerative or neurological conditions, hemophilia, hepatitis, HIV/AIDS, Crohn’s disease, ulcerative colitis, solid organ tumors, organ transplants, hereditary amyloidosis, metabolic deficiencies, hormonal deficiencies, pulmonary hypertension, hypercholesterolemia, spinal muscular atrophy, muscular dystrophies, or other muscle disorders.

[0018] In one aspect, the processor is further configured to verify accuracy of the distributed excess medication information by: transmitting the excess distributed medication information to a provider; receiving, from the provider, verification information about the excess distributed medication; receiving, from the user, an image of a medication described in the excess distributed medication information; and matching the verification information received from the provider with the image of the medication and the excess distributed medication information· [0019] In one aspect, the image of the medication includes a LOT number and expiration information. In one aspect, the provider is a healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, or government healthcare system.

[0020] In one aspect, the processor is further configured to: receive compensation information from the user; and authorize, by the system for managing excess medications, compensation for the shipment of medication in response to verifying a condition of the shipment of medication and validating the compensation information.

[0021] In one aspect, the processor is further configured to: generate, by the system for managing excess medications, a subscriber notification including one or more pieces of data included in the user information; distribute, by the system for managing excess medications, the subscriber notification to a subscriber; in response to the subscriber notification, receive compensation for the shipment of medication from the subscriber; and distribute, by the system for managing excess medications, the shipment of medication to the subscriber.

[0022] In one aspect, the subscriber is a patient, healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, or government healthcare system.

[0023] In one aspect, disclosed herein are methods of managing excess medications comprising: providing a medication return platform having a graphical user interface that is remotely accessible by a plurality of users; receiving, by the medication return platform, user data including medical information and excess distributed medication information from a user included in the plurality of users; verifying, by the medication return platform, accuracy of the excess distributed medication information; generating, by the medication return platform, a shipping label and a return authorization from for the user; receiving, from the user, a completed return authorization form and a shipment of medication sent using the shipping label; matching, by the medication return platform, the verified excess distributed medication information with the shipment of medication; and based on the matching, accepting, by the medication return platform, the shipment of medication for re-distribution.

BRIEF DESCRIPTION OF THE FIGURES

[0024] FIG. 1 illustrates an exemplary system for managing excess medications according to various embodiments of the present disclosure.

[0025] FIG. 2 illustrates more details of an exemplary medication verification system according to various embodiments of the present disclosure.

[0026] FIG. 3 illustrates more details of an exemplary medication management system according to various embodiments of the present disclosure.

[0027] FIGS. 4A-G illustrate exemplary graphical user interfaces (GUIs) for collecting user data according to various embodiments of the present disclosure.

[0028] FIGS. 5A-D illustrate exemplary GUIs for generating a shipping label and shipping excess medications according to various embodiments of the present disclosure.

[0029] FIGS. 6A-E illustrate exemplary GUIs for collecting medical information according to various embodiments of the present disclosure.

[0030] FIG. 7 is a flow chart illustrating an exemplary method of returning excess medications according to various embodiments of the present disclosure.

[0031] FIG. 8 is a flow chart illustrating an exemplary method of re-distributing returned medications according to various embodiments of the present disclosure.

[0032] FIG. 9 is an exemplary computer system implementing a client device or other computer implemented component of the exemplary system shown in FIG. 1 according to various embodiments of the present disclosure.

DETAILED DESCRIPTION OF SEVERAL EMBODIMENTS

[0033] Disclosed herein are systems and methods for recovering, returning, and managing, partially used and unused medications for a variety of conditions. In various embodiments, the medication return platform facilitates collaboration between patients, healthcare providers, pharmacies, insurance providers, government agencies, government healthcare systems, drug manufactures and other pharmaceutical industry stakeholders to manage collection and re distribution of used medications. The return platform may automate aspects of the drug collection, verification, reimbursement, and re-distribution process to enable unused medications to be returned and re-distributed efficiently. The return platform may also include a notification system for notifying drug manufactures, healthcare providers, insurance companies, and pharmacies when a patient switches to a new medication to reduce the amount of unwanted medications distributed to patients. Data collected by the return platform may also be distributed to subscribers of the medication return platform. Subscribers may include, for example, patients, healthcare providers, health insurance companies, pharmacies, pharmaceutical manufacturers, pharmacy benefit managers, government agencies, and the like. Data distributed to the subscribers may be used to predict effective treatments for patients, track the effectiveness and side effects of therapies, determine the number of patients switching from and/or using a particular medication, streamline insurance approval for new medications, improve the efficiency of drug manufacturing supply chains, more precisely manage pharmaceutical inventories, and the like.

[0034] As described herein, the terms“medication”,“medications”,“drug”, and“drugs” may refer to any DMT and/or symptomatic or preventative treatment for any condition including, for example, multiple sclerosis, glioblastoma multiforme, Parkinson’s disease, rheumatoid arthritis, systemic lupus erythematosus, psoriatic arthritis, ankylosing spondylitis, multiple myeloma and other forms of cancer, neuromyelitis optica spectrum disorder, sleep disorders, cystic fibrosis, hematological malignancies, Alzheimer’s disease and other neurodegenerative or neurological conditions, hemophilia, hepatitis, HIV/AIDS, Crohn’s disease, ulcerative colitis, solid organ tumors, organ transplants, hereditary amyloidosis, metabolic deficiencies, hormonal

deficiencies, pulmonary hypertension, hypercholesterolemia, spinal muscular atrophy, muscular dystrophies, and other muscle disorders.

[0035] As described herein, the term“medical information” may refer to treatment condition history and treatment history relating to any condition including, for example, multiple sclerosis, glioblastoma multiforme, Parkinson’s disease, rheumatoid arthritis, systemic lupus

erythematosus, psoriatic arthritis, ankylosing spondylitis, multiple myeloma and other forms of cancer, neuromyelitis optica spectrum disorder, sleep disorders, cystic fibrosis, hematological malignancies, Alzheimer’s disease and other neurodegenerative or neurological conditions, hemophilia, hepatitis, HIV/AIDS, Crohn’s disease, ulcerative colitis, solid organ tumors, organ transplants, hereditary amyloidosis, metabolic deficiencies, hormonal deficiencies, pulmonary hypertension, hypercholesterolemia, spinal muscular atrophy, muscular dystrophies, and other muscle disorders..

[0036] As described herein, the term“excess medication information” may refer to any information describing or related to medication returned by a patient including for example, a medication description, patient information, patient insurance information, medication information, treatment start date, and other medical information related to the returned medication, and the like. [0037] FIG. 1 shows a system for managing excess medications according to various embodiments of the present disclosure. System 100 may include a plurality of functional elements that may be provided by mechanical components, electrical components, and or computing devices. These elements may work together to collect unused medications from a patient 110, verify the amount, authenticity, expiration data, and the like of collected

medications, send notifications to patients and entity subscribers, facilitate reimbursement for verified medications, and re-distribute collected medications to new patients. The elements may also collect data about patients, disease conditions, therapies, drug distribution logistics, and the like. Data collected by the system 100 may be distributed to industry stakeholders and other subscribers to the medication return platform.

[0038] For example, system 100 may include at least one client 160. Client 160 may be any device configured to present graphical user interfaces (GUIs) 162 and receive inputs thereto in the GUIs 162. For example, client 160 may be a smartphone, personal computer, tablet, laptop computer, or other device.

[0039] System 100 may include a medication verification system 120. In some embodiments, the medication verification system 120 may include one of more mechanical, electrical, and/or software elements that facilitate collecting unused medications from patients 110. The medication verification system 120 may interface with a medication repository 115 or other provider, for example, a pharmacy, hospital, drug wholesaler, and the like, to verify one or more aspects of medications and determine if the medications can be re-used. Upon verification, the medication verification system may generate a shipping label for a patient 110 use to return unused medications. In some embodiments, the medication verification system 130 may include one or more hardware and/or software components that may be accessible to the client 160 through a network 140 in some embodiments (e.g., a verification module of the medication verification system 120 may be hosted by a server computer).

[0040] System 100 may include a medication management system 130. In various embodiments, the medication management system 130 may be integrated with the medication verification system 120 and/or the medication repository 115 receiving the shipment of unused medications from the patient 110. The medication management system 130 may include one of more mechanical, electrical, and/or software elements that analyze medication shipments to authorize compensation for unused medications. If compensation is authorized, the medication

management system 130 may receive reimbursement funds from a subscriber 135, for example, a patient, healthcare provider, health insurance company, pharmacy, pharmaceutical

manufacturer, pharmacy benefit manager, government agency, government healthcare system, and the like and distribute compensation. Compensation may include, for example, a donation to a charity, a reimbursement payment to the patient, or any other form of compensation. The medication management system 130 may also generate and distribute notifications to one or more subscribers upon receiving a medication shipment, authorizing compensation for returned medications, or some other triggering event. In some embodiments, the medication management system 130 may include one or more hardware and/or software components that may be accessible to the client 160 through a network 140 in some embodiments (e.g., an authorization module of the medication management system 130 may be hosted by a server computer).

[0041] In some embodiments, one or more clients 160 may communicate with one or more medication verifications systems 120 and/or medication management systems 130 through a network 140. For example, communication between the elements may be facilitated by one or more application programming interfaces (APIs). APIs of the system 100 may be proprietary and/or may be examples available to those of ordinary skill in the art such as Amazon^® Web Services (AWS) APIs, Google APIs, and the like. Network 140 may be the Internet and/or other public or private networks or combinations thereof.

[0042] A single client 160 and separate, single medication management system 130, and/or medication verification system 120 are shown for ease of illustration, but those of ordinary skill in the art will appreciate that these elements may be embodied in different forms for different implementations. For example, system 100 may include a plurality of clients 160, many of which may access different data. Moreover, a single medication verification system 120 and/or medication management system 130 be components of a single computing device or a combination of computing devices may provide a single medication verification system 120 and/or medication management system 130. In some embodiments, the operations performed by client 160 and at least one of the separate, single medication verification systems 120 and/or medication management systems 130 may be performed on a single device (e.g., without the various components communicating using network 140 and, instead, all being embodied in a single computing device).

[0043] FIG. 2 illustrates an exemplary medication verification system 120. As shown, the medication verification system 120 may receive user data 202, perform a verification analysis, and based on the verification analysis generate a shipping label 242. Patients may use the shipping label to return unused medications to a medication repository. The shipping label 242 may include embedded information identifying the patient and/or medication shipment. For example, the shipping label 242 may include a QR code, bar code, or other form of machine readable information containing user data 202. Embedded machine readable user data 202 included the shipping label 242 may be read by the medication management system to facilitate authorizing compensation for medication shipments and notifying patients and entities of the status of the medication return.

[0044] User data 202 may include patient information 204, insurance information 206, treatment history 208, medication description 210, condition history 212, and other medical information and/or excess medication information. User data 202 may be collected using one or more GUIs included in the medication return platform and management system. For example, condition history 212 may be collected using one or more condition history GUIs including questionnaires for eliciting condition history information from patients. Patient information 204 may include user identification information (e.g., user name, password, security pin, account information, and the like) for a patient’s user account on the medication return platform. Patient information 204 may also include personal identification information (e.g., name, address, city, state, zip code, email address, date of birth, social security number, and the like) and compensation information (e.g., bank account number, routing number, credit card number, charity name, charity address, charity payment information, and the like). Insurance information 206 may include provider name, name of policy holder, policy number, group number, date of birth, pharmacy name, and any other information required to identify the insurance policy of the patient. Patient information and insurance information may be used by the medication return platform to, for example, generate shipping labels, process reimbursement payments, charity donations, and other compensation for returned medications, notify insurance companies of medication changes for policy holders, and the like.

[0045] User data 202 may also include information about the patient’s treatments and conditions. Treatment history 208 may include records of previous drugs and other treatments used by the patient for a particular condition. For example, treatment history 208 may include the medical condition associated with a prescribed treatment, the name (e.g., brand name and/or chemical name) of the treatment the patient would like to return, the side effects and benefits of the treatment, and the like. Medication description 210 may describe the unused medications, the patient is returning. For example, medication description 210 may include the quantity of pills, capsules, syringes, and/or other medication units the patient is returning, the lot number of the medication, the batch number of the medication, the expiration date of the medication, and the like. Patients may also be asked to provide condition history 212 about one or more conditions associated with the medication returned by the patient. Condition history 212 may include the date the patient was diagnosed with the condition, the reason the patient is switching treatments, the date the patient started the treatment she is returning, previous treatments used by the patient, the side effects and/or benefits of using the previous treatments, the date the patient first experienced symptoms related to her condition, the date the patient experienced a recent setback associated with her condition, the treatments the patient has been exposed to, and the like.

[0046] Once collected, user data 202 may be received by the medication verification system 130. User data may be processed by the verification module 230 to verify the patient’s identity, the condition of the returned medication, if the returned medication can be accepted by the medication repository, and the like. To facilitate verification, the patient may be asked to submit a photo or other medication image data 220. For example, an image of the returned medication may be used to verify the condition of the unused medication possessed by the patient and confirm the medication description (e.g., quantity, expiration date, and the like) and other excess medication information are accurate. Medication image data 220 received from patients may be stored in an image database 222 and provided to the medication verification system 120.

[0047] To verify the condition and description of the returned medication, the verification module 230 may compare the medication description 210 to the medication image data 220. To facilitate the comparison, the verification model 230 may extract one or more fields of data from the medication image data using ocular character recognition (OCR) techniques, machine learning based entity extraction techniques, or other automated image processing techniques.

The condition of the medication, medication description 210 and other excess medication information may be verified by comparing the medication description information included in the medication image data 220 to the medication description 210. For example, the verification module 230 may be able to recognize a distinct font on the medication bottle and/or bar codes, QR codes, color scheme or distinct hex colors that appear on the medication and/or medication packaging shown in the medication image data 220. As described below, the verification module 230 may also process the LOT numbers and corresponding expiration dates included in the medication image data 220 to confirm with the drug manufacturer that the returned medication is authentic.

[0048] The verification module 230 may also verify the condition of the medication, the medication description 210, and other excess medication information by searching the medication description 210 against one or more databases of medication information. Once the quantity, condition, expiration information, and/or other excess medication information for the medication has been verified, the verification module 230 may verify the identity of the patient, and/or determine if the medication can be accepted by the medication repository. The verification module 230 may determine if the medication can be accepted by comparing the verified medication description 210 to one or more criteria. For example, to be accepted by the medication repository, the medication: must include a minimum number of units, must be a treatment for a certain type of condition, must be specific brand name or chemical class of treatment, must be manufactured by a certain drug manufacturer, must be covered by a certain insurance provider, must be in good condition, must not have an expiration date that is expired, must have an expiration date that expired within a certain period of time, must be located within a certain distance from the medical repository, and the like.

[0049] The verification module 230 may also verify the identity of the patient, the medication description 210, and other excess medication information and/or determine whether to accept the medication based on verification information received from a provider or subscriber. To obtain verification information, the verification module 230 may transmit user data 202 including, for example, the medication description 210, patient information 204, insurance information 206, treatment history 208, and/or condition history 212 and other excess distributed medication information to a provider, for example, a healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, government healthcare system, and the like. The verification module 230 may then receive verification information for the patient and/or medication from the provider. Verification information may include, for example, LOT numbers and corresponding expiration dates received from drug manufactures. Verification information may also include prescription information that verifies the patient was prescribed a returned medication received from the patient’s health insurance company and/or pharmacy. Verification information can also include dates the patient started treatment and other medical information (e.g., treatment history data, condition history, and the like) received from the patient’ s physician or other healthcare provider.

[0050] After receiving the verification information from the provider, the verification module 230 may then verify the patient’s identity, medication condition, medication description 210 and/or other excess medication information by matching the verification information received from the provider with the user data 202 received from the patient and/or the image of the excess medication. For example, the verification module 230 may match the patient name and/or prescription date pictured on the medication label and/or included in the medication description 210 and other excess distributed medication information with the patient name and prescription date included in prescription information obtained from the patient’ s health insurance company and/or pharmacy. The verification module 230 may also match the LOT number and expiration dates included in an image of the label on a medication bottle or package with the LOT number and expiration date received from the drug manufacturer. The verification module 230 may also match the patient’s date of diagnosis and starting date of treatment with the patient’s medication information received form the healthcare provider. [0051] If the verification model 230 determines the submitted medication can be accepted by the medication repository, the verification module 230 may cause the shipping module 240 to generate a shipping label 242. If the verification module 230 determines the submitted medication cannot be accepted by the medication repository, the verification module 230 may notify the user/patient of the medication’s deficiency. To generate the shipping label 242, the shipping module 240 may read user data 202 to extract the patient’s name, address, city, state, zip, and other shipping information from the patient information 204. The shipping module 240 may then automatically populate the patient’ s return address and shipping address for the medication repository into the shipping label 242. The shipping module 240 may also embed additional user data 202 into the shipping label or other label assigned to the medication shipment. To embed additional user data 202, the shipping module 242 may generate a QR code, bar code, or other form of machine readable information containing user data 202. The code including embedded user data 202 may then be added to the shipping label and/or added separately to the medication shipment. Embedded user data 202 may facilitate processing of the medication shipment once it is received from the patient. For example, embedded compensation information included in a QR code may facilitate distributing reimbursement payments to the patient, donations to a charity, and other compensation.

[0052] FIG. 3 illustrates an exemplary medication management system 130. As shown, the medication management system 130 may receive medication shipments 302 from patients.

Based on the analysis of the medication shipment 302 performed by the authorization module 320, the medication management system 130 may generate user notifications 332 and entity notifications 334. The medication management system 130 may also authorize and distribute compensation 342. Compensation 342 may include payments to patients and/or insurance companies as reimbursement for the costs of the returned medications, donations to charity, and the like. User notifications 332 may update patients on the status of their returned medications. Entity notifications 334 may be distributed to healthcare providers, pharmacies, insurance companies, drug manufacturers, and the like to help entities adjust to changes in the number of patients using a particular treatment. The notifications may include treatment history, condition history, and other user data received from the medication verification system. Entities may use the data included in notifications to help predict effective treatments for patients, develop more effective medications, identify the benefits and side effects of a particular treatment, budget for drug costs, streamline drug manufacturing supply chains, manage drug inventories, determine the effectiveness of a particular treatment, and the like.

[0053] The medication shipment 302 received by the medication management system 130 may include one or more pieces of data (e.g., shipment information 304, compensation information 308, and the like) and the physical returned medication 306. The authorization module 320 may analyze the pieces of data and/or the returned medication 308 to determine whether to accept the medication shipment. Based on the analysis performed by the authorization module 320, the medication management system 130 may accept or reject a medication shipment 302. For example, if the authorization module 320 determines the returned medication 306 is in demand and/or may be re-distributed, the medication shipment 302 may be accepted. If the authorization module 320 determines the returned medication 306 is damaged, expired, not in-demand, or may not be re-distributed for some other reason, the medication shipment 302 may be rejected.

[0054] The authorization module 320 may also determine to accept or reject a medication shipment 302 based on an analysis of the medication image data 220 received by the medication verification system 120. Images of the returned medication and other medication image data 220 may be captured by patients before shipping. Medication image data 220 may be stored in an image database 222. The captured images and other medication image data 220 may be received by the authorization module 320. To determine to accept or reject a medication shipment, 302 the authorization module 320 may compare the medication image data 220 to the retuned medication 306. For example, the authorization module 320 may be able to recognize a distinct font on the medication bottle and/or bar codes, QR codes, color scheme or distinct hex colors that appear on the returned medication 306 and/or medication packaging. The authorization module 320 may also process the LOT numbers and corresponding expiration dates included in the medication image data 220 to confirm with the drug manufacturer that the returned medication is authentic. Returned medication 306 matching the medication image data 220 received for the shipment may be accepted. Returned medication 306 that do not match the medication image data 220 may be rejected.

[0055] Once the authorization module 320 makes a determination, rejected medication shipments may be returned to the user or disposed of/destroyed at the medication repository. The returned medication 306 included in accepted medication shipments may sent to a pharmacy, patient, drug wholesaler, group purchasing organization, or other buyer or distributor of prescription medication for re-distribution and reuse by other patients. The returned medication 306 may also sent to a drug manufacturer and exchanged for a new, not previously dispensed replacement medication. The replacement medication may then be re-distributed to patients. To facilitate the exchange of returned medications for replacement medications, the medication return platform may engage in partnerships with drug manufactures. As part of the partnership, the drug manufacturer may agree to receive returned medications in exchange for new, not previously dispensed replacement medications. The partnerships may allow the drug manufactures to properly dispose of unused medications. As part of the partnership, the medication return platform may provide the drug manufacturer user data and/or excess distributed medication information that the drug manufacturer can user to develop new drugs, improve existing therapies, upgrade drug distribution systems, optimize drug production, and the like.

[0056] Once the authorization module 320 has determined to accept or reject the medication shipment 302, the authorization module 320 may notify the notification module 330 and/or the compensation module 340. In response, to receiving a notice that the medication shipment has been accepted or rejected, the notification module 330 may generate user notifications 332 and/or entity notifications 334. The notification module 330 may then distribute the user notifications 332 to patients using the medication return platform. For example, the notification module may distribute a user notification 332 to a patient explaining that the medication shipment 302 submitted by the patient was accepted. User notifications 332 may also include other status updates, for example, notice that the medication shipment: was received, is being processed, has been rejected, has been approved for reimbursement, and the like. Other user notifications 332 may include notice of payment for the reimbursement has been generated, a check for the reimbursement payment has shipped, a reimbursement payment has been made via wire transfer, a donation to charity has been made, and the like. User notifications 332 may also include status updates from the verification system, for example, notifications that the user data for the medication return been received, that the user data for the medication return has been verified, that the user data is incorrect or incomplete, that the shipping label has been generated, and the like. User notifications 332 may be distributed to patients and other users of the medication return platform in real time as push notifications or other notifications delivered to a client that may be displayed in a GUI.

[0057] Entity notifications 334 generated by the notification module 330 may include notices sent to a doctor or other healthcare provider. For example, notifications that a patient is no longer taking a returned medication or other updates to a patient’ s treatment plan. Entity notifications 334 may also be sent to insurance companies drug manufacturers, and/or other subscribers or providers. For example, notifications that a drug has been returned may be sent to a drug manufacturer to help anticipate the amount of supply needed to satisfy patient demand. Notifications that a patient is no longer taking a returned medication may be sent to an insurance company to update patient coverage information and help insurance companies budget for costs associated with providing pharmaceutical drug coverage. Entity notifications 334 may also be sent to a pharmacy, drug wholesaler, drug distributor, and/or other provider or subscriber to notify the subscriber of the returned medication so that the subscriber knows when to request and/or purchase the returned medication. Data included in the entity notifications 334 may be distributed in real time. Data included in the entity notifications 334 may also be aggregated by the medication return platform and used to generate deep learning machine systems that are able reliably predict the probability of medication discontinuation rates.

[0058] In response to receiving a notice that the medication shipment 302 has been accepted, the compensation module 340 may authorize compensation 342 for the returned medication.

Compensation 342 may include a payment to the patient and/or patient’s insurance company, a donation to a charity selected by the patient, and any other form of compensation 342. The compensation module 340 may distribute funds to a patient returning medication and/or donations to a charity via wire transfer, direct deposit, check, and the like. To distribute funds and/or donations, the compensation module 340 may process compensation information 308 (e.g., bank account number, routing number, credit card number, name, address, bank name, charity name, charity bank information, and the like) included in the medication shipment 302. The compensation module 340 may also request compensation information 308 from the user. Compensation 342 distributed by the compensation module 340 may be drawn from an account maintained by the medication repository and/or obtained from a subscriber (e.g., a drug company, drug wholesaler, pharmacy and the like).

[0059] FIGS. 4A-G illustrate exemplary GUIs for collecting user data. FIGS. 4A-C illustrate exemplary GUIs that elicit treatment history information from patients using the medication return platform. Patients and other users may enter treatment history information into the GUIs by, for example, selecting one of the options shown or selecting other and entering text into a free form text box. FIG. 4A illustrates an exemplary medical condition GUI 400 for patients to enter a medication condition associated with the medication they are returning. FIG. 4B illustrates an exemplary medication identification GUI 402 for patients to enter one or more medications they are returning. FIG. 4C illustrates an exemplary treatment problem

identification GUI 404 for patients to enter one or more side effects they experienced while taking the medication they are returning. Patients may select and/or enter one or more conditions, medications, and/or side effects in the treatment history GUIs 400-404.

[0060] The treatment history GUIs may be displayed sequentially by the medication return platform. For example, the medication return platform may first display a medication condition GUI 400 and receive one or more conditions from the patient. Based on the conditions selected by the patient, the medication return platform may generate a medication identification GUI 402 including medications for the conditions entered by the patient. After receiving the medications from the patient, the medication return platform may then generate a treatment problem identification GUI 404 including the most common problems with the medications entered by the patient and/or the most common reasons for discontinuing use of the identified medications. Treatment history data collected by the treatment history GUIs 400-404 may be stored by the medication return platform and/or distributed to one or more subscribers to the medication return platform including healthcare providers, drug manufactures, insurance companies, government agencies, government healthcare systems, and other drug industry stakeholders. Treatment history data may be used to better understand the benefits and problems of using particular medications, predict treatment that will be effective for patients, and the like.

[0061] FIGS. 4D-4G illustrate additional exemplary GUIs the elicit insurance, personal, and medication information from patients. Patients and other users may enter insurance information, patient information, medication description information, and other data into the GUIs by, for example, selecting one of the options shown or selecting other and entering text into a free form text box. FIG. 4D illustrates an exemplary insurance information GUI 406 for patients to enter their insurance information. Once received by the insurance information GUI 406, patient insurance information may be used to determine if a patient is eligible for reimbursement for returned medications, identify an insurance company to reimburse for returned medications, and the like. FIG. 4E illustrates an exemplary personal information GUI 408 for patients to enter their address, contact information, and other personal information. Once received by the personal information GUI, patient personal information may be used to identify patients, generate a personalized shipping label used to return medications, and the like.

[0062] FIGS. 4F and 4G illustrate exemplary medication identification GUIs 410-412.

Medication identification GUIs 410-412 may collect medication descriptions and other excess medication information used to identify the medications a patient is returning. FIG. 4F illustrates an exemplary oral medication identification GUI 410. Patients may enter the quantity of pills/capsules they are returning, medication expiration information, and other information describing oral medications in the oral medication identification GUI 410. FIG. 4G illustrates an exemplary injection medication identification GUI 412. Patients may enter the number of syringes they are returning, medication expiration information, and other information describing injectable medications in the injection medication identification GUI 412. Medication descriptions received by the medication identification GUIs 410-412 may be used to identify returned medications, determine whether the medication return platform may accept and/or provide reimbursement for returned medications, and the like.

[0063] FIGS. 5A-5D illustrate exemplary shipping and packaging GUIs for facilitating packing and shipping returned medications by patients and other users of the medication return platform. To return medications via the platform, patients and other user may have to follow instructions included in one or more shipping and packaging GUIs. FIG. 5 A illustrates an exemplary image capture GUI 500 that facilitates capture of image data identifying a medication. The image data may include LOT numbers and the expiration date for the medication returned by the patient. The medication return platform may integrate with a camera included on a device used by the patient to access the medication return platform. For example, the medication return platform may integrate with a camera included in a smart phone or other mobile device. Once integrated with the camera, the medication platform may first display the image capture GUI 500. The after a predetermined period of time has passed and/or after prompting by the user, the medication return platform may initialize the camera and display an image capture user interface used to operate the camera. The medication return platform may then receive the image of the medication captured by the user. Previously captured medication images may also be displayed in the image capture GUI 500. Patients may select a previously captured picture to associate it with a shipment of retuned medications.

[0064] FIG. 5B illustrates an exemplary shipping label GUI 502. The shipping label GUI 502 may include an icon for accessing a shipping label, instructions for printing a shipping label, instructions for preparing a return authorization form, and the like. Once a medication return has been verified by the verification system, the medication return platform may send a notification to the user that a shipping label for the returned medication is available for printing. The shipping label may be accessed from the shipping label GUI 502. For example, the shipping label may be downloaded by selecting an icon or other prompt on the shipping label GUI 502. The shipping label may also be automatically sent to the patient (e.g., emailed to the patient) in response to the patient selecting an icon or other prompt on the shipping label GUI 502. FIG. 5C and 5D illustrate exemplary packaging GUIs 504, 506 including instructions for packing medication and an authorization form into a medication return package. The authorization form may also be submitted digitally.

[0065] FIGS. 6A-6E illustrate exemplary GUIs that illicit medical information including treatment and condition history information from patients using the medication return platform. Medical information received from the condition history GUIs 600-608 may be transferred to health care providers to update patient medical records. The medical information may also be used to predict treatments that are likely to be effective for a particular patient. Patients and other users may enter condition history and other medical information into the GUIs by, for example, selecting one of the options shown or selecting other and entering text into a free form text box. FIG. 6A illustrates an exemplary diagnosis history GUI for patients to enter condition diagnosis data including diagnosis date. FIG. 6B and 6E illustrate exemplary medication history GUIs for patients to enter medication history data including the start date for their current medication, the names of the medications they have used to treat their condition, and the like. FIGS. 6C and 6D illustrate exemplary symptom history GUIs for patients to enter symptom history data including the start date for their first condition symptom, the date of their most recent condition symptom, the type of symptoms, the severity of the symptoms, the duration of the symptoms, and the like.

[0066] Data collected by the medication return platform, for example, data collected from users via the exemplary GUIs shown in FIGS. 4A-6E may allow for the generation of deep learning models and other machine learning systems. For example, user data could be used to train a machine learning system to reliably predict a rate of discontinuation for a particular medication and/or condition. The machine learning system could be trained on user data for patients having similar attributes to generate patient specific models that more accurately predict the rate of discontinuation for a particular patient or group of patients having one or more attributes in common. Attributes may include, for example, condition history, treatment history, locations, user demographics, or other patient information, and the like. For example, the machine learning system could be trained on training dataset including user data for patients taking Avonex that were diagnosed with MS at least 5 years ago. After training, the patient specific model generated based on this particular training dataset could predict the rate of discontinuation for Avonex for a particular patient that was diagnosed with MS at least 5 years ago. The patient specific models generated based on user data collected by the medication return platform can predict discontinuation rates for specific drugs and specific patients more accurately than models trained on user data that is not specific to a particular patient or group of patients. Over time as more information is collected from users, the machine learning system may be re- trained to generate more accurate patient specific models.

[0067] Predictions generated by the machine learning system may be used my subscribers to the medication return platform. For example, the predictions for rate of discontinuation may be used by insurance companies to refine the list of authorizations and approvals. For example, the predicted discontinuation rate may be used as a threshold for authorizing insurance coverage for a particular treatment. If the predicted discontinuation rate is high and above the threshold, the insurance company may not authorize coverage for the treatment. If the predicted

discontinuation rate is low and below the threshold, the insurance company may authorize coverage and/or prioritize review for approval. Predictions for rate of discontinuation of specific medications may also be used by drug manufactures to develop more effective marketing strategies, better train sales staff, educate prescribers about the medications and expected level of support, and the like.

[0068] FIG. 7 is a flow chart illustrating an exemplary method for returning unused medication 700. At 702, the medication return platform receives user data from a patient. User data may include personal information about the patient, a description of the medication the patient is returning, the patient’ s condition and treatment history, the patient’ s insurance information, and the like. The user data may also include a photo of the medication the patient is returning and a digital authorization form signed by the patient that authorizes the medication repository to accept the returned medication and destroy or re-distribute the medication.

[0069] At 704, the medication return platform verifies the returned medication based on the user data as described above. For example, the medication return platform may confirm the quantity and expiration information of the returned medication provided by the user matches the LOT number and expiration information shown in the medication image. At 706 if the medication return platform verifies the medication information included in the user data, the medication return platform may generate a shipping label for the returned medication. At 706 if the medication return platform does not verify the medication information included in the user data, the mediation return platform may request the patient provide corrected information at 708. For example, the medication return platform may request the patient update the medication quantity and/or expiration information. Updated user data may then be received at 702 and verified at 704.

[0070] At 712, the medication return platform receives the shipment of returned medication from the patient. The shipment may be accepted by a medication repository and the physical returned medication, shipment information, and compensation information may be analyzed to determine if a payment reimbursing the patient, donation to patient’ s charity of choice, or some other compensation for the returned medication is authorized. For example, the medication repository may check the condition of the medication to verify if can be redistributed, review the compensation information of the patient to determine if the patient’ s account information is valid, the charity selected by the patient exists, and the like. At 714 if the medication return platform determines the compensation for the medication shipment is authorized, the mediation return platform may distribute compensation at 716. At 714 if the medication return platform determines the medication shipment is not authorized, the medication return platform may request the patient provide corrected information at 708. For example, the medication return platform may request the patient update the compensation information to provide a valid bank account or existing charity. Updated user data may then be received at 702 and the medication return platform may determine if compensation is authorized at 714.

[0071] Once the returned medication is accepted and compensation distributed, the medication return platform may confirm the patient is no longer using the returned medication and has switched to a new treatment. To determine how the patient is responding to the new treatment, the medication return platform may request follow-up information at 718. If the patient is responding well, follow-up information received from the patient may be distributed to a healthcare provider and used to update the patient’s medical records. If the patient is not responding well to the new medication, the medication return platform may initiate the medication return process for the new treatment to facilitate return of an excess supply of the ineffective treatment. Follow-up information received by the medication return platform may be stored and used as training data to improve the accuracy of models generated by the machine learning system.

[0072] FIG. 8 is a flow chart illustrating a method of distributing returned medication 800. At 802, the medication return platform may receive user data from a patient as described above. In response to receiving the user data, the medication return platform may generate notifications including one or more pieces of user data. The notifications may be distributed to various subscribers to the return medication platform at 804-810. Subscribers may include healthcare providers and other drug industry stakeholders including a patient, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, government healthcare system, and the like. For example, the medication return platform may distribute patient information and treatment history information a healthcare provider to notify the provider of the return at 804. The healthcare provider may use the pieces of data included in the notification to, for example, update the patient’s medical records.

[0073] At 806, the medication return platform may distribute a notification including patient information, insurance information, and treatment history information to an insurance company. The insurance company may use the pieces of data included in the notification to, for example, update the patient’s coverage and/or adjust the budget for pharmaceutical cost reimbursement.

At 808, the medication return platform may distribute a notification including medication description information and treatment history information to a drug manufacturer. The drug manufacturer may use the pieces of data included in the notification to help develop more effective drugs, develop alternative formulations of effective drugs, expand manufacturing capacity for one or more drugs, decrease manufacturing capacity for one or more drugs, and the like. At 810, the medication return platform may distribute a notification including patient medication description information to a pharmacy. The pharmacy may use one or more pieces of data included in the notification to adjust the inventory of a particular drug.

[0074] Upon receiving user data 802, the medication return platform may verify the returned medication based on user data as described above. Once the returned medication is verified the medication return platform may locate a subscriber at 812. For example, the medication return platform may notify pharmacies, patients, group purchasing organizations, drug wholesalers, and other subscribers that purchase medications of the type, quantity, and expired information of the returned medication. An interested subscriber may submit payment to the medication return platform. Once the shipment is received at 814 and the compensation is authorized, the payment, donation, or other compensation may be distributed. For example, a reimbursement payment may be distributed to the patient or a donation may be made to the patient’ s charity of choice.

[0075] At 816, retuned medication included in shipments received by the medication repository may be distributed to the subscriber. For example, returned medication may be distributed to a pharmacy of a patient or other subscriber that payed for the returned medication collected by the medication return platform. Once the returned medication is distributed, the medication return platform may confirm the patient is no longer using the returned medication and has switched to a new treatment. To determine how the patient is responding to the new treatment, the medication return platform may request follow-up information at 818 as described above. Once the medication is distributed, the medication return platform may also confirm that the medication is being used by a new patient. To determine how the new patient is responding to the returned medication, the medication return platform may request follow-up information at 818. If the patient is responding well, follow-up information received from the patient may be distributed to a healthcare provider and used to update the patient’s medical records. If the patient is not responding well to the new medication, the medication return platform may initiate the medication return process for the new treatment to facilitate return of an excess supply of the ineffective treatment. Follow-up information received by the medication return platform may be stored and used as training data to improve the accuracy of models generated by the machine learning system.

[0076] FIG. 9 shows a computing device according to an embodiment of the present disclosure. For example, computing device 900 may function as client 160 (which may include a platform for returning an managing excess medications). The computing device 900 may be implemented on any electronic device that runs software applications derived from compiled instructions, including without limitation personal computers, servers, smart phones, media players, electronic tablets, game consoles, email devices, etc. In some implementations, the computing device 900 may include one or more processors 902, one or more input devices 904, one or more display devices 906, one or more network interfaces 908, and one or more computer-readable mediums 912. Each of these components may be coupled by bus 910, and in some

embodiments, these components may be distributed among multiple physical locations and coupled by a network.

[0077] Display device 906 may be any known display technology, including but not limited to display devices using Liquid Crystal Display (LCD) or Light Emitting Diode (LED) technology. Processor(s) 902 may use any known processor technology, including but not limited to graphics processors and multi-core processors. Input device 904 may be any known input device technology, including but not limited to a keyboard (including a virtual keyboard), mouse, track ball, camera, and touch-sensitive pad or display. Bus 910 may be any known internal or external bus technology, including but not limited to ISA, EISA, PCI, PCI Express, NuBus, USB, Serial ATA or FireWire. Computer-readable medium 912 may be any medium that participates in providing instructions to processor(s) 902 for execution, including without limitation, non volatile storage media (e.g., optical disks, magnetic disks, flash drives, etc.), or volatile media (e.g., SDRAM, ROM, etc.).

[0078] Computer-readable medium 912 may include various instructions 914 for implementing an operating system (e.g., Mac OS®, Windows®, Linux). The operating system may be multi user, multiprocessing, multitasking, multithreading, real-time, and the like. The operating system may perform basic tasks, including but not limited to: recognizing input from input device 904; sending output to display device 906; keeping track of files and directories on computer-readable medium 912; controlling peripheral devices (e.g., disk drives, printers, etc.) which can be controlled directly or through an I/O controller; and managing traffic on bus 910. Network communications instructions 916 may establish and maintain network connections (e.g., software for implementing communication protocols, such as TCP/IP, HTTP, Ethernet, telephony, etc.).

[0079] Application(s) 918 may be an application that uses or implements the processes described herein and/or other processes. For example, an medication verification application that verifies returned medication information and generates shipping labels, a medication management system that authorizes and distributes compensation for returned medication, and/or a medication return application that collects patient data and facilitates shipping returned medications to a medication repository. The processes may also be implemented in operating system 914. For example, application 918 and/or operating system 914 may present GUIs 162 that facilitate return of unused medications and distribute notifications and compensation to patients as described herein.

[0080] The described features may be implemented in one or more computer programs that may be executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program may be written in any form of programming language (e.g., Objective-C, Java), including compiled or interpreted languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment. [0081] Suitable processors for the execution of a program of instructions may include, by way of example, microcontrollers, both general and special purpose microprocessors, and the sole processor or one of multiple processors or cores, of any kind of computer. Generally, a processor may receive instructions and data from a read-only memory or a random access memory or both. The essential elements of a computer may include a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer may also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data may include all forms of non volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).

[0082] To provide for interaction with a user, the features may be implemented on a computer having a display device such as an LED or LCD monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.

[0083] The features may be implemented in a computer system that includes a back-end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination thereof. The components of the system may be connected by any form or medium of digital data communication such as a communication network. Examples of communication networks include, e.g., a telephone network, a LAN, a WAN, and the computers and networks forming the Internet.

[0084] The computer system may include clients and servers. A client and server may generally be remote from each other and may typically interact through a network. The relationship of client and server may arise by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

[0085] One or more features or steps of the disclosed embodiments may be implemented using an API. An API may define one or more parameters that are passed between a calling application and other software code (e.g., an operating system, library routine, function) that provides a service, that provides data, or that performs an operation or a computation. [0086] The API may be implemented as one or more calls in program code that send or receive one or more parameters through a parameter list or other structure based on a call convention defined in an API specification document. A parameter may be a constant, a key, a data structure, an object, an object class, a variable, a data type, a pointer, an array, a list, or another call. API calls and parameters may be implemented in any programming language. The programming language may define the vocabulary and calling convention that a programmer will employ to access functions supporting the API.

[0087] In some implementations, an API call may report to an application the capabilities of a device running the application, such as input capability, output capability, processing capability, power capability, communications capability, etc.

[0088] While various embodiments have been described above, it should be understood that they have been presented by way of example and not limitation. It will be apparent to persons skilled in the relevant art(s) that various changes in form and detail can be made therein without departing from the spirit and scope. In fact, after reading the above description, it will be apparent to one skilled in the relevant art(s) how to implement alternative embodiments. For example, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.

[0089] In addition, it should be understood that any figures which highlight the functionality and advantages are presented for example purposes only. The disclosed methodology and system are each sufficiently flexible and configurable such that they may be utilized in ways other than that shown.

[0090] Although the term“at least one” may often be used in the specification, claims and drawings, the terms“a”,“an”,“the”,“said”, etc. also signify“at least one” or“the at least one” in the specification, claims and drawings.

[0091] Finally, it is the applicant's intent that only claims that include the express language "means for" or "step for" be interpreted under 35 U.S.C. 112(f). Claims that do not expressly include the phrase "means for" or "step for" are not to be interpreted under 35 U.S.C. 112(f).

Claims

CLAIMS What is claimed is:

1. A method of managing excess medications comprising:

providing a medication return platform having a graphical user interface that is remotely accessible by a plurality of users;

receiving, by the medication return platform, user data including medical information and excess distributed medication information from a user included in the plurality of users; verifying, by the medication return platform, accuracy of the excess distributed medication information;

generating, by the medication return platform, a shipping label and a return authorization from for the user;

receiving, from the user, a completed return authorization form and a shipment of medication sent using the shipping label;

matching, by the medication return platform, the verified excess distributed medication information with the shipment of medication; and

distributing, by the medication return platform, compensation for the shipment of medication.

2. The method of claim 1, wherein the medical information includes condition history and treatment history relating to multiple sclerosis, glioblastoma multiforme, Parkinson’s disease, rheumatoid arthritis, systemic lupus erythematosus, psoriatic arthritis, ankylosing spondylitis, multiple myeloma or other forms of cancer, neuromyelitis optica spectrum disorder, sleep disorders, cystic fibrosis, hematological malignancies, Alzheimer’s disease or other neurodegenerative or neurological conditions, hemophilia, hepatitis, HIV/AIDS, Crohn’s disease, ulcerative colitis, solid organ tumors, organ transplants, hereditary amyloidosis, metabolic deficiencies, hormonal deficiencies, pulmonary hypertension, hypercholesterolemia, spinal muscular atrophy, muscular dystrophies, or other muscle disorders.

3. The method of claim 1, wherein the graphical user interface is provided by smartphone, tablet or personal computer.

4. The method of claim 1, wherein the compensation is a donation to a charity selected by the user.

5. The method of claim 1, wherein the compensation is an electronic payment to the user comprising a bank wire, automatic deposit, account credit, or redeemable points.

6. The method of claim 1, wherein the verifying further comprises:

transmitting the excess distributed medication information to a provider;

receiving, from the provider, verification information about the excess distributed medication;

receiving, from the user, an image of a medication described in the excess distributed medication information; and

matching the verification information received from the provider with the image of the medication and the excess distributed medication information.

7. The method of claim 6, wherein the image of the medication includes a LOT number and expiration information.

8. The method of claim 6, wherein the provider is a healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, or government healthcare system.

9. The method of claim 1, 2, 3, 4, 5, 6, 7 or 8, further comprising;

receiving compensation information from the user; and

authorizing, by the medication return platform, the compensation for the shipment of medication in response to verifying a condition of the shipment of medication and validating the compensation information·

10. The method of claim 1, 2, 3, 4, 5, 6, 7, 8 or 9, further comprising:

generating, by the medication return platform, a subscriber notification including one or more pieces of data included in the user data;

distributing, by the medication return platform, the subscriber notification to a subscriber;

in response to the distributing, receiving payment for the shipment of medication from the subscriber; and

distributing, by the medication return platform, the shipment of medication to the subscriber.

11. The method of claim 10, wherein the subscriber is a patient, healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, or government healthcare system.

12. A system for managing excess medications, comprising:

a processor and memory connected to each other;

a display connected to the processor; and

a plurality of lines of instructions stored in the memory and executed by the processor that is configured to:

provide, on the display, a medication return platform having a graphical user interface that is remotely accessible by a plurality of users;

receive, by the system for managing excess medications, user data including medical information and excess distributed medication information from a user included in the plurality of users;

verify, by the system for managing excess medications, accuracy of the excess distributed medication information;

generate, by the system for managing excess medications, a shipping label and a return authorization from for the user;

receive, from the user, a completed return authorization form and a shipment of medication sent using the shipping label;

match, by the system for managing excess medications, the verified excess distributed medication information with the shipment of medication; and

distribute, by the medication return platform, compensation for the shipment of medication.

13. The system of claim 12, wherein the medical information includes condition history and treatment history relating to multiple sclerosis, glioblastoma multiforme, Parkinson’s disease, rheumatoid arthritis, systemic lupus erythematosus, psoriatic arthritis, ankylosing spondylitis, multiple myeloma or other forms of cancer, neuromyelitis optica spectrum disorder, sleep disorders, cystic fibrosis, hematological malignancies, Alzheimer’s disease or other neurodegenerative or neurological conditions, hemophilia, hepatitis, HIV/AIDS, Crohn’s disease, ulcerative colitis, solid organ tumors, organ transplants, hereditary amyloidosis, metabolic deficiencies, hormonal deficiencies, pulmonary hypertension, hypercholesterolemia, spinal muscular atrophy, muscular dystrophies, or other muscle disorders.

14. The system of claim 12, wherein the processor is further configured to verify accuracy of the distributed excess medication information by:

transmitting the excess distributed medication information to a provider;

15. The system of claim 14, wherein the image of the medication includes a LOT number and expiration information.

16. The system of claim 14, wherein the provider is a healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, or government healthcare system.

17. The system of claim 12, 13, 14, 15 or 16, wherein the processor is further configured to: receive compensation information from the user; and

authorize, by the system for managing excess medications, compensation for the shipment of medication in response to verifying a condition of the shipment of medication and validating the compensation information.

18. The system of claim 12, 13, 14, 15, 16 or 17, wherein the processor is further configured to:

generate, by the system for managing excess medications, a subscriber notification including one or more pieces of data included in the user information;

distribute, by the system for managing excess medications, the subscriber notification to a subscriber;

in response to the subscriber notification, receive compensation for the shipment of medication from the subscriber; and

distribute, by the system for managing excess medications, the shipment of medication to the subscriber.

19. The system of claim 18, wherein the subscriber is a patient, healthcare provider, health insurance company, pharmacy, pharmaceutical manufacturer, pharmacy benefit manager, government agency, or government healthcare system.

20. A method of managing excess medications comprising:

based on the matching, accepting, by the medication return platform, the shipment of medication for re-distribution.