JP7712211B2 - Adaptive Care Management System - Google Patents

Description

This application claims the benefit of U.S. Patent Application No. 62/844,697, filed May 7, 2019, which is incorporated herein by reference in its entirety.

The present technology relates generally to treatment. Specifically, the present technology relates to managing the treatment of heart failure or other chronic diseases.

As a specific example of a chronic disease, congestive heart failure (CHF) is a serious disease that occurs when the heart is unable to pump blood consistently at an adequate rate. To improve the heart's ability to pump blood efficiently, CHF patients may require an implantable medical device (IMD). IMDs, such as implantable cardioverter defibrillators (ICDs) and pacemakers, can provide cardiac resynchronization therapy to improve cardiac function in CHF patients. Despite the use of IMDs to improve cardiac function, CHF patients may experience gradual deterioration as evidenced by weight gain, dyspnea, orthopnea, changes in blood pressure, fatigue, tiredness, peripheral edema (swelling of the legs), fainting, and/or palpitations.

Patient data can be obtained in a variety of ways. Typically, patients communicate their health data directly to healthcare professionals during a consultation. Some data can be generated automatically and transmitted to a computer or healthcare system over the Internet. For example, an electronic weight scale is configured to measure a patient's weight and then automatically transmit that data to a healthcare system.

Depending on the collected data, the medical system may respond in a variety of ways. Some medical systems can generate health alerts based on data detected by the IMD. One exemplary medical system described in U.S. Patent Publication No. 2010/0030293 to Sarkar et al. generates an alert for the patient to seek treatment in response to the detected information. The medical device can detect worsening heart failure in the patient based on diagnostic parameters. Upon detecting worsening heart failure, the medical device can provide an alert, for example, to allow the patient to seek medical attention before experiencing a heart failure event. While many medical systems can automatically notify medical personnel of potential health problems, medical systems typically require physician input to adjust the therapy (e.g., medication) delivered to the patient.

The technology of the present disclosure generally relates to an adaptive treatment management system. The system may administer different treatment regimens between physician visits for a chronic condition, such as heart failure, chronic obstructive pulmonary disease (COPD), or renal dysfunction, to maintain a constant and stable condition for the patient, even when the patient is not at high risk for hospitalization. The system may update the treatment regimen multiple times between physician visits to facilitate optimization of treatment, thereby minimizing the patient's risk score, minimizing deviations from the physician-prescribed treatment regimen, and minimizing the patient's symptoms.

In one aspect, the present disclosure provides a therapy management system including a sensor system for providing patient data regarding a patient or an environment associated with the patient. The therapy management system also includes a therapy delivery system for administering a therapy based on a therapy regimen and for providing therapy compliance data. The therapy management system further includes a therapy optimization system operably coupled to the sensor system and the therapy delivery system, for updating the therapy regimen based on the patient data from the sensor system and the therapy compliance data from the therapy delivery system, and providing the updated therapy regimen to the therapy delivery system.

In another aspect, the present disclosure provides a therapy optimization system including a sensor system configured to provide patient data and a data communication interface operably coupled to a therapy delivery system configured to administer a therapy based on a therapy regimen. The therapy optimization system also includes a memory configured to store data representative of a risk score generator and a therapy regimen generator, and a processor operably coupled to the data communication interface and the memory. The processor is configured to: update a patient score based on at least one score selected from one or more risk scores, one or more therapy scores, and one or more symptom scores in response to administering a previous therapy based on the previous therapy regimen; determine a therapy regimen in response to the updated patient score and the previous therapy regimen; and provide the therapy regimen to the therapy delivery system.

In another aspect, the present disclosure provides a therapy optimization system including a sensor system configured to provide patient data and a data communication interface operably coupled to a therapy delivery system configured to administer therapy based on a therapy regimen. The communication interface is configured to receive data representative of a predetermined physician-limited parameter region. The therapy optimization system also includes a memory configured to store data representative of the predetermined physician-limited parameter region, and a processor operably coupled to the data communication interface and the memory. The processor is configured to use the patient data to determine a patient score based on at least one of a risk score, a treatment score, or a symptom score, determine a therapy regimen based on the patient score, determine whether the therapy regimen is within the predetermined physician-limited parameter region, and, in response to determining that the therapy regimen is within the predetermined physician-limited parameter region, provide the therapy regimen to the therapy delivery system for administering therapy based on the therapy regimen.

In yet another aspect, the present disclosure provides a therapy optimization system including a sensor system configured to provide patient data and a data communication interface operably coupled to a therapy delivery system configured to administer therapy based on a therapy regimen. The communication interface is configured to receive a physician-based therapy regimen. The therapy optimization system also includes a memory configured to store data representative of the physician-based therapy regimen, and a processor operably coupled to the data communication interface and the memory. The processor is configured to determine whether one or more risk scores are within a stability region representative of stability of the patient after administering therapy according to the current therapy regimen, determine a therapy score based on a difference between the current therapy regimen and the physician-based therapy regimen as a function of the one or more risk scores being within the stability region, determine an updated therapy regimen based on the therapy score, and provide the updated therapy regimen to the therapy delivery system.

In yet another aspect, the present disclosure provides a therapeutic delivery system including a plurality of receptacles. Each receptacle is for holding a different drug or a different dose of a drug. The therapeutic delivery system also includes one or more cartridges. Each cartridge is for containing a different drug. Each cartridge includes a different drug identifier associated with a different drug or a different dose of a drug for loading into a respective receptacle. The therapeutic delivery system further includes a controller configured to detect each drug identifier of the one or more cartridges and transmit a request via the data communication interface to deliver a new cartridge associated with a particular drug identifier according to an updated therapeutic regimen.

The details of one or more aspects of the disclosure are set forth in the accompanying drawings and the description below. Other features, objects, and advantages of the techniques described in this disclosure will become apparent from the specification and drawings, and from the claims.

FIG. 1 is a block diagram illustrating an example of a treatment management system according to the present disclosure. FIG. 2 is a conceptual diagram showing an example of an environment in which the treatment management system of FIG. 1 can be used. 2 is a flow diagram illustrating an example of a method of using the treatment management system of FIG. 1. FIG. 4 is a state diagram illustrating an example of a method for implementing the optimization treatment method of FIG. 3 using multiple generators. FIG. 4 is a flow diagram illustrating an example of a method for determining a patient score that can be used in the method of FIG. 3. FIG. 4 is a flow diagram showing an example of implementing the optimization treatment method of FIG. 3 using risk score evidence. FIG. 4 is a flow diagram illustrating an example of integrating physician input to implement the optimization method of FIG. 3. FIG. 8 is a conceptual diagram illustrating an example of a physician-limited parameter region that can be used in the method of FIG. 7. FIG. 2 is a conceptual diagram illustrating an example of a therapy delivery system that can be used with the therapy management system of FIG. 1. FIG. 4 is a conceptual diagram illustrating an example of managing a patient's treatment using the method of FIG. 3. FIG. 4 is a conceptual diagram illustrating another example of managing a patient's treatment using the method of FIG. 3.

The technology of the present disclosure generally relates to an adaptive treatment management system. The system may administer different treatment regimens between physician visits for a chronic condition, such as heart failure, chronic obstructive pulmonary disease (COPD), or renal dysfunction, to maintain a constant and stable condition for the patient, even when the patient is not at high risk for hospitalization. The system may update the treatment regimen multiple times between physician visits to facilitate optimization of treatment, thereby minimizing the patient's risk score, minimizing deviations from the physician-prescribed treatment regimen, and minimizing the patient's symptoms.

The technology can provide dynamic therapy to manage physician-guided dose titration based on a patient's risk status, therapy adjustments for daily inadvertence, provide a reduction in the total amount of diuretics taken by a patient, effectively capture data from non-implanted or non-wearable sources, encourage patient compliance with treatment regimens, reduce the complexity of treatment regimens, detect non-compliance, enable efficient triage, collect data on treatment outcomes, and automatically schedule nurse and physician appointments.

As used herein, the term "or" is generally used in its inclusive sense, e.g., meaning "and/or," unless the context clearly dictates otherwise. The term "and/or" refers to one or all listed elements, or a combination of at least two of the listed elements.

When listed items are joined by "and" or "or," "at least one of" and "one or more of" refer generally to any one of the listed items, and any combination of two or more of the listed items, unless the context clearly dictates otherwise.

Reference is now made to the drawings, which illustrate one or more aspects described in the present disclosure. However, it will be understood that other aspects not shown in the drawings are within the scope of the present disclosure. Like numbers used in the figures refer to like components, steps, etc. However, it will be understood that the use of a reference character to refer to an element in a given figure is not intended to limit the element in another figure labeled with the same reference character. Additionally, the use of different reference characters to refer to elements in different figures is not intended to indicate that the different referenced elements may not be the same or similar.

FIGS. 1-2 and 9 show a treatment management system and various components for managing a patient's treatment. FIGS. 3-8 show various views of techniques that may be used by or in conjunction with the treatment management system. FIGS. 10-11 show various examples of using the treatment management system of FIGS. 1-2 and 9 to manage treatment using one or more of the techniques shown in FIGS. 3-8.

FIG. 1 is a block diagram illustrating an example of a therapy management system according to the present disclosure. As shown, the therapy management system 100 can include a sensor system 150, a therapy optimization system 160, a therapy delivery system 170, and a remote system 180. The therapy management system 100 can be used to administer therapy to a patient based on the patient's treatment regimen and to update the treatment regimen between physician visits periodically or as needed.

The treatment management system 100 can update the treatment regimen based on the frequency of administering the treatment. For example, the treatment regimen can prescribe administration of a particular treatment once or multiple times a day, e.g., three times a day, and the treatment regimen can be updated at least daily, or at the most frequent administration, e.g., three times a day, or at any frequency suitable enough to keep the patient in a constant, stable, or constant and stable state. In some embodiments, the treatment can be adjusted or titrated upon updating the treatment regimen by the treatment management system 100. For example, a physician can provide a prescription that can map a dose of drug and drug type to a risk score or other patient condition, and the treatment management system 100 can determine and provide a treatment regimen daily, every two days, every three days, weekly, or any suitable time based on this risk score or changes in risk score.

The sensor system 150 may include one or more sensors for detecting various parameters related to the patient and the environment associated with the patient. The detected parameters may be used to provide patient data or other data. Various examples of components of the sensor system 150 include patient-implanted sensors, patient-wearable sensors, external sensors not worn by the patient, a graphical or audible user interface for accepting user input, or a memory for storing historical or past patient data.

As used herein, the term "patient data" generally refers to data relating to a patient or the environment associated with a patient. Various examples of sensors and devices that can be used to detect, collect, or determine patient data are described herein, for example, with respect to FIG. 2. Non-limiting examples of patient data include, for example, fluid levels, blood pressure, heart rate, heart rate variability, pulse transit time, QT interval, weight level, respiratory rate, respiratory effort, heart sounds, ejection fraction, potassium level, sodium level, creatinine level (or another renal biomarker such as blood urea nitrogen (BUN)), brain natriuretic peptide (BNP) or its precursor form NT-proBNP, pulmonary ventricular pressure, jugular vein size, posture, patient activity, tissue perfusion level, oxygen saturation, blood glucose level, incidence and burden of arrhythmias (atrial or ventricular) (e.g., atrial or ventricular premature beats per day), COPD burden, and images of the patient's heart. A variety of specific sensors, such as fluid level sensors, blood pressure sensors, etc., can be used to collect each type of patient data. Patient data may include patient outcome data, such as whether the patient is hospitalized and other healthcare utilization information. Patient data may also include relevant information about the patient, such as other medical conditions or current treatments (e.g., diabetes, renal failure, obesity, sleep apnea, dementia, Parkinson's disease, etc.).

The sensor system 150 can be operatively coupled to a treatment optimization system 160 to provide patient data to the system 160. The treatment optimization system 160 can use this patient data to provide or determine an optimal treatment regimen for the patient. The optimized treatment can be described as a patient-specific treatment. In particular, the historical patient data can be used to determine covariances with current patient data or to determine various risk factors based on the patient's background or history, for example using artificial intelligence (AI) or other adaptive feedback methods. The treatment regimen can be determined based on at least one of the patient data, compliance data, and associated treatment data.

Some patient data may be provided to the treatment optimization system 160 automatically, and other patient data may be provided to the treatment optimization system in response to a triggering event. In some embodiments, the treatment optimization system 160 may request information from the sensor system 150, which may be described as previously received patient data or additional patient data used to supplement the initial patient data. In particular, the treatment optimization system 160 may request information to confirm or corroborate the information in the initial patient data (e.g., "Are you short of breath?" or "Have you been to the hospital?"). For example, patient data indicating high blood pressure or hypertension may be corroborated or confirmed using an eye scan from an image sensor. The additional patient data may be described as corroborating, confirming, or adjacent patient data. The additional patient data may be collected by the sensor system 150 or the treatment optimization system 160. Various examples of additional patient data requested by the treatment optimization system 160 are described herein with respect to FIG. 2.

As used herein, "compliance data" or "treatment compliance data" generally refers to data related to a patient receiving a administered treatment. The compliance data may be sufficient to determine whether a treatment was administered to a patient or whether the patient actually received the treatment. Various sensors and devices that may be used to detect, collect, or determine compliance data are described herein with respect to FIG. 2. The compliance data may be used by the treatment optimization system 160 to train one or more algorithms or generators to generate subsequent or future treatment regimens.

Non-limiting examples of compliance data include, for example, medication compliance (e.g., did the patient take the correct medication with rise doses in a timely manner), nutritional compliance (e.g., limiting salt and water intake), physical activity compliance (e.g., exercise), and refraining from substance use (e.g., smoking). Compliance data may also include data such as facial recognition data, voice recognition data, fingerprint data, verbal confirmation data, internal medication sensor data, dispenser confirmation data (e.g., to confirm what was dispensed for medication or nutrition), and motion sensor data (e.g., to confirm exercise) to verify the identity of the user (e.g., to facilitate identification of the user of the medication) or to verify that the user actually complied with the treatment regimen.

In the illustrated embodiment, the therapy optimization system 160 may be operatively coupled to the therapy delivery system 170 to receive compliance data. The compliance data may be received, for example, at the same or similar frequency used to update the therapy regimen, or at the same or similar frequency as administering the therapy, or at any other suitable pace to manage the therapy at a constant or stable regime.

As used herein, the term "related treatment data" generally refers to data related to one or more medical conditions and treatments in a treatment regimen. The related treatment data may include information about specific treatments used for other patients sharing the same or similar characteristics as the current patient. For example, a patient may be receiving treatment for both heart failure and chronic obstructive pulmonary disease (COPD), and the related treatment data may include or be based on information about treatments used for other patients receiving the same treatment. The related treatment data may be used by the treatment optimization system 160 to train one or more algorithms or generators to generate subsequent or future treatment regimens. For example, an initial treatment regimen may be determined by the treatment optimization system 160 based on the related treatment data, which may have little or no patient-specific patient data and may include large population-level data on the same or similar medical conditions or treatments. The patient data may then be used to further update the treatment regimen.

In the illustrated embodiment, the treatment optimization system 160 may be operably coupled to the remote system 180 to receive relevant treatment data. In particular, the treatment optimization system 160 may be operably coupled to the remote system 180 via the Internet. In some embodiments, the treatment optimization system 160 may be operably coupled to the sensor system 150 or the treatment delivery system 170 via the Internet, and the functionality of the remote system 180 may be integrated into the treatment optimization system, for example, as a single unit. The treatment optimization system 160 located on the remote system 180 may persist as a dynamic database that continually grows as the number of patients utilizing it and the duration of time that patients use the system increases.

The associated treatment data may be received at any suitable pace to manage treatment in a constant or stable region, as described herein with respect to FIG. 6. In some embodiments, the associated treatment data may be received periodically during the generation of the initial or initial treatment regimen and at a slower frequency compared to updating the treatment regimen or administering the treatment. In other embodiments, the associated treatment data may be received and used to update the treatment regimen in real time or at the same or similar frequency as updating the treatment regimen or administering the treatment.

The therapy optimization system 160 may be operatively coupled to a therapy delivery system 170 to provide the therapy regimen. The therapy delivery system 170 may administer therapy to the patient using the therapy regimen.

As used herein, "delivering a therapy" refers to providing a patient with information (e.g., notifications) to receive a therapy, making a therapy available to a patient (e.g., administering a medication), or controlling a device or system to automatically provide a therapy to a patient (e.g., a drug delivery pump or oxygen machine to treat COPD). Examples of drug delivery pumps that may be used to automatically provide a therapy to a patient include a diuretic pump or an insulin pump depending on the medical condition.

The therapy management system 100 can be described as a "closed loop" therapy management system, for example, because of the feedback provided between the various systems 150, 160, 170, 180 throughout the system 100. In one example, compliance data from the therapy delivery system 170 can be provided to the therapy optimization system 160 to confirm or corroborate the administration of therapy to the patient. In another example, the sensor system 150 can be used, for example, to administer a therapy using the therapy delivery system 170 and then observe the effectiveness of the administered therapy. Other forms of feedback are also contemplated in the use of the therapy management system 100.

FIG. 2 is a conceptual diagram illustrating an example of an environment in which the treatment management system of FIG. 1 can be used. As shown, the environment 200 for use with the treatment management system 100 can include the body of a patient 50.

Any suitable components or devices may be used to implement the system of the treatment management system 100. Non-limiting examples of systems that can be used in the treatment management system 100 are described in U.S. Patent Application No. 16/394,942, filed April 25, 2019 and published as U.S. Patent Application No. 2019/0329043, and U.S. Patent Application No. 15/402,839, filed January 10, 2017 and published as U.S. Patent Publication No. 2017/0245794, which are incorporated by reference into this disclosure. In some embodiments, the treatment management system 100 is configured to seamlessly trigger adjustments to a patient's treatment regimen, i.e., treatment plan, without direct interaction with the patient's physician at any time after the prescribed treatment regimen has been sent to a central communication center for storage or stored in the memory of a computing device.

A treatment regimen may include one or more treatments (e.g., a first dose, a second dose, etc.). In general, adjustments to a patient's treatment regimen may depend on a variety of factors, such as one or more risk scores, which may be determined based on patient data from one or more devices of the sensor system 150.

The sensor system 150 may include any suitable device for acquiring patient data. In some embodiments, the sensor system 150 may include a patient-implantable device 202, such as an implantable medical device (IMD) having patient-implantable sensors, a patient-wearable device 204 having patient-wearable sensors, and an external device 206 having external sensors.

Various types of patient-implantable sensors can be used and operably coupled to the circuitry of the patient-implantable device 202 for use in providing patient data. Non-limiting examples of patient-implantable sensors include implantable electrical sensors with one or more electrical contacts (e.g., electrodes), biochemical sensors, motion sensors (e.g., 3-axis accelerometers), piezoelectric sensors, optical sensors, temperature sensors, geographic location sensors (e.g., GPS sensors), or microphones. The electrical contacts can be used to provide electrical stimulation to the patient's tissue, such as cardiac tissue or renal tissue.

The one or more patient-implanted sensors may be incorporated into or operably coupled to a variety of implantable medical devices 202. Non-limiting examples of implantable medical devices 202 include leaded or lead-free pacemakers, implantable cardioverter-defibrillators (ICDs), cardiac resynchronization devices without defibrillation (CRT) or with defibrillation (CRT-D), leaded or leaded monitoring devices, or extravascular implantable cardioverter-defibrillators (EVICDs).

Various types of patient wearable sensors can be used and operably coupled to the circuitry of the patient wearable device 204 for use in providing patient data. Non-limiting examples of patient wearable sensors include an external electrical sensor with one or more electrical contacts (e.g., electrodes), a biochemical sensor, a motion sensor (e.g., a three-axis accelerometer), a piezoelectric sensor, an optical sensor, a body temperature sensor, a geographic location sensor (e.g., a GPS sensor), or a microphone.

One or more patient wearable sensors may be incorporated into or operably coupled to various patient wearable devices 204. Non-limiting examples of patient wearable devices 204 include a heart rate monitor, a smart watch, a perfusion sensor (e.g., a pulse oximeter), a patch for monitoring vitals and monitoring activity, a hearing aid with the ability to detect activity and vitals (e.g., core body temperature), or a pendant-like device for measuring activity.

Various types of external sensors can be used and operably coupled to the circuitry of the external device 206 for use in providing patient data. Non-limiting examples of external sensors include an image sensor, a weight scale, a pressure sensor, or a microphone.

One or more external sensors may be incorporated into or operably coupled to various external devices 206. Non-limiting examples of external devices 206 include smartphones, tablets, personal computers, home security cameras, therapy dispensers, weight scales, blood pressure cuffs, bed sensors for measuring sleep metrics such as bed exits and restlessness, or furniture.

The various sensors of the sensor system 150 can be used in a variety of ways to provide patient data. In one example, pressure sensors can be embedded in furniture such as a sofa or bed and used to provide respiratory data and heart rate.

In another example, the electrical sensors on the patient implantable device 202 or patient wearable device 204 may include electrical sensors used to monitor electrical activity to provide, for example, an electrocardiogram (ECG), impedance values, respiration data, or bodily fluid levels.

In another example, a three-axis accelerometer can be used to measure a patient's activity, changes in walking patterns, and frailty indicators (e.g., the time it takes to get up from the couch and walk a certain distance). An accelerometer and/or piezoelectric sensor can be used to measure S3 and S4 heart sounds (which may be present when a patient's fluid volume increases and heart failure begins to worsen). A temperature sensor can be used to measure daily changes in body temperature and assess infection risk.

One or more devices of the sensor system 150 may be operably coupled to a programmer 208 or an access point 210. The programmer 208 or access point 210 may be wirelessly or wired connected to one or more devices. For example, the programmer 208 and access point 210 may be wirelessly connected to the patient implantable device 202 to transmit and receive data. The programmer 208 and access point 210 may then be operably coupled to a network 212, which may include a local network, a wide area network, or the Internet, to further transmit and receive data.

The therapy delivery system 170 may include any suitable device for administering therapy to a patient. In some embodiments, the therapy delivery system 170 may include a drug dispenser containing one or more medications, an automated subcutaneous (SubQ) implantable or fully implantable therapy pump, an intravenous or intraperitoneal line, or a graphical or audible user interface for providing therapy information to the patient. The therapy delivery system 170 may be operably coupled to one or both of the network 212 and the therapy optimization system 160.

Drug dispensers may be used in some therapy delivery systems 170. Some drug dispensers may be configured to include two or more different receptacles or compartments for holding two or more different drugs or different dosages of the same drug (e.g., a diuretic, a hypertensive drug, etc.). The drug dispenser may be external, wearable, or implantable to administer the appropriate dosage of the drug according to a therapy regimen.

Some medication dispensers, such as the PILLO™ automated tablet dispenser from Pillo Corporation of Boston, MA, contain two or more compartments and release medication into a single container for use by the patient. Some medication dispensers also release medication directly into the body. These are described, for example, in U.S. Pat. Nos. 7,001,359, 7,054,782, 7,008,413, 7,264,611, and 7,160,284, which are incorporated by reference into this disclosure. An example of an implantable drug dispenser is a subcutaneous drug dispenser (e.g., a subcutaneous implantable device such as a drug delivery device such as the MiniMed PARADIGM® REVEL™ insulin pump from Medtronic, Inc. of Dublin, Ireland, or a subcutaneous device such as the SC2 injector from SC Pharmaceuticals, Inc. of Burlington, Mass., or the OmniPod® insulin management system from Insulet, Inc. of Acton, Mass.).

The medication dispenser may be configured to receive the treatment regimen via a communication signal via a data communication interface, which may include a transceiver or transmitter. In some embodiments, the data communication interface may utilize a wireless communication protocol, such as BLUETOOTH® technology.

In some embodiments, the drug dispenser may be configured to receive commands to adjust the dosage or type of drug administered. In some embodiments, the drug dispenser may be configured to send a signal to another implantable medical device (such as a LINQ™ pacemaker) or an external device (such as a smartphone) to provide information (e.g., that drug levels are depleted or critically low).

The drug dispenser may be configured to receive instructions to dispense or otherwise administer to facilitate ensuring that the patient has access to the correct medication and/or dosage of medication. Once the therapy optimization system 160 has determined one or more medications for a treatment regimen, the therapy optimization system 160 may automatically send a signal to the therapy delivery system 170 to administer the medication according to the updated treatment regimen. The therapy optimization system 160 may send a signal to the therapy delivery system 170 to adjust the dosage delivered to the patient, for example, to increase or decrease the dosage based on the updated treatment regimen.

The therapy delivery system 170 can automatically switch from a first dosage compartment to a second dosage compartment for drug delivery. The drug dispenser, or therapy delivery device, can rotate from a first dosage compartment storing a first dosage to a second dosage compartment storing a second dosage for delivery to the patient. The therapy delivery device may or may not automatically notify the patient that the therapy regimen has changed. The therapy delivery device can automatically notify the patient to take their medication during the day. The therapy or drug can be automatically administered to the patient at the proper dosage. The therapy delivery device may be set to automatically lock the drug delivery mechanism once the proper dosage has been delivered.

The therapy optimization system 160 may include any suitable device for optimizing therapy and determining a patient's treatment regimen. In some embodiments, the therapy optimization system 160 may be integrated with the therapy delivery system 170 or may be located on a server connected to other parts of the therapy management system 100 via network 212.

A therapy delivery system 170 that can control the amount of therapy administered to a patient can provide robust feedback in the form of therapy compliance data. In some embodiments, the therapy delivery system 170 cannot control the amount of therapy administered, but can provide therapy compliance data that indicates whether the patient has at least accessed and possibly received the therapy. For example, the therapy delivery system 170 may only include a drug container that can indicate whether the container has been opened. For example, the container may include a wireless tag that can provide a signal to another device, such as a smartphone or smart speaker, when the container is opened or whenever the container is opened. Such a therapy delivery system 170 can be used, for example, when a patient is on vacation and an override mode is active, as described herein with respect to FIG. 4.

Some therapy delivery systems 170 may include a graphical or audible user interface to provide therapy information, such as dosage or other therapy information, to the patient. In one example, the graphical or audible user interface may suggest to the patient to avoid salt that day due to a high risk score.

One or more systems of the therapy management system 100 may include one or more computing devices having a data communication interface 220, a processor 222, and a memory 224. In particular, one or more systems may include one or more controllers, sensors, or interfaces, each of which may include a processor 222, such as a central processing unit (CPU), computer, logic array, processing circuit, or other device capable of sending data within or outside the system. Each system may include circuitry used to couple various components of the controller together or with other components operably coupled to the processor 222. The functions of the processor 222 may be implemented by hardware and/or as computer instructions on a non-transitory computer-readable storage medium.

The processor 222 may include any one or more of a microprocessor, a microcontroller, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), and/or equivalent discrete or integrated logic circuitry. In some examples, the processor 222 may include multiple components, such as any combination of one or more microprocessors, one or more controllers, one or more DSPs, one or more ASICs, and/or one or more FPGAs, as well as other discrete or integrated logic circuitry. The functionality attributed to the controller or processor 222 herein may be embodied as software, firmware, hardware, or any combination thereof. Although described herein as a processor-based system, alternative controllers may utilize other components, such as relays and timers, alone or in combination with a microprocessor-based system, to achieve the desired results.

In one or more embodiments, the exemplary systems, methods, techniques, and other related functions may be implemented using one or more computer programs using a computing device that may include one or more processors 222 and/or memory 224. The program code and/or logic described herein may be applied to input data/information using data communications interface 220 to perform the functions described herein and generate desired output data/information. The output data/information may be applied as input to one or more other devices and/or methods as described herein or may be applied in a known manner using data communications interface 220. In view of the above, it will be readily apparent that the controller or processor functions described herein may be implemented in any manner known to one of ordinary skill in the art.

The network 212 may generally be used to transmit information or data (e.g., patient data such as physiological data, risk level data, recovery data, etc.) between the several devices of the treatment management system 100 or between the paging devices. However, the network 212 may also be used to transmit information to other external computing devices (e.g., the CARELINK® system available from Medtronic, Inc.).

Typically, wireless connections may be used. In one example, the proprietary implantable device 202, the patient wearable device 204, the external device 206, the programmer 208, the access point 210, the therapy optimization system 160, and the therapy delivery system 170 may be interconnected and communicate with each other directly or via a network 212.

The various systems of the treatment management system 100 may include one or more servers, computers, weight scales, portable blood pressure monitors, biometric data collection devices, a computer, a symptom assessment system, a personal digital assistant (e.g., a mobile phone, tablet, etc.). In some examples, the various devices of the treatment management system 100 may generate data to perform any of the various functions or operations described herein, such as generating a heart failure risk state based on patient metrics comparisons or creating patient metrics from raw metric data.

Heart failure (HF) risk status can be calculated in a number of ways known to one of skill in the art having the benefit of this disclosure. One example of calculating a risk score or risk status is described in U.S. Patent Publication No. 2019/0069851, filed August 31, 2018, and U.S. Patent Publication No. 2019/0125273, filed April 26, 2018, which are incorporated by reference into this disclosure.

The various data communication interfaces 220 may also include user interfaces. In some embodiments, one or more of the data communication interfaces 220 of the therapy management system 100 may include input devices such as a keyboard, mouse, voice input, weight sensor, or an output device such as a graphical or audible user interface (e.g., for touch screen input or voice commands), a printer, or other suitable means.

One or more processors 222 of the therapy management system 100 may be configured to perform some type of analog-to-digital conversion so that the signal can be compared to some threshold value. Each processor 222 may be configured to perform various functions such as calculations, accessing data in memory, performing comparisons, setting start and end dates for each evaluation period, etc. The evaluation periods serve as evaluation windows that encompass the data acquired from each patient and that fall within the boundaries (e.g., start and end times).

Various memories 224 of the therapy management system 100 may include volatile, non-volatile, magnetic, optical, or electrical media, such as random access memory (RAM), read only memory (ROM), non-volatile RAM (NVRAM), electrically erasable programmable ROM (EEPROM), flash memory, or any other digital or analog media. In general, the memory 224 may store data such as patient data, which may include heart failure patient data, heart failure prediction risk data, intracardiac or intravascular pressure, activity, posture, respiration, thoracic impedance, impedance trends, risk of hypervolemia or hypovolemia, and the like. Also, start and end times or dates of an evaluation period may be stored in the memory 224. In some cases, the patient data may include data observations (e.g., data sensed from a sensor exceeding a threshold).

The programmer 208 may include any suitable programming system, including those commonly known to those skilled in the art, such as a Medtronic CARELINK™ programmer from Medtronic.

The therapy optimization system 160 can send a request to a device of the sensor system 150, such as the patient implantable device 202, via the programmer 208, for example. The patient implantable device 202 can provide the programmer 208 with patient data (e.g., diagnostic information, real-time data related to absolute intrathoracic impedance that may indicate hypervolemia or hypovolemia, etc.) or diagnostic information based on the patient condition selected by the request or already entered. The patient data can include patient metric values or other detailed information from the patient implantable device 202.

The patient data may be used to provide an alert or notification of the HF risk level by the therapy optimization system 160. An alert may be automatically sent or pushed when the HF risk level becomes critical. Additionally, the alert may be a notification of the risk level to a medical professional, e.g., a clinician or nurse, and/or instructions to the patient 50 to receive treatment (e.g., tests to confirm worsening HF, etc.). In response to receiving the alert, the user interface may display an alert to the medical professional regarding the risk level or present instructions to the patient 50 to receive treatment.

In response to either the heart failure data, e.g., risk level or patient metrics, or the requested heart failure information, the user interface of the computing device or programmer 24 may present the patient metrics, heart failure risk level, or recommended treatment (e.g., medication) to the user. In some examples, the user interface may also highlight patient metrics that exceed respective metric-specific thresholds. In this manner, the user can quickly see which patient metrics are contributing to the identified heart failure risk level.

The access point 210 may comprise a device that connects to the network 112 via any of a variety of connections, such as a telephone dial-up, digital subscriber line (DSL), or cable modem connection. In other examples, the access point 210 may be coupled to the network 112 via a different form of connection, including a wired or wireless connection. In some examples, the access point 210 may be co-located with the patient 50 and may comprise one or more programming units and/or computing devices (e.g., one or more monitoring units) that may perform the various functions and operations described herein.

In another example, the access point 210 may be a LINQ™ device co-located within the patient and configured to sense, record, and transmit data to the network 112. Alternatively, a wearable patch such as a SEEQ™ device configured for monitoring may be attached to the patient's skin. For example, a SEEQ™ device may be attached to the patient's skin over the heart for cardiac monitoring. In another example, the access point 210 may include a home monitoring unit that may be placed within the patient 50 and monitor the activity of the IMD 16. LINQ™ and SEEQ™ devices available from Medtronic, Inc. may also be used as the access point 210. Non-limiting examples of LINQ™ devices are described with respect to U.S. Publication No. 2016/0310031, filed April 20, 2016, which is incorporated by reference into this disclosure.

The therapy optimization system 160 may include or be part of a centralized communication center staffed by one or more skilled nurses and an established workflow for managing/treating patients across a spectrum of episode severity (e.g., hypotensive vs. normotensive decompensated HF patients). The therapy optimization system 160 may be configured to perform complex calculations for large patient populations and may provide secure storage in memory for archiving of information collected and generated from the sensor system 150 and therapy delivery system 170 (e.g., patient metric data, heart failure risk level, weight, blood pressure, etc.).

FIG. 3 is a flow diagram illustrating an example of a method for using the treatment management system of FIG. 1. As shown, the method 300 may include determining 302 patient data. The patient data may be provided by a sensor system, which may include an implantable device, a wearable device, or an external device. Some patient data may be provided automatically and other patient data may be provided to ascertain a risk score.

The risk score can be used to determine a patient score. The method 300 can include optimizing 304 the treatment using the patient score. A treatment regimen can be generated or determined that reflects the optimized treatment. Generally, optimizing the treatment minimizes the patient score, which typically corresponds to risk, treatment differentials, and symptom reduction.

The method 300 may include administering 306 a therapy based on the generated optimal therapy regimen, for example. Administering the therapy may include providing a predetermined dosage to a patient who is willingly receiving the therapy, or providing an automatic delivery of the therapy (e.g., an automatic therapy pump or oxygen machine setting into the patient's body).

Additionally, the method 300 may include determining 308 treatment compliance data, e.g., in response to administering the treatment. The treatment compliance data may provide some indication of whether the patient has complied with the administered treatment. For example, a camera placed on or near a medication dispenser may identify the patient as taking the dispensed medication, which may provide at least some verification of the patient's compliance with the treatment regimen.

Further, the method 300 may return in an iterative or closed loop to determining patient data 302, optimizing treatment using the patient score 304, and administering treatment 306. Treatment compliance data may be used to optimize treatment or update a treatment regimen. For example, treatment compliance data may indicate whether a patient actually received a previously administered treatment regimen, which may be used to determine an appropriate treatment regimen to administer next. In particular, patient scores may be updated based on treatment compliance data. For example, a risk score may change based on treatment compliance data as described herein with respect to FIG. 4.

FIG. 4 is a state diagram illustrating an example of a method for implementing the optimization treatment method of FIG. 3 using multiple generators. In particular, FIG. 3 illustrates the use of two generators. As shown, the method 320 may include a state 322 of delivering treatment and collecting data. The collected data may include, for example, patient data, treatment compliance data, and associated treatment data.

The method 320 may also include a risk prediction or status 324 of risk score generation by a risk score generator, which may follow the delivery of treatment and data collection 322. The risk score generator may be used to generate one or more risk scores based on collected data, such as new or updated patient data or data regarding a current treatment regimen. The risk score generator may be stored in a memory of the treatment optimization system.

"Risk" score refers to a measure that may be indicative of a patient's declining health. Non-limiting examples of declining patient health include increased risk of hospitalization, increased risk of death, or other signs of general declining health.

In general, patient data may be used to determine one or more risk scores. For example, if a patient's blood pressure increases, the risk score associated with hypertension (and overall risk score) may also increase. A current treatment regimen may be used to adjust a particular risk score. For example, if a patient is treated for hypertension by administration of a maximum tolerated level of an ACE inhibitor, the risk score associated with hypertension may further increase. In another example, even if a patient's blood pressure remains unchanged from a high level even after administration of a maximum tolerated level of an ACE inhibitor, the risk score associated with hypertension may still increase.

The method 320 may also include a status 326 of generating a treatment regimen by a treatment regimen generator. The treatment regimen generator may be used to determine a treatment regimen based, for example, on one or more risk scores provided by the risk score generator. As described herein, the generated treatment regimen may be within the range of treatment regimens prescribed by a physician. The treatment regimen generator may also determine a treatment regimen based on other data and scores, such as treatment scores or symptom scores. The treatment regimen generator may be stored in a memory of the treatment optimization system. In some embodiments, the treatment regimen generator does not use patient data as a direct input, but rather determines an updated treatment regimen based on patient scores and past treatment regimen data. In general, the risk score generator and the treatment regimen generator are separate and distinct in that each has different inputs and different outputs than the other.

In general, the treatment regimen generator can generate a treatment regimen based on an overall patient score, which can be a combination of one or more scores. The treatment regimen generator can provide new treatment regimens to lower or minimize the overall patient score. In general, as used herein, a lower overall patient score is defined as corresponding to a better patient condition than a higher overall patient score. However, in some embodiments, a higher overall patient score can be defined as corresponding to a better patient condition than a lower overall patient score.

A treatment regimen may also be generated based on information about one or more previous treatment regimens. The previous treatment regimen data may be used to update the patient score. For example, if a previous treatment regimen to lower blood pressure did not reduce the patient's hypertension, the patient score may increase, and thus the new treatment regimen may increase the dosage of the ACE inhibitor or introduce a different treatment for hypertension.

In general, the treatment regimen generator may update a patient score in response to administration of a previous treatment based on the previous treatment regimen, determine a treatment regimen in response to the updated patient score and the previous treatment regimen, and provide the treatment regimen to the treatment delivery system.

The method 320 can return to treatment delivery and data collection 322 after treatment regimen generation 326 in an iterative or "closed loop" manner to continue delivering treatment, collecting data, generating a risk score, and updating the treatment regimen.

In some embodiments, the treatment regimen generation 326 or treatment delivery and data collection 322 of method 320 can enter an override mode. In the override mode, the treatment regimen or administration of treatment can be interrupted in some manner. For example, the override mode can indicate that the treatment regimen should not be updated for a period of time or that treatment should not be administered for a period of time.

Various triggering events may initiate the override mode, which may be detected by one or more sensors or devices of the treatment management system. In some embodiments, physician input may trigger entry into the override mode, such as when the patient is in the clinic or hospital and the physician is administering treatment. Administration of treatment and generation of updated treatment regimens may be suspended during the override mode. Physician input may trigger exit of the override mode (e.g., disable, turn off, etc.) when the patient is ready to leave.

In some embodiments, patient input may trigger or initiate entry into the override mode, such as when the patient plans to be away from the home therapy delivery system on a vacation or other trip. Administration of therapy and generation of an updated therapy regimen by the home therapy delivery system may be interrupted, for example, because dosage changes or different therapy are not readily accessible while the patient is away from the home therapy delivery system. Patient input may trigger exit of the override mode when the patient returns to the home therapy delivery system.

In some cases, the therapy delivery system may be portable. The portable therapy delivery system may provide some or all of the same functionality as the home therapy delivery system. In other words, the portable therapy delivery system may be able to administer different therapies to the patient, at least to some extent, based on an updated therapy regimen. For example, the portable therapy delivery system may include a limited number of different dosages of the same drug or a limited number of different drugs. The patient may be notified by the portable therapy delivery system to take a certain amount of medication by a smartphone, which may be considered part of the portable therapy delivery system. In general, the portable therapy delivery system may enable the therapy management system to avoid or exit the override mode, in part or in whole.

Proximity sensors or other location-based sensors in the care management system can also be used to generate environmental data for triggering entry or exit of the override mode, for example, instead of requiring manual physician or patient input. In addition, data from other sources, such as GPS location from the patient's phone, can also be used to trigger entry or exit of the override mode.

Furthermore, in some embodiments, non-compliance with a treatment regimen may trigger an override mode or an increase in the overall patient score or one or more risk scores.

In some embodiments, the risk score generator or treatment regimen generator may be updated based on relevant treatment data. For example, other patients undergoing the same or similar treatments may generate data that can be used to update various best practices regarding risk or treatment. These generators can be updated or trained periodically, for example using updates, or may be updated in real time. For example, the risk score generator or treatment regimen generator can be stored in the cloud and used to generate risk predictions and treatments for one or more patients.

FIG. 5 is a flow diagram illustrating an example of a method for determining a patient score that can be used in the method of FIG. 3. As shown, a method 340 can be used to determine or update 350 a patient score in response to collecting 342 data. Although optimization of patient scores and other scores is generally described in terms of minimization, optimization of patient scores using maximum or target values is also contemplated in any suitable manner available to one of skill in the art having the benefit of this disclosure.

Based on the various types of data collected, one or more risk scores can be determined 344, with each risk score representing a different parameter or metric of risk. One or more of the risk scores can be based on patient data, which may include corroborated patient data. In some embodiments, the risk scores can be related to an underlying heart failure risk.

A risk score may represent an input parameter or a combination of input parameters. A composite risk score may represent some or all of the input parameters. Non-limiting examples of risk scores, or input parameters into a risk score, include an OPTIVOL™ score (e.g., impedance or impedance index representing fluid levels), a nocturnal heart rate (NHR) score (e.g., nocturnal ventricular rate), a patient activity score, a heart rate variability (HRV) score, an arrhythmia score (e.g., atrial tachycardia or atrial fibrillation score), a ventricular rate score (e.g., average heart rate during arrhythmia), a pacing score (e.g., ventricular pacing percentage of CRT), a shock score (e.g., number of shocks), respiration, tissue perfusion, temperature, a treated arrhythmia score, COPD risk, stroke risk, renal failure risk, VT/VF risk, acute decompensation risk, high or low potassium risk, high or low glucose risk, or sleep arrhythmia risk.

Various diagnostic metrics or metrics that can be used to determine a risk score can be extracted from the patient data. Non-limiting examples of patient data include: (1) impedance trend index available from Medtronic in IMDs, (2) intrathoracic impedance, (3) atrial tachycardia/atrial fibrillation (AT/AF) burden, (4) average ventricular rate during AT/AF, (5) patient activity, (6) ventricular (V) rate, (7) daytime and nighttime heart rate, (8) percent CRT pacing, or (9) number of shocks.

Some examples of medium and high risk calculations performed by the treatment optimization system are described in U.S. Patent Publication No. 2016/0361026, filed March 29, 2011, U.S. Patent Publication No. 2012/032243, filed October 28, 2010, U.S. Patent Publication No. 2019/0069851, filed August 31, 2018, and U.S. Patent Publication No. 2019/0125273, filed April 26, 2018, which are incorporated by reference into this disclosure.

For example, medium risk conditions may include one or more conditions such as AT/AF load above threshold (>6 hrs/day), low %V pacing, and high nighttime heart rate (>85 bpm). For example, high risk conditions may include one or more conditions such as high OPTIVOL™/impedance index (>60 ohm-day), patient activity (<1 hr/day), high nighttime heart rate (>85 bpm), and low HRV (<60 ms).

The impedance index can be an indication of the amount of fluid congestion experienced by the patient. The impedance index is, for example, the difference between the impedance measured daily using a patient-implantable device and a baseline impedance that can be continually updated and established by the patient-implantable device or during a physician's visit. A non-limiting example of determining and using the impedance index is described in U.S. Patent No. 7,986,994, issued July 26, 2011, which is incorporated by reference into this disclosure.

Heart rate variability (HRV) can be a marker of autonomic tone and may provide prognostic information for mortality risk. Decreased HRV is associated with increased sympathetic tone or elevated risk scores. Using diagnostic data from HRV devices, patients with low HRV (<100 ms) may be at higher risk for combined mortality and hospitalization. Patients with HRV below 50 ms may be at even higher risk than those with HRV in the range of 50-100 ms.

Similar to HRV, elevated heart rate may be a marker of elevated sympathetic tone and has been shown to have prognostic value for worsening HF or higher risk scores. Nocturnal heart rate (NHR), measured between midnight and 4:00 a.m., may be a better indicator than daytime heart rate, which may be affected by different activity levels (e.g., rest and exercise). Patients with high NHR (75±25 bpm) are typically at higher risk of hospitalization or death than those with low NHR (73±11 bpm).

Furthermore, decreased patient activity may help predict HF hospitalization as it is associated with worsening HF status, which may correspond to a higher risk score. Decreased patient activity can be determined by various activity devices, such as FITBIT® devices, mobile phones, and smartphones.

Combination variables (e.g., combining pacing and arrhythmia-related information) can also be used to assess worsening HF risk or higher risk scores. For example, one component of the combination variable is a large reduction in CRT pacing (>8%), which is associated with high HF events. A reduction in CRT pacing can occur due to rapid conduction during AF. Thus, mean ventricular rate ≥ 90 bpm and atrial fibrillation (AF) load ≥ 6 hours/day, and shocks delivered into ventricular fibrillation/ventricular tachycardia (VT/VF) can also be components of the combination variable.

In general, the treatment management system can provide an updated treatment regimen to lower the risk score (or overall risk score) and bring each of the variables into a constant and stable region, minimizing the risk score (or overall risk score). In some embodiments, baseline medications can be maximized and diuretics can be lowered to keep the physiological variables within the normal range.

Based on the collected data, one or more treatment scores 346 may be determined, each associated with a different treatment. In particular, a treatment score may be determined based on the difference between a physician-based treatment regimen and a current treatment regimen being administered to the patient.

In some embodiments, the treatment regimen may include multiple different therapies. Non-limiting examples of therapies that may be included in the treatment regimen include diuretics, heart failure medications (e.g., beta blockers, ACE inhibitors, ARBs, hydralazine, nitrates, ENTRESTO™ sacubitril/valsartan) and mineralocorticoids), stroke medications, blood pressure medications (e.g., ACE inhibitors or beta blockers and calcium channel blockers), oxygen (e.g., in COPD), steroids (e.g., in COPD), physical activity (e.g., exercise), dietary recommendations, dietary supplements, sugar pills, oral insulin, Parkinson's/tremor medications, or anticoagulants.

The difference may be calculated for each treatment and incorporated into one or more treatment scores. The difference may also be described as a deviation from the physician-based treatment regimen. For example, the difference in the treatment regimen may be caused by one or more of the patient scores or other scores, such as the symptom scores, which may affect the patient score and thus the treatment regimen generated by the treatment optimization system. In some embodiments, if the risk score and symptom score are constant and stable, the current treatment regimen may be titrated toward a physician-based treatment regimen that may minimize the treatment score. The physician-based treatment regimen may be determined based on the physician's input and stored in the memory of the treatment management system.

Based on the collected data representing one or more patient symptoms, one or more symptom scores can be determined 348. In general, the symptom score may be indicative of other patient symptoms not reflected in the risk score. The symptom score can be determined based on the patient's mood and may be independent of the risk score or treatment score. For example, a patient may have a low risk score but experience side effects from a treatment that result in a high symptom score. One example of a side effect is that a patient may develop a cough from a beta blocker. The symptom score may be based on patient data from sensor data or patient input. For example, a patient may input a sensation of pain into a smartphone user interface, which may be used to generate a symptom score. In response, the treatment management system may decrease or otherwise modify one or more treatments to alleviate the patient's symptoms, which may minimize the patient's score.

An overall patient score may be determined or updated 350 based on at least one of the score factors, which may include one or more of a risk score, a treatment score, and a symptom score. One or more score factors may be calculated and combined in any suitable manner to facilitate minimizing patient risk, treatment discrepancies or deviations, and patient symptoms when generating a treatment regimen.

One or more calculated risk scores can be weighted. A weighting function can be applied to one or more risk scores that can be monotonic, non-linear, or both monotonic and non-linear. In one example, the weighting function can be an increasing monotonic non-linear function.

The weighting function may be continuous and may include inflection points associated with thresholds or pseudo thresholds. For example, as the risk score increases beyond a certain threshold, the weighted risk score may increase dramatically, which may have the effect of prioritizing the risk score over other risk scores, treatment scores, or symptom scores that have not reached a similar threshold or pseudo threshold. Each risk may include a different inflection point or pseudo threshold, or an entirely different risk profile.

Various functions can also be applied to the treatment deviations to provide a treatment score, or to the symptom data to provide a symptom score. Weighting functions can also be applied to one or more of the treatment or symptom scores.

Sums can be used to combine multiple scores. For example, multiple risk scores can be combined using the sum of multiple weighted risk scores.

One or more risk scores, treatment scores, and symptom scores, whether weighted or not, can be combined as inputs to a function that generates an overall patient score. The function can adjust the score coefficients such that minimization (or maximization) of the patient score generally balances the minimization of risk factors, treatment deviations, and patient symptoms. In one example, the scores can be summed.

FIG. 6 is a flow diagram illustrating an example of implementing the optimization treatment method of FIG. 3 using risk score evidence. As shown, the method 360 may include collecting 362 data, such as patient data, treatment compliance data, and related treatment data.

The method 360 may also include determining 364 whether the risk score has changed, for example, based on the collected data. The risk score may change or remain the same based on previous treatments provided.

Further, the method 360 may include determining 366 whether patient input is required. If patient input is required, a request is provided to the patient to provide more information (e.g., answer a question) or to take a patient action (e.g., step on a scale) to gather additional data.

The method 360 may include, for example, in response to determining 366 that patient input is required, corroborating 368 the risk score using patient data, such as patient input. In one example, the patient data may indicate a high risk score associated with blood pressure, and the patient may be asked to stand in front of a camera to record an image of the patient's eye. The image of the patient's eye may be used to confirm or corroborate the presence of a high risk score associated with blood pressure, which may represent a blood pressure outside of an acceptable range.

The method 360 may include, for example, updating or determining a patient score 370 in response to confirming the risk score 368 or in response to determining that no further patient input is required 366. The patient score may be used to assess the overall condition of the patient.

In addition, the method 360 may include determining 372 whether the patient is stable, for example after administering treatment according to the current treatment regimen. Patient stability may be determined by comparing an overall patient score, one or more risk scores, one or more treatment scores, or one or more symptom scores to a threshold. In the illustrated embodiment, whether the patient is stable is related to whether one or more risk scores are within a stable or non-stable region. In particular, the patient may be determined to be stable or unstable based on whether one or more risk scores exceed a particular threshold that defines a boundary between the stable and non-stable regions.

The stability threshold may correspond to a threshold magnitude value of the score, a threshold rate of change of the score, or both. In one example, a patient with a high but stable risk score may be considered unstable. In another example, a patient with a low risk score that increases dramatically but remains low may also be considered unstable.

The method 360 may include, for example, determining 374 a treatment regimen to stabilize the risk score in response to determining that the patient is not stable based on one or more risk scores. The treatment regimen to stabilize the risk score may prioritize reducing or stabilizing the risk score (e.g., reducing a magnitude value or reducing a rate of change value) over reducing or stabilizing other scores, such as treatment scores or symptom scores.

In some embodiments, the threshold value can be based on the continuous function used to generate one or more scores and the function used to combine them with the patient score. Thus, the threshold value may be fixed or determined based on a relative value to other scores.

The method 360 may include, for example, determining 376 a treatment regimen to optimize an overall patient score in response to determining that the patient is stable based on one or more risk scores. The treatment regimen to optimize an overall patient score may balance risk scores, treatment scores, and symptom scores without necessarily favoring one type of score over the others. In some embodiments, if the patient is stable, the treatment regimen determined based on the treatment score may titrate one or more treatments used in a previous treatment regimen, for example, toward a physician-based treatment regimen.

Additionally, the method 360 may include, for example, after determining a treatment regimen at 374 or 376, providing the determined treatment regimen 378 to administer the treatment. The treatment regimen may be provided to a treatment delivery system and administered.

Further, the method 360 may include verifying 380 compliance with the administered treatment. For example, an image of the user's face may be recorded when the medication is dispensed from the medication dispenser to identify the patient. Such compliance data may be used by the method 360, for example, to update 370 the patient score.

In some embodiments, the patient may not be stable 372 and the patient score may indicate that physician input is required instead of management by the care management system. For example, the overall HF risk score may exceed a higher threshold level indicating an HF event, which may suggest that the patient needs to be seen by a nurse or physician at a hospital, emergency department, ambulance, observation unit, urgent care, or HF/cardiology clinic. In such cases, the care management system may automatically notify the nurse or physician as well as the patient and go into override mode to stop administration of therapy.

Figures 7-8 illustrate the use of physician-restricted treatment regions to manage patient treatment. Figure 7 is a flow diagram illustrating an example of integrating physician input to implement the optimized treatment method of Figure 3. Figure 8 is a conceptual diagram illustrating an example of a physician-restricted parameter region that can be used in the method of Figure 7.

As shown, the method 400 may include receiving 402 a physician-limited parameter field for a given patient. The physician-limited parameter field 402 may be different for different patients, different health conditions (e.g., HF class, NYHA II vs. NYHA III, etc.), and different treatments (e.g., specific medications or drugs). The physician-limited parameter field may be based on physician input, e.g., indicating an acceptable range of parameters that the treatment management system may use to administer treatment to the patient without further physician input between physician visits. The physician-limited parameter field may be stored in a memory of the treatment management system and may be described as a predetermined physician-limited or physician-guided parameter field.

The method 400 may include, for example, updating 404 a patient score based on the collected data. The patient score may be updated in the same or similar manner as updating the patient score 370 of FIG. 6.

The method 400 may also include updating 406 the treatment regimen, for example, based on the collected data. The treatment regimen may be updated in the same or similar manner as treatment regimen generation 326 of FIG. 4.

Once the treatment regimen is updated or determined, the method 400 may include determining 402 whether the treatment regimen is within a physician-limited parameter region.

This determination can be based on a comparison of the treatment regimen to the physician-limited parameter domain for one or more treatments. In some embodiments, a patient score, one or more risk scores, one or more treatment scores, or one or more symptom scores are determinations that can be made in addition to or as an alternative to directly comparing the treatment regimen to the physician-limited parameter domain. For example, the physician-limited parameter domain can include limits on various scores, or scores associated with the physician-limited treatment regimen can be calculated for comparison.

The method 400 may include, for example, in response to determining 408 that the treatment regimen is within the physician-limited parameter region, providing 410 the treatment regimen to a treatment delivery system to administer the treatment. After administering the treatment, the method 400 may return to updating 404 the patient score. The physician-limited parameter region may again be received or updated 402 each time the patient is seen by a physician.

Additionally, the method 400 may include initiating a process 412 of contacting a physician, for example, in response to determining 408 that the treatment regimen is outside the physician restricted parameter region (e.g., within the physician assistance region). For example, a treatment regimen outside the physician restricted parameter region may indicate that the treatment management system cannot provide effective treatment of one or more risks or symptoms based on the treatments available in the physician restricted parameter region. The method 400 may return to receiving 402 an updated physician restricted parameter region.

An example of a physician restricted treatment region is shown in plot 420, which shows a physician restricted region 422 and a physician assistance region 424. Physician restricted region 422 may also be described as a threshold region. The boundary 426 between physician restricted region 422 and physician assistance region 424 may also be described as a threshold.

Physician limits area 422 may define one or more parameters for a treatment within which the treatment management system may operate. Non-limiting examples of parameters that may be defined by physician limits area 422 include treatment dose, frequency of administration, or cumulative treatment dose over time.

In some embodiments, the physician restriction area 422 may take the shape of a triangle or other geometric shape, for example, when shown in a graph of dosage versus time. As shown, a triangular shape may indicate that a lower dosage may be administered over a wider range of time, compared to a higher dosage that may only be allowed to be administered for a shorter period of time.

9 is a conceptual diagram illustrating an example of a therapy delivery system that may be used with the therapy management system of FIG. 1. As illustrated, FIG. 9 shows a therapy delivery system in the form of a drug dispenser 500. The drug dispenser 500 may include a housing 502 that includes one or more receptacles 506 or compartments. A communication interface 504 may be coupled to the housing 502. The one or more receptacles 506 are configured to receive or hold one or more cartridges 508. For example, one receptacle 506 may be configured to receive one cartridge 508 or multiple cartridges. Generally, the drug dispenser 500 is configured to hold two or more cartridges 508.

Each cartridge 508 may include or be coupled to a unique medication identifier 510. The medication identifier 510 may be detectable by the communications interface 504 and used by the medication dispenser 500 to identify which medication is contained in each cartridge 508 and where the cartridge 508 is located in one or more receptacles 506. For example, the medication identifier 510 may be an RFID tag that is detectable using an RFID transceiver in the communications interface 504. Other types of medication identifiers include optical and electrical encoders.

In some embodiments, each cartridge 508 contains a different drug or a different dose of a drug. By tracking the drug identifiers 510, the drug dispenser 500 may be able to dispense a particular drug from a particular cartridge 508 as indicated by the current treatment regimen. In other words, the cartridges 508 may be inserted into the drug dispenser 500 in any position or order, yet the drug dispenser may still be able to distinguish the position of each cartridge. The dispensed drugs may be poured into a single cup or other container 512 for use by the patient to administer the administered medication.

The communication interface 504 may also be configured to transmit a request to deliver one or more new cartridges 508. For example, the communication interface 504 may provide instructions over the internet to initiate delivery of a particular cartridge 508 from a remote location to a patient's home for the patient to keep on hand. The patient or a delivery service may insert the cartridge into a receptacle 506 of the medication dispenser 500. As each cartridge 508 is used, a new cartridge may be ordered, which may contain the same drug or dose of drug as the empty cartridge, or a different drug or dose of drug, depending on the requirements of the current treatment regimen.

In some embodiments, each cartridge 508 may be sealed and inaccessible to the patient or person loading the cartridge 508 into the receptacle 506. The cartridge 508 may be accessible only to the medication dispenser 500.

Each cartridge 508 may be configured to be inserted into a respective receptacle 506 to load the receptacle with the respective drug. In other embodiments, each cartridge 508 may be attached to a drug dispenser 500, which may empty the drug from the cartridge into the appropriate one or more receptacles 506 and load the receptacles. The drug dispenser 500 may track which receptacle is loaded with which drug based on a drug identifier 510 associated with the cartridge upon loading. In other words, the drug dispenser 500 may process to ensure that each drug from each cartridge 508 reaches the appropriate receptacle 506. After being emptied, each cartridge 508 may be discarded.

The communication interface 504 may be configured to detect the drug identifier 510 before, during, or after loading of each cartridge 508. For example, in some embodiments in which the cartridge 508 is emptied to load a receptacle, the drug identifier 510 may be detected before or at the same time the cartridge 508 is attached to the drug dispenser 500.

10 is a conceptual diagram illustrating an example of managing a patient's treatment using the method of FIG. 3. As shown, plot 600 illustrates how different treatment regimens are administered based on changes in fluid level risk score (e.g., impedance risk score). In plot 600, time is plotted on the x-axis and dosage or fluid level is plotted on the y-axis. In the illustrated example, the treatment management system adjusts treatment to keep the patient in a constant and stable region even if the fluid level risk score is in a stable region based on magnitude but not based on rate of change (e.g., below an OptiVol™ high threshold such as 60 ohm-days but changing rapidly). For example, if fluid levels increase at time 2, the treatment management system increases loop diuretics and electrolytes at time 2. If fluid levels decrease at time 3, loop diuretics and electrolytes are decreased at time 4. If fluid levels increase again at time 5, diuretics and electrolytes are also increased again at time 5. Other medications such as ACE inhibitors and beta blockers may not change depending on the risk factors.

11 is a conceptual diagram illustrating another example of managing a patient's therapy using the method of FIG. 3. As shown, plot 650 shows diuretic therapy level, renal failure risk score, dietary sodium intake level, and HF hospitalization risk score. In plot 650, time is plotted on the x-axis and dosage or risk is plotted on the y-axis. The therapy management system can administer therapy to balance various risks, such as fluid levels and electrolyte levels (e.g., sodium).

As shown, the hospitalization for heart failure (AHF) risk score spikes at time 2 due to, for example, increased impedance from fluids. The care management system increases the diuretic and electrolyte dosage at time 2 in proportion to the increased risk of AHF. To keep the risk score for renal failure low, the care management system increases the diuretic dosage for a short period of time. As shown, if the AHF risk score drops at time 3, the diuretic dosage is returned to a low level at time 4 to maintain a low renal risk score. This balance of risk score and dosage not only keeps the AHF risk score and renal risk score low at the same time, but also keeps the patient's dosage as low as possible.

Although the present disclosure is not limited, an understanding of various aspects of the disclosure will be gained through a discussion of certain exemplary embodiments provided below. Various modifications of the exemplary embodiments, as well as additional embodiments of the present disclosure, will become apparent herein.

In embodiment A1, the therapy management system includes a sensor system for providing patient data related to the patient or an environment associated with the patient. The therapy management system also includes a therapy delivery system for administering therapy based on the therapy regimen and for providing therapy compliance data. The therapy management system further includes a therapy optimization system operably coupled to the sensor system and the therapy delivery system, for updating the therapy regimen based on the patient data from the sensor system and the therapy compliance data from the therapy delivery system, and providing the updated therapy regimen to the therapy delivery system.

In embodiment A2, the system includes a system according to any of the A embodiments, and the treatment optimization system is configured to update the treatment regimen at least daily.

In embodiment A3, the system includes a system according to any of the A embodiments, and the treatment optimization system is configured to automatically update the treatment regimen between physician inputs to maintain the patient in a stable region.

In embodiment A4, the system includes a system according to any of the A embodiments, where the treatment optimization system is operatively coupled to a remote system to receive relevant treatment data to train the risk score generator, the treatment regimen generator, or both, and update the treatment regimen.

In embodiment A5, the system includes a system according to any of the A embodiments, and the therapy optimization system includes an override mode for interrupting the therapy regimen or the therapy delivery system includes an override mode for interrupting delivery of therapy.

In embodiment A6, the system includes a system according to embodiment A5, and the treatment optimization system is configured to enter the override mode in response to physician input or environmental data.

In embodiment A7, the system includes a system according to any of the A embodiments, and the treatment optimization system is operatively coupled to the treatment delivery system via the internet or is integrated with the treatment delivery system in a single unit.

In embodiment A8, the system includes a system according to any of the A embodiments, wherein the treatment optimization system includes a treatment regimen generator for providing a treatment regimen based on one or more risk scores.

In embodiment A9, the system includes a system according to any of the A embodiments, wherein the treatment optimization system includes a risk score generator for providing one or more risk scores based on the patient data.

In embodiment A10, the system includes a system according to any A embodiment, and at least one of the therapy delivery system or the therapy optimization system is configured to collect patient data to support one or more risk scores.

In embodiment A11, the system includes a system according to any of the A embodiments, and the treatment optimization system includes a treatment regimen generator that provides a treatment regimen based on a patient score determined based on at least one score selected from a risk score, a treatment score, and a symptom score.

In embodiment A12, the system includes a system according to any of the A embodiments, and the sensor system includes at least one of a patient-implantable sensor, a patient-wearable sensor, an external sensor, a graphical user interface, or a memory for storing historical patient data.

In embodiment A13, the system includes a system according to embodiment A12, and the patient-implantable sensor includes at least one of an implantable electrical sensor including one or more electrical contacts, a biochemical sensor, a motion sensor, a piezoelectric sensor, an optical sensor, a body temperature sensor, a geographic location sensor, or a microphone operably coupled to the circuitry of the implantable medical device.

In embodiment A14, the system includes a system according to embodiment A12 or A13, and the patient-wearable sensor includes at least one of an external electrical sensor including one or more electrical contacts, a biochemical sensor, a motion sensor, a piezoelectric sensor, an optical sensor, a body temperature sensor, a geographic location sensor, or a microphone.

In embodiment A15, the system includes a system according to any of embodiments A12-A14, and the external sensor includes at least one of an image sensor, a weight scale, a pressure sensor, or a microphone operably coupled to the circuitry of the external device.

In embodiment A16, the system includes a system according to any A embodiment, and the therapy delivery system includes at least one of a drug dispenser containing one or more medications, an automated therapy pump, or a graphical user interface for providing therapy information to the patient.

In embodiment A17, the system includes a system according to any of the A embodiments, where the treatment delivery system includes a processor that transmits, via the communications interface, a request to deliver from a remote location one or more medications for on-site storage based on a treatment regimen.

In embodiment B1, the treatment optimization system includes a data communication interface operably coupled to a sensor system configured to provide patient data and a treatment delivery system configured to administer a treatment based on a treatment regimen. The treatment optimization system also includes a memory configured to store data representative of a risk score generator and a treatment regimen generator, and a processor operably coupled to the data communication interface and the memory. The processor is configured to update a patient score based on at least one score selected from one or more risk scores, one or more treatment scores, and one or more symptom scores in response to administering a previous treatment based on the previous treatment regimen, determine a treatment regimen in response to the updated patient score and the previous treatment regimen, and provide the treatment regimen to the treatment delivery system.

In embodiment B2, the system includes a system according to any B embodiment, and the treatment regimen is configured to minimize the patient score to minimize at least one of the risk score, treatment deviation, or patient symptoms.

In embodiment B3, the system includes a system according to any B embodiment, and the processor is further configured to update the patient score based on the treatment compliance data.

In embodiment B4, the system includes a system according to any B embodiment, and the processor is further configured to update the patient score based on patient corroboration of one or more risk scores.

In embodiment B5, the system includes a system according to any B embodiment, and the processor is further configured to update the patient score based on one or more monotonic, nonlinear, or monotonic and nonlinear functions applied to the one or more risk scores.

In embodiment B6, the system includes a system according to any B embodiment, and the treatment regimen includes administration of multiple different treatments.

In embodiment B7, the system includes a system according to any B embodiment, and the one or more symptom scores represent one or more patient symptoms determined based on sensor data or patient input.

In embodiment C1, the therapy optimization system includes a data communication interface operably coupled to a sensor system configured to provide patient data and a therapy delivery system configured to administer therapy based on a therapy regimen. The communication interface is configured to receive data representative of a predetermined physician-limited parameter region. The therapy optimization system also includes a memory configured to store data representative of the predetermined physician-limited parameter region, and a processor operably coupled to the data communication interface and the memory. The processor is configured to use the patient data to determine a patient score based on at least one of a risk score, a therapy score, or a symptom score, determine a therapy regimen based on the patient score, determine whether the therapy regimen is within the predetermined physician-limited parameter region, and, in response to determining that the therapy regimen is within the predetermined physician-limited parameter region, provide the therapy regimen to the therapy delivery system for administering therapy based on the therapy regimen.

In embodiment C2, the system includes a system according to any C embodiment, and the processor is further configured to initiate a physician contact process in response to determining that the treatment regimen is outside of a predetermined physician limit parameter region.

In embodiment C3, the system includes a system according to any C embodiment, and the processor is configured to initiate a physician contact process in response to determining that one or more scores selected from the risk score, the treatment score, and the symptom score are outside the threshold region.

In embodiment C4, the system includes a system according to any C embodiment, and the predetermined physician restricted parameter region is based on at least one of a therapeutic dose, a dosing frequency, or a cumulative therapeutic dose over time.

In embodiment D1, the treatment optimization system includes a data communication interface operably coupled to a sensor system configured to provide patient data and a treatment delivery system configured to administer treatment based on the treatment regimen. The communication interface is configured to receive the physician-based treatment regimen. The treatment optimization system also includes a memory configured to store data representing the physician-based treatment regimen, and a processor operably coupled to the data communication interface and the memory. The processor is configured to determine whether one or more risk scores are within a stability region representing stability of the patient after administering treatment according to the current treatment regimen, determine a treatment score based on a difference between the current treatment regimen and the physician-based treatment regimen in response to the one or more risk scores being within the stability region, determine an updated treatment regimen based on the treatment score, and provide the updated treatment regimen to the treatment delivery system.

In embodiment D2, the system includes a system according to any of the D embodiments, and the treatment regimen updated based on the treatment score is configured to minimize the patient score based on minimizing at least one of the risk score, the treatment score, or the symptom score.

In embodiment D3, the system includes a system according to any of the D embodiments, and the updated treatment regimen based on the treatment score includes a titration of one or more treatments used in the previous treatment regimen.

In embodiment D4, the system includes a system according to any of the D embodiments, and the processor is further configured to determine an updated treatment regimen based on the one or more risk scores in response to the one or more risk scores being within an instability region representing an unstable patient.

In embodiment E1, the present disclosure includes a therapeutic delivery system including a plurality of receptacles. Each receptacle is for holding a different drug or a different dose of a drug. The therapeutic delivery system also includes one or more cartridges. Each cartridge is for containing a different drug. Each cartridge includes a different drug identifier associated with a different drug or a different dose of a drug for loading into a respective receptacle. The therapeutic delivery system further includes a controller configured to detect each drug identifier of the one or more cartridges and transmit a request via the data communication interface to deliver a new cartridge associated with a particular drug identifier according to an updated therapeutic regimen.

In embodiment E2, the system includes a system according to any of the E embodiments, and the controller is further configured to deliver the request to a remote delivery system via the Internet using the data communications interface.

In embodiment E3, the system includes a system according to any of the E embodiments and further includes a data communication interface further configured to detect a drug identifier and a particular receptacle associated with each cartridge, where each cartridge is held such that a new cartridge can be placed into any of the receptacles.

In embodiment E4, the system includes a system according to any of the E embodiments, and the controller is further configured to load a drug in each of the one or more cartridges into each receptacle of the plurality of receptacles.

In embodiment E5, the system includes a system according to any E embodiment, and each drug identifier includes an RFID tag, an optical encoder, or an electrical encoder.

Thus, various embodiments of an adaptive therapy management system are disclosed. The various aspects disclosed herein may be combined in different combinations than those specifically presented in the description and accompanying drawings. It should also be understood that certain acts or events of any of the processes or methods described herein may be performed in different orders, or may be added, combined, or omitted entirely, depending on the example (e.g., not all described acts or events may be necessary to perform the techniques). In addition, while certain aspects of the disclosure are described as being performed by a single module or unit for clarity, it should be understood that the techniques of the disclosure may be performed by a combination of units or modules associated with, for example, a medical device.

In one or more embodiments, the described techniques can be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions can be stored as one or more instructions or code on a computer-readable medium and executed by a hardware-based processing unit. The computer-readable medium can include non-transitory computer-readable media that corresponds to tangible media, such as data storage media (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer).

The instructions may be executed by one or more processors, such as one or more digital signal processors (DSPs), general-purpose microprocessors, application specific integrated circuits (ASICs), field programmable logic arrays (FPGAs), or other equivalent integrated or discrete logic circuitry. Thus, the term "processor" as used herein may refer to any of the above structures, or any other physical structure suitable for implementing the described techniques. The techniques may also be implemented entirely in one or more circuits or logic elements.

All references and publications cited herein are expressly incorporated herein by reference in their entirety for all purposes, except to the extent that any aspect directly contradicts this disclosure.

All scientific and technical terms used herein have meanings commonly used in the art unless otherwise specified. The definitions provided herein are intended to facilitate understanding of certain terms used frequently herein and are not meant to limit the scope of the disclosure.

The terms "coupled" or "connected" refer to elements that are attached to each other either directly (in direct contact with each other) or indirectly (having one or more elements between the two elements that attach the two elements). Either term may be modified by "operatively" and "operably," which may be used interchangeably to describe that the coupling or connection is configured to allow the components to interact to achieve functionality.

As used herein, the term "configured" may be used interchangeably with the terms "adapted" or "structured," unless the content of this disclosure clearly dictates otherwise.

The singular forms "a," "an," and "the" include embodiments having plural referents unless the context clearly dictates otherwise.

As used herein, the words "have," "having," "include," "including," "comprise," "comprising," and the like are used in their open-ended sense and generally mean "including, but not limited to." "Consists essentially of," "consists of," and the like will be understood to be included in "including," and the like.

References to "one embodiment," "an embodiment," "a particular embodiment," or "some embodiments," or the like, mean that the particular features, configurations, compositions, or characteristics described in connection with that embodiment are included in at least one embodiment of the disclosure. Thus, the appearances of such language in various places throughout do not necessarily refer to the same embodiment of the disclosure. Furthermore, the particular features, configurations, compositions, or characteristics may be combined in any suitable manner in one or more embodiments.

Claims (13)

1. A heart failure therapy management system, comprising:
a sensor system for providing patient data regarding a patient or an environment associated with said patient using non-implanted and implanted sensors;
a heart failure therapy delivery system for administering therapy based on a therapy regimen and for providing therapy compliance data;
a heart failure therapy optimization system operatively coupled to the sensor system and the heart failure therapy delivery system, the heart failure therapy optimization system updating a heart failure therapy regimen based on the patient data from the sensor system and the therapy compliance data from the heart failure therapy delivery system, and providing the updated heart failure therapy regimen to the heart failure therapy delivery system;
A heart failure treatment management system comprising :
The heart failure therapy optimization system comprises:
a risk score indicating a decline in the patient's health;
a treatment score indicating the difference between the physician-based treatment regimen and the current treatment regimen being administered to the patient; and
a treatment regimen generator for providing the treatment regimen based on a patient score determined based on at least one score selected from symptom scores indicative of a patient symptom not included in the patient data.
Heart failure treatment management system . The heart failure treatment management system of claim 1, wherein the heart failure treatment optimization system is configured to update the treatment regimen at least daily. The heart failure treatment management system of claim 1 or 2, wherein the heart failure treatment optimization system is configured to automatically update the treatment regimen between physician inputs to maintain the patient in a stable region. The heart failure treatment management system of any one of claims 1 to 3, wherein the heart failure treatment optimization system is operably coupled to a remote system to receive relevant treatment data to train a risk score generator, a treatment regimen generator, or both to update the treatment regimen. The heart failure therapy management system of any one of claims 1 to 4, wherein the heart failure therapy optimization system includes an override mode for interrupting the therapy regimen, the heart failure therapy delivery system includes an override mode for interrupting delivery of therapy, or both. The heart failure treatment management system according to any one of claims 1 to 5, wherein the heart failure treatment optimization system includes a treatment regimen generator for providing the treatment regimen based on one or more risk scores. The heart failure treatment management system according to any one of claims 1 to 6, wherein the heart failure treatment optimization system includes a risk score generator for providing one or more risk scores based on patient data. The heart failure therapy management system of claim 6 or 7, wherein at least one of the heart failure therapy delivery system or the heart failure therapy optimization system is configured to collect patient data to support the one or more risk scores.
The heart failure therapy management system of claim 1 , wherein the non-implanted sensor of the sensor system comprises a patient-wearable sensor. The heart failure therapy management system of claim 1 , wherein the implantable sensor of the sensor system includes one or more electrical contacts. 11. The heart failure therapy management system of claim 10 , wherein the external sensor comprises at least one of an image sensor, a weight scale, a pressure sensor, or a microphone operably coupled to the circuitry of the external device. 12. The heart failure therapy management system of claim 1, wherein the heart failure therapy delivery system includes at least one of a drug dispenser containing one or more drugs, an automated therapy pump, a graphical user interface for providing therapy information to the patient, or an implantable electrical stimulation device. 13. The heart failure therapy management system of claim 1, wherein the heart failure therapy delivery system includes a processor that transmits, via a communications interface, a request for delivery of one or more medications from a remote location for on-site storage based on the treatment regimen.