Adaptive Treatment Management System

Abstract

The adaptive therapy management system includes a sensor system, a therapy optimization system, and a therapy delivery system. The therapy optimization system can update the therapy regimen multiple times between physician visits to facilitate therapy optimization. The therapy optimization system can determine the therapy regimen based on at least one of patient data, therapy compliance data, and related therapy data. The patient data can be provided by the sensor system. The therapy compliance data can be provided by the therapy delivery system. The related therapy data can be provided by a remote system.

Description

Technical Field

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

[0002] This technology generally relates to treatment. Specifically, this technology relates to the management of the treatment of heart failure or other chronic diseases.

[0003] As a specific example of a chronic disease, congestive heart failure (CHF) is a serious disease that occurs when the heart cannot pump blood steadily at an appropriate rate. To improve the heart's ability to pump blood efficiently, CHF patients may require an implantable medical device (IMD). IMDs such as implantable defibrillators (ICDs) and pacemakers can provide cardiac resynchronization therapy to improve the heart function of CHF patients. Despite using an IMD to improve heart function, CHF patients may gradually deteriorate, as evidenced by weight gain, shortness of breath, orthopnea, blood pressure changes, malaise, fatigue, peripheral edema (swelling in the lower limbs), fainting, and / or palpitations.

[0004] Patient data can be obtained in various ways. Typically, a patient directly conveys health data to a healthcare provider during a medical examination. Some data is automatically generated and can be transmitted to a computer system or a medical system via the Internet. For example, an electronic weighing scale is configured to measure a patient's weight and then automatically transmit that data to a medical system.

[0005] Depending on the data collected, the medical system can respond in various ways. Some medical systems can generate health warnings based on the data detected by the IMD. One exemplary medical system described in U.S. Patent Publication No. 2010 / 0030293 to Sarkar et al. generates a warning for the patient to seek treatment according to the detected information. The medical device can detect the deterioration of the patient's heart failure based on diagnostic parameters. When detecting the deterioration of heart failure, the medical device can, for example, provide a warning to enable the patient to receive a medical examination before experiencing a heart failure event. Many medical systems can automatically notify healthcare providers of potential health problems, but medical systems typically require physician input to adjust the therapy (e.g., medication) delivered to the patient.

SUMMARY OF THE INVENTION

[0006] The techniques of the present disclosure generally relate to an adaptive treatment management system. The system can administer different treatment regimens to maintain a patient in a constant and stable state even when the patient's risk of hospitalization is not high during the intervals between physician examinations for chronic diseases such as heart failure, chronic obstructive pulmonary disease (COPD), or renal dysfunction. The system can update the treatment regimen multiple times during the intervals between physician examinations to facilitate treatment optimization, thereby minimizing the patient's risk score, minimizing deviation from the treatment regimen prescribed by the physician, and minimizing the patient's symptoms.

[0007] In one aspect, the present disclosure provides a treatment management system including a sensor system for providing patient data related to a patient or the patient's environment. The treatment management system also includes a treatment delivery system for administering treatment based on a treatment regimen and for providing treatment compliance data. The treatment management system further includes a treatment optimization system operably coupled to the sensor system and the treatment delivery system, which updates the treatment regimen based on patient data from the sensor system and treatment compliance data from the treatment delivery system and provides the updated treatment regimen to the treatment delivery system.

[0008] In another aspect, the present disclosure provides a treatment optimization system including a data communication interface operably couplable to a sensor system configured to provide patient data and a treatment delivery system configured to administer treatment based on a treatment regimen. The treatment optimization system also includes a memory configured to store data representing 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, which is based on at least one score selected from one or more risk scores, one or more treatment scores, and one or more symptom scores, corresponding to administering a previous treatment based on a previous treatment regimen, determine a treatment regimen corresponding to the updated patient score and the previous treatment regimen, and provide this treatment regimen to the treatment delivery system.

[0009] In another aspect, the present disclosure provides a treatment optimization system including 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 a treatment regimen. The communication interface is configured to receive data representing a predetermined physician-restricted parameter region. The treatment optimization system also includes a memory configured to store data representing a predetermined physician-restricted parameter region, and a processor operably coupled to the data communication interface and the memory. The processor is configured to determine a patient score based on at least one of a risk score, a treatment score, or a symptom score using the patient data, determine a treatment regimen based on the patient score, determine whether the treatment regimen is within a predetermined physician-restricted parameter region, and in response to a determination that the treatment regimen is within the predetermined physician-restricted parameter region, provide the treatment regimen to the treatment delivery system to administer treatment based on the treatment regimen.

[0010] In yet another aspect, the present disclosure provides a treatment optimization system including 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 a treatment regimen. The communication interface is configured to receive a 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 there is one or more risk scores within a stability region representing patient stability 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 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.

[0011] In yet another aspect, the present disclosure provides a therapeutic delivery system that includes 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 to be loaded into respective receptacles. The therapeutic delivery system further includes a controller configured to detect each drug identifier of the one or more cartridges and transmit, via a data communication interface, a request to deliver a new cartridge associated with a particular drug identifier in response to an updated treatment regimen.

[0012] Details of one or more aspects of the present 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 be apparent from the specification, drawings, and claims.

Brief Description of the Drawings

[0013]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

DETAILED DESCRIPTION OF THE INVENTION

[0014] The technology of the present disclosure generally relates to an adaptive treatment management system. The system can administer different treatment regimens to maintain a patient in a constant and stable state even when the patient's risk of hospitalization is not high during and between physician consultations for chronic diseases such as heart failure, chronic obstructive pulmonary disease (COPD), or renal dysfunction. The system can update the treatment regimen multiple times between physician consultations to facilitate treatment optimization, thereby minimizing the patient's risk score, minimizing deviation from the treatment regimen prescribed by the physician, and minimizing the patient's symptoms.

[0015] This technology can provide dynamic treatment that manages the titration of the drug dose directed by a physician based on the patient's risk status, treatment adjustment for daily inattention, reduction of the total amount of diuretics taken by the patient, effectively obtain data from non-implanted or non-wearable information sources, promote patient compliance with the treatment regimen, reduce the complexity of the treatment regimen, detect compliance violations, enable efficient triage, collect data on treatment outcomes, and automatically schedule appointments for nurses and physicians.

[0016] As used herein, the term "or" is generally used in its inclusive sense and, for example, means "and / or" unless the context clearly dictates otherwise. The term "and / or" means one or all of the listed elements, or a combination of at least two of the listed elements.

[0017] When "at least one of" and "one or more of" follow items listed in conjunction with "and" or "or", they generally mean any one of the listed items and any combination of two or more of the listed items, unless the context clearly dictates otherwise.

[0018] Reference is now made to the drawings which illustrate one or more aspects described herein. 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 reference characters 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 reference elements cannot be the same or similar.

[0019] Figures 1 - 2 and 9 show a treatment management system and various components for managing the treatment of a patient. Figures 3 - 8 show various diagrams of techniques that can be used by or with the treatment management system. Figures 10 - 11 show various examples of managing treatment using the treatment management system of Figures 1 - 2 and 9 using one or more of the techniques shown in Figures 3 - 8.

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

[0021] The treatment management system 100 can update the treatment regimen based on the frequency of treatment. For example, the treatment regimen can prescribe the 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 highest frequency of administration, e.g., three times a day, or at any suitable frequency sufficient to keep the patient in a certain, stable, or certain and stable state. In some embodiments, the treatment can be adjusted or titrated when the treatment regimen is updated by the treatment management system 100. For example, a doctor can provide a prescription that can map a single dose of a drug and the type of drug to a risk score or other patient condition, and the treatment management system 100 can determine and provide the treatment regimen daily, every two days, every three days, weekly, or at any suitable time interval, based on this risk score or change in risk score.

[0022] The sensor system 150 can include one or more sensors for detecting various parameters related to the patient and the environment associated with this patient. The detected parameters can be used to provide patient data or other data. Various examples of components of the sensor system 150 include patient implantable sensors, patient wearable sensors, external sensors that the patient is not wearing, a graphical interface or audible user interface for receiving user input, or a memory for storing historical or past patient data.

[0023] As used herein, the term "patient data" generally refers to data regarding a patient or the environment associated with the 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. Various specific sensors, such as a liquid level sensor, a blood pressure sensor, etc., can be used to collect each type of patient data. Patient data can include patient outcome data such as whether the patient is hospitalized or other healthcare utilization information. Patient data can also include relevant information regarding the patient, such as other medical conditions or current treatments (e.g., diabetes, renal insufficiency, obesity, sleep apnea, dementia, Parkinson's disease, etc.).

[0024] Sensor system 150 can be operably coupled to treatment optimization system 160 to provide patient data to system 160. 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 patient-specific treatment. In particular, historical patient data can be used to determine the covariance 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 patient data, compliance data, and related treatment data.

[0025] Some patient data may be automatically provided to the treatment optimization system 160, 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 can request information from the sensor system 150, which can be described as previously received patient data or additional patient data used to supplement initial patient data. In particular, the treatment optimization system 160 can request information (e.g., "Do you feel short of breath?" or "Have you been to the hospital?") to confirm or verify information about the initial patient data. For example, patient data indicating hypertension or high blood pressure can be verified or confirmed using an ice scan from an imaging sensor. Additional patient data can be described as verification, confirmation, or adjacent patient data. Additional patient data can 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.

[0026] As used herein, "compliance data" or "treatment compliance data" generally refers to data related to a patient who is receiving a treatment that has been administered. Compliance data may be sufficient to determine whether a treatment has been administered to a patient or whether the patient has actually received the treatment. Various sensors and devices that can be used to detect, collect, or determine compliance data are described herein with respect to FIG. 2. 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.

[0027] Non-limiting examples of compliance data include, for example, medication compliance (e.g., whether a patient has taken the correct medication at the right escalating dose), nutritional compliance (e.g., restricting salt and water intake), physical activity compliance (e.g., exercise), and refraining from substance use (e.g., smoking). Compliance data can also include data for verifying the identity of the user (e.g., to facilitate identification of the user of a medication), or data such as face recognition data, voice recognition data, fingerprint data, verbal confirmation data, internal dosing sensor data, dispenser confirmation data (e.g., to verify what was dispensed for medication or nutrition), and motion sensor data (e.g., to verify exercise) for verifying that the user has actually adhered to the treatment regimen.

[0028] In the illustrated embodiment, the treatment optimization system 160 can be operably coupled to the treatment delivery system 170 to receive compliance data. The compliance data can be received, for example, at the same or similar frequency as used for updating the treatment regimen, or at the same or similar frequency as administering the treatment, or at any other suitable pace for managing the treatment in a constant or steady state.

[0029] As used herein, the term "associated treatment data" generally refers to data related to one or more medical conditions and treatments in a treatment regimen. Associated treatment data may include information about specific treatments used in other patients sharing the same or similar characteristics as the current patient. For example, a patient may be undergoing treatment for both heart failure and chronic obstructive pulmonary disease (COPD), and the associated treatment data may include or be based on information about treatments used in other patients undergoing the same treatment. Associated treatment data may be used by 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 treatment optimization system 160 based on associated treatment data that has little or no patient-specific patient data and includes large-scale population-level data about the same or similar medical conditions or treatments. The patient data can then be used to further update the treatment regimen.

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

[0031] Associated treatment data can 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 can be received periodically at a slower frequency during the generation of the first, or initial, treatment regimen and compared to the update of the treatment regimen or the implementation of treatment. In other embodiments, the associated treatment data can be received and used to update the treatment regimen in real time or at the same or similar frequency as the update of the treatment regimen or the implementation of treatment.

[0032] The treatment optimization system 160 can be operably coupled to the treatment delivery system 170 to provide a treatment regimen. The treatment delivery system 170 can use the treatment regimen to administer treatment to a patient.

[0033] As used herein, "administer treatment" refers to providing information (such as a notification) to a patient for receiving treatment, enabling a patient to utilize treatment (such as drug administration), or controlling a device or system to automatically provide treatment to a patient (such as a drug delivery pump or an oxygen machine for treating COPD). Examples of drug delivery pumps that can be used to automatically provide treatment to a patient include a diuretic pump or an insulin pump depending on the medical condition.

[0034] The treatment management system 100 can be described as a "closed-loop" treatment management system, for example, for the feedback provided between various systems 150, 160, 170, 180 of the system 100 as a whole. In one example, compliance data from the treatment delivery system 170 can be provided to the treatment optimization system 160 to confirm or verify the implementation of treatment to the patient. In another example, the sensor system 150 can be used to observe the effect of the administered treatment, for example, after treatment is administered using the treatment delivery system 170. Other forms of feedback are also contemplated in the use of the treatment management system 100.

[0035] FIG. 2 is a conceptual diagram showing an example of an environment that can be used with the treatment management system of FIG. 1. As shown, the environment 200 for use with the treatment management system 100 may include the body of the patient 50.

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

[0037] The treatment regimen may include one or more treatments (e.g., first dose, second dose, etc.). Generally, the adjustment of the patient's treatment regimen may depend on various factors such as one or more risk scores that may be determined based on patient data from one or more devices of the sensor system 150.

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

[0039] Using various types of patient-implantable sensors, they can be 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 having one or more electrical contacts (e.g., electrodes), biochemical sensors, motion sensors (e.g., 3-axis accelerometers), piezoelectric sensors, optical sensors, body temperature sensors, geographical 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 heart tissue or kidney tissue.

[0040] One or more patient-implantable sensors can be incorporated into or operably coupled to various implantable medical devices 202. Non-limiting examples of implantable medical devices 202 include leaded or leadless pacemakers, implantable cardioverter-defibrillators (ICDs), cardiac resynchronization devices without defibrillation function (CRT) or cardiac resynchronization devices with defibrillation function (CRT-D), leaded or leadless monitoring devices, or extracorporeal implantable cardioverter-defibrillators (EVICD).

[0041] Using various types of patient-wearable sensors, they can be 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 external electrical sensors having one or more electrical contacts (e.g., electrodes), biochemical sensors, motion sensors (e.g., 3-axis accelerometers), piezoelectric sensors, optical sensors, body temperature sensors, geographical location sensors (e.g., GPS sensors), or microphones.

[0042] One or more patient wearable sensors can be incorporated into or operably coupled to various patient wearable devices 204. Non-limiting examples of patient wearable devices 204 include heart rate monitors, smartwatches, perfusion sensors (e.g., pulse oximeters), patches for monitoring vital signs and activities, hearing aids with the function of detecting activities and vital signs (e.g., deep body temperature), or devices such as pendants for measuring activities.

[0043] Various types of external sensors can be operably coupled to the circuitry of an external device 206 for use in providing patient data. Non-limiting examples of external sensors include image sensors, weighing scales, pressure sensors, or microphones.

[0044] One or more external sensors can 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, treatment dispensers, weighing scales, blood pressure cuffs, bed sensors for measuring sleep metrics such as the number of times getting out of bed and restlessness, or furniture.

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

[0046] In another example, electrical sensors on the patient implantable device 202 or patient wearable device 204 can include electrical sensors used for monitoring electrical activity to provide, for example, electrocardiogram (ECG), impedance values, respiratory data, or body fluid levels.

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

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

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

[0050] Drug dispensers can be used in some treatment delivery systems 170. Some drug dispensers can 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., diuretics, antihypertensive drugs, etc.). The drug dispenser can be external, wearable, or implantable to administer the appropriate dosage of the drug according to the treatment regimen.

[0051] Some drug dispensers, such as the PILLO™ automatic tablet dispenser of Pillo, Inc. in Boston, MA, include two or more compartments and dispense the drug into a single container for patient use. Also, some drug dispensers release the drug directly into the body. These are described, for example, in U.S. Patent Nos. 7,001,359, 7,054,782, 7,008,413, 7,264,611, and 7,160,284 and are incorporated herein by reference. An example of an implantable drug dispenser is a subcutaneous drug dispenser (e.g., subcutaneous implantable devices such as drug delivery like the MiniMed® Paradigm® Revel® insulin pump of Medtronic, Inc. in Dublin, Ireland, or the SC2 injector of SC Pharmaceuticals, Inc. in Burlington, MA, or the OmniPod® insulin management system of Insulet Corporation in Acton, MA).

[0052] The drug dispenser can be configured to receive a treatment regimen via a communication signal through a data communication interface that can include a transceiver or transmitter. In some embodiments, the data communication interface can utilize a wireless communication protocol such as BLUETOOTH® technology.

[0053] In some embodiments, the drug dispenser may be configured to receive commands to adjust the dosage or type of drug to be administered. In some embodiments, the drug dispenser may be configured to send signals to another implantable medical device (such as a LINQ™ pacemaker) or an external device (such as a smartphone) to provide information (such as whether the drug level is depleted or very low).

[0054] The drug dispenser may be configured to receive instructions to dispense or otherwise administer drugs to facilitate a patient's reliable access to the correct drug and / or dosage. When the treatment optimization system 160 determines one or more drugs for a treatment regimen, the treatment optimization system 160 can automatically send a signal to the treatment delivery system 170 to administer the drug according to the updated treatment regimen. The treatment optimization system 160 can send a signal to the treatment 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.

[0055] The treatment delivery system 170 can automatically switch from a first dosing compartment to a second dosing compartment for drug delivery. The drug dispenser, or treatment delivery device, can rotate from a first dosing compartment that stores a first dosage to a second dosing compartment that stores a second dosage for delivery to the patient. The treatment delivery device may or may not automatically notify the patient that the treatment regimen has changed. The treatment delivery device can automatically notify the patient to take the drug during the day. The treatment or drug can be automatically administered to the patient in the appropriate dosage. The treatment delivery device may be set to automatically lock the drug delivery mechanism when the appropriate dosage has been delivered.

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

[0057] The treatment delivery system 170, which can control the amount of treatment administered to a patient, can provide robust feedback in the form of treatment compliance data. In some embodiments, the treatment delivery system 170 may not be able to control the amount of treatment administered, but may be able to provide treatment compliance data indicating whether the patient has at least accessed the treatment and, in some cases, received the treatment. For example, the treatment delivery system 170 may simply 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 each time the container is opened. Such a treatment delivery system 170 can be used, for example, when the patient is on vacation and the override mode is active, which is described herein with respect to FIG. 4.

[0058] Some treatment delivery systems 170 may include a graphical user interface or an audible user interface for providing treatment information to the patient, such as dosage or other treatment information. In one example, the graphical user interface or the audible user interface can recommend to the patient to avoid salt that day due to a high risk score.

[0059] One or more systems of the treatment management system 100 can 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 can include one or more controllers, sensors, or interfaces, each of which can include a processor 222 such as, for example, a central processing unit (CPU), a computer, a logic array, a processing circuit, or other device capable of sending data inside or outside the system. Each system can include circuitry used to couple various components of the controller together or to couple with other components operably coupled to the processor 222. The functions of the processor 222 can be implemented by hardware and / or as computer instructions on a non-transitory computer-readable storage medium.

[0060] The processor 222 can 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 can 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 individual or integrated logic circuitry. The functions 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 can utilize other components such as relays and timers, alone or in combination with a microprocessor-based system, to achieve the desired results.

[0061] In one or more embodiments, exemplary systems, methods, techniques, and other related functions may be implemented using one or more computer programs that may include one or more processors 222 and / or memory 224. To perform the functions described herein and generate the desired output data / information, the data communication interface 220 may be used to apply the program code and / or logic described herein to the input 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 the data communication interface 220. Considering the above, it will be readily apparent that the controller or processor functions described herein may be implemented in any manner known to those skilled in the art.

[0062] 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 some of the devices of the treatment management system 100 or between calling devices. However, the network 212 may also be used to transmit information to other external computing devices (e.g., the CARELINK® system commercially available from Medtronic).

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

[0064] Various systems of the treatment management system 100 may include one or more servers, computers, weighing scales, portable blood pressure monitors, biometric data collection devices, one computer, a symptom evaluation system, and portable information terminals (e.g., mobile phones, tablets, etc.). In some examples, the various devices of the treatment management system 100 can generate data for performing any of the various functions or operations described herein. For example, a heart failure risk status can be generated based on patient metrics comparison, or patient metrics can be created from raw metric data.

[0065] The risk status of heart failure (HF) can be calculated in several ways known to those skilled in the art having the advantages of the present disclosure. An example of calculating a risk score or risk status is described in U.S. Patent Publication No. 2019 / 0069851, filed on August 31, 2018, and U.S. Patent Publication No. 2019 / 0125273, filed on April 26, 2018, which are incorporated herein by reference.

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

[0067] One or more processors 222 of the treatment management system 100 may be configured to perform some kind of analog-to-digital conversion so that the signal can be compared with 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 of each evaluation period, etc. The evaluation period is obtained from each patient and functions as an evaluation window that includes data within the boundaries (e.g., start time and end time).

[0068] Examples of the various memories 224 of the treatment management system 100 may include volatile media, non-volatile media, magnetic media, optical media, 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 medium. Generally, 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, chest impedance, impedance trend, risk of hypervolemia or hypovolemia, etc. Also, the start time and end time or date of the evaluation period may be stored in the memory 224. In some cases, patient data may include data observations (e.g., data sensed from sensors that exceed a threshold).

[0069] The programmer 208 can include any suitable programming system, including those generally known to those skilled in the art, such as the Medtronic CARELINK (trademark) programmer of Medtronic.

[0070] The treatment optimization system 160 can send requests to devices of the sensor system 150, such as the patient implantable device 202, for example, via the programmer 208. 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), or diagnostic information based on a patient condition selected or already input in response to a request. The patient data can include the patient's metric values or other detailed information from the patient's implantable device 202.

[0071] The patient data can be used to provide warnings or notifications of heart failure risk levels by the treatment optimization system 160. When the risk level of heart failure becomes critical, a warning may be automatically sent or pushed. Additionally, the warning can be a notification of the risk level to a medical professional, such as a clinician or nurse, and / or instructions to the patient 50 to receive treatment (e.g., tests to confirm worsening of HF). In response to receiving the warning, the user interface can display the warning to the medical professional regarding the risk level or present instructions to the patient 50 to receive treatment.

[0072] In response to either heart failure data, such as a risk level or patient metric, or requested heart failure information, the user interface of the computing device or programmer 24 can present the user with patient metrics, heart failure risk levels, or recommended treatments (e.g., dosing). Also, in some examples, the user interface can highlight patient metrics that exceed the threshold specific to each metric. In this way, the user can quickly identify the patient metrics contributing to the identified heart failure risk level.

[0073] The access point 210 can 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 can be coupled to the network 112 via different forms of connections, including wired or wireless connections. In some examples, the access point 210 may be located in the same location as the patient 50 and may comprise one or more programming units and / or computing devices (e.g., one or more monitoring units) capable of performing the various functions and operations described herein.

[0074] In another example, the access point 210 can be a LINQ (trademark) device located in the same location within the patient, configured to sense, record, and transmit data to the network 112. Alternatively, a wearable patch such as a SEEQ (trademark) device configured for monitoring may be attached to the patient's skin. For example, the SEEQ (trademark) device can be attached to the skin over the patient's heart for heart monitoring. In another example, the access point 210 can include a home monitoring unit located within the patient 50 and capable of monitoring the activity of the IMD 16. Commercially available LINQ (trademark) and SEEQ (trademark) devices from Medtronic can also be used as the access point 210. Non-limiting examples of the LINQ (trademark) device are described with respect to U.S. Patent Publication No. 2016 / 0310031, filed on April 20, 2016, which is incorporated herein by reference.

[0075] The treatment 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 (e.g., decompensated HF patients with low blood pressure vs. normal blood pressure) across a spectrum of episode severity. The treatment optimization system 160 may be configured to perform complex calculations on large patient populations and may provide a secure storage area in memory for archiving information (e.g., patient metric data, heart failure risk levels, weight, blood pressure, etc.) collected and generated from the sensor system 150 and the treatment delivery system 170.

[0076] FIG. 3 is a flowchart illustrating an example of a method of using the treatment management system of FIG. 1. As shown, method 300 may include determining patient data 302. The patient data may be provided by a sensor system that 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 confirm a risk score.

[0077] A risk score may be used to determine a patient's score. Method 300 may include optimizing treatment 304 using the patient score. A treatment regimen reflecting the optimized treatment may be generated or determined. Generally, treatment optimization minimizes a patient's score, which typically corresponds to risk, treatment differences, and symptom reduction.

[0078] Method 300 may include administering treatment 306, for example, based on the generated optimal treatment regimen. Administering treatment may include providing a predetermined dosage to a patient who is receiving treatment voluntarily, or providing automated delivery of treatment (e.g., automated treatment pump or oxygen machine settings into a patient's body).

[0079] Additionally, method 300 may include, for example, determining treatment compliance data 308 in response to administering treatment. The treatment compliance data may provide some indication of whether the patient has adhered to the administered treatment. For example, a camera located on or near a drug dispenser can identify a patient taking the dispensed medication, which can provide at least some verification of the patient's compliance with the treatment regimen.

[0080] Furthermore, method 300 can loop back, via an iterative loop or a closed loop, to determining patient data 302, optimizing treatment using the patient score 304, and administering treatment 306. The treatment compliance data can be used to optimize the treatment or update the treatment regimen. For example, the treatment compliance data can indicate whether the patient actually received the previously administered treatment regimen, which can be used to determine the appropriate treatment regimen to administer next. In particular, the patient score can be updated based on the treatment compliance data. For example, the risk score can vary based on treatment compliance data as described herein with respect to FIG. 4.

[0081] FIG. 4 is a state diagram showing an example of a method of implementing the optimization treatment method of FIG. 3 using a plurality of generators. In particular, FIG. 3 shows the use of two generators. As shown, method 320 may include a state 322 of delivering treatment and collecting data. The data collected may include, for example, patient data, treatment compliance data, and related treatment data.

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

[0083] The "risk" score refers to a measure that may indicate a decline in a patient's health. Non-limiting examples of a decline in a patient's health include an increased risk of hospitalization, an increased risk of death, or other signs of a general decline in health.

[0084] Generally, one or more risk scores can be determined using patient data. For example, if a patient's blood pressure increases, the risk score associated with hypertension (and the overall risk score) may also increase. The current treatment regimen may be used to adjust a particular risk score. For example, if a patient is being treated for hypertension by administration of the maximum allowable level of an ACE inhibitor, the risk score associated with hypertension may further increase. In another example, even if the patient's blood pressure has not changed from a high level after administration of the maximum allowable level of an ACE inhibitor, the risk score associated with hypertension may still increase.

[0085] Method 320 may also include a state 326 of treatment regimen generation by a treatment regimen generator. A treatment regimen generator can be used to determine a treatment regimen based on, for example, one or more risk scores provided by a risk score generator. As described herein, the treatment regimen generated can be within the range of treatment regimens prescribed by a physician. The treatment regimen generator can also determine a treatment regimen based on other data and scores such as treatment scores or symptom scores. The treatment regimen generator can be stored in the 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. Generally, the risk score generator and the treatment regimen generator are separate and differ in that each has different inputs and different outputs from the other.

[0086] Generally, a treatment regimen generator can generate a treatment regimen based on a comprehensive patient score, which can be a combination of one or more scores. The treatment regimen generator can provide a new treatment regimen to reduce or minimize the comprehensive patient score. Generally, as used herein, a low comprehensive patient score is defined as corresponding to a better patient condition than a high comprehensive patient score. However, in some embodiments, a high overall patient score can be defined as corresponding to a better patient condition than a lower overall patient score.

[0087] The treatment regimen can also be generated based on information regarding one or more past treatment regimens. Past treatment regimen data can be used to update the patient score. For example, if a past treatment regimen for lowering blood pressure did not lower 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 another treatment for hypertension.

[0088] Generally, a treatment regimen generator can update the patient score in response to the implementation of previous treatment based on the previous treatment regimen, determine the treatment regimen according to the updated patient score and the previous treatment regimen, and provide the treatment regimen to a treatment delivery system.

[0089] 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 treatment delivery, data collection, risk score generation, and treatment regimen update.

[0090] In some embodiments, 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 the administration of treatment can be interrupted in some way. For example, the override mode can indicate that the treatment regimen should not be updated for a certain period of time, or that the treatment should not be administered for a certain period of time.

[0091] Various trigger 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, the physician's input may be a trigger to enter the override mode, such as when the patient is at a clinic or hospital and the physician is administering treatment. The administration of treatment and the generation of an updated treatment regimen may be interrupted during the override mode. When the patient is ready to leave, the physician's input may trigger the end of the override mode (e.g., disable, turn off, etc.).

[0092] In some embodiments, the patient's input may trigger or initiate entering the override mode, such as when the patient is planning to be away from the home treatment delivery system for vacation or other travel. The administration of treatment by the home treatment delivery system and the generation of an updated treatment regimen may be interrupted, for example, because the dosage cannot be easily changed or access to different treatments is not available while the patient is away from the home treatment delivery system. The end of the override mode may be triggered by the patient's input when the patient returns to the home treatment delivery system.

[0093] In some cases, the treatment delivery system may be portable. The portable treatment delivery system may provide some or all of the same functions as the home treatment delivery system. In other words, the portable treatment delivery system may be able to administer different treatments to the patient, at least to some extent, based on an updated treatment regimen. For example, the portable treatment delivery system may contain the same drug in a limited number of different dosages or a limited number of different drugs. The patient may be notified by a smartphone, which may be considered part of the portable treatment delivery system, to take a certain amount of medication from the portable treatment delivery system. Generally, the portable treatment delivery system may enable the treatment management system to avoid or end the override mode, either partially or entirely.

[0094] Using the proximity sensor or other location-based sensors of the treatment management system, environmental data can also be generated to enter the override mode or trigger the end of the override mode, for example, instead of requiring manual physician input or manual patient input. In addition, data from other sources, such as the GPS location from the patient's phone, can be used to enter the override mode or trigger the end of the override mode.

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

[0096] In some embodiments, the risk score generator or treatment regimen generator can be updated based on the relevant treatment data. For example, other patients receiving the same or similar treatment 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 the 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.

[0097] FIG. 5 is a flowchart showing an example of a method for determining a patient score that can be used in the method of FIG. 3. As shown, using method 340, the determination or update 350 of the patient score can be performed in response to the collection 342 of data. The optimization of the patient score and other scores is generally described from the perspective of minimization, but the optimization of the patient score using a maximum value or a target value is also contemplated in any suitable method available to those skilled in the art having the advantages of the present disclosure.

[0098] Based on the various types of data collected, a determination 344 of one or more risk scores can be made, where each risk score represents a different parameter or metric of risk. One or more of the risk scores can be based on patient data, which may include validated patient data. In some embodiments, the risk scores can be related to a potential heart failure risk.

[0099] A risk score can represent an input parameter or a combination of input parameters. A composite risk score can represent some or all of the input parameters. Non-limiting examples of risk scores, or input parameters to risk scores, include the OPTIVOL™ score (e.g., impedance or impedance index representing fluid levels), nocturnal heart rate (NHR) score (e.g., nocturnal ventricular rate), patient activity score, heart rate variability (HRV) score, arrhythmia score (e.g., atrial tachycardia or atrial fibrillation score), ventricular rate score (e.g., average heart rate during arrhythmia), pacing score (e.g., percent CRT ventricular pacing), shock score (e.g., number of shocks), respiration, tissue perfusion, body temperature, treated arrhythmia score, COPD risk, stroke risk, renal failure risk, VT / VF risk, acute decompensation risk, hyperkalemia or hypokalemia risk, hyperglycemia or hypoglycemia risk, or sleep apnea risk.

[0100] Various diagnostic metrics or metrics that can be used to determine risk scores can be extracted from patient data. Non-limiting examples of patient data include (1) impedance trend index commercially available from Medtronic in an IMD, (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 rates, (8) percent CRT pacing, or (9) number of shocks.

[0101] Some examples of medium and high risk calculations performed by a treatment optimization system are described in U.S. Patent Publication No. 2016 / 0361026, filed Mar. 29, 2011, U.S. Patent Publication No. 2012 / 032243, filed Oct. 28, 2010, U.S. Patent Publication No. 2019 / 0069851, filed Aug. 31, 2018, and U.S. Patent Publication No. 2019 / 0125273, filed Apr. 26, 2018, which are incorporated herein by reference.

[0102] For example, the medium risk state may include one or more conditions such as an AT / AF load exceeding a threshold (>6 hours / day), low %V pacing, and a high nocturnal heart rate (>85 bpm). For example, the high risk state may include one or more conditions such as a high OPTIVOL™ / impedance index (>60 ohm-days), patient activity (<1 hour / day), a high nocturnal heart rate (>85 bpm), and a low HRV (<60 ms).

[0103] The impedance index may be an indicator 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 reference impedance that can be continuously updated and established by the patient implantable device or during a physician's examination. Non-limiting examples of determining and using the impedance index are described in U.S. Patent No. 7,986,994, issued Jul. 26, 2011, which is incorporated herein by reference.

[0104] Heart rate variability (HRV) can be a marker of autonomic nervous tension and can provide prognostic information on the risk of death. A decrease in HRV is associated with an increase in sympathetic nervous tension or an increase in the risk score. Using diagnostic data from an HRV device, patients with a low HRV (<100 ms) may have a higher combined risk of death and hospitalization. Patients with an HRV of less than 50 ms may exhibit an even higher risk than patients with an HRV in the range of 50-100 ms.

[0105] Similar to HRV, an increase in heart rate can be a marker of increased sympathetic nervous tension, and it has been shown that there is a prognostic value for the deterioration of HF or a higher risk score. The nocturnal heart rate (NHR) measured between midnight and 4 am may be a better indicator than the heart rate during the day. The heart rate during the day may be affected by various activity levels (e.g., rest or exercise). Patients with a high NHR (75 ± 25 bpm) typically have a higher risk of hospitalization or death than patients with a low NHR (73 ± 11 bpm).

[0106] Furthermore, since a decrease in patient activity is associated with a worsening of the HF state, it may be useful for predicting HF hospitalization, which may correspond to a higher risk score. A decrease in patient activity can be determined by various activity devices such as FITBIT (registered trademark) devices, mobile phones, and smartphones.

[0107] It is also possible to evaluate the deteriorating HF risk or a higher risk score by using combined variables (e.g., combining pacing and arrhythmia-related information). For example, there is a significant decrease (>8%) in CRT pacing as one of the components of the combined variable, which is associated with high HF events. A decrease in CRT pacing may occur due to rapid conduction during AF. Therefore, an average ventricular rate ≥90 bpm and an atrial fibrillation (AF) burden ≥6 hours / day, and shocks delivered to ventricular fibrillation / ventricular tachycardia (VT / VF) can also be components of the combined variable.

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

[0109] Based on the collected data related to different treatments respectively, the determination 346 of one or more treatment scores can be performed. In particular, the treatment score can be determined based on the difference between the physician-based treatment regimen and the current treatment regimen being administered to the patient.

[0110] In some embodiments, the treatment regimen may include a plurality of different treatments. Non-limiting examples of treatments 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 the case of COPD), steroids (e.g., in the case of COPD), physical activity (e.g., exercise), dietary recommendations, nutritional supplements, sugar pills, oral insulin, medications for Parkinson's / tremors, or anticoagulants.

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

[0112] Based on the collected data representing the symptoms of one or more patients, determination 348 of one or more symptom scores can be performed. Generally, the symptom score can indicate other symptoms of the patient that are 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, even if the patient's risk score is low, there may be side effects due to treatment and the symptom score may be high. An example of a side effect is that the patient may develop a cough from a beta blocker. The symptom score may be based on sensor data or patient data from patient input. For example, the patient can input a feeling of pain into the user interface of a smartphone and use this to generate a symptom score. Accordingly, the treatment management system may reduce or otherwise change one or more treatments to reduce the patient's symptoms, whereby the patient's score can be minimized.

[0113] The overall patient score can be determined or updated 350 based on at least one of the score factors that may include one or more risk scores, treatment scores, and symptom scores. Calculating and combining one or more score factors in any suitable way can facilitate the patient's risk, treatment differences or deviations, and minimization of the patient's symptoms when generating a treatment regimen.

[0114] One or more of the calculated risk scores can be weighted. The 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 may be an increasing monotonic non - linear function.

[0115] The weight function can be continuous and can include inflection points related to thresholds or pseudo-thresholds. For example, when 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 the same or a similar threshold or pseudo-threshold. Each risk may include different inflection points or pseudo-thresholds, or an entirely different risk profile.

[0116] Various functions can also be applied to treatment deviations to provide treatment scores, or to symptom data to provide symptom scores. The weight function can also be applied to one or more treatment scores or symptom scores.

[0117] A sum can be used to combine multiple scores. For example, the sum of multiple weighted risk scores can be used to combine multiple risk scores.

[0118] 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 generally adjust the score coefficients such that minimization (or maximization) of the patient score generally balances minimization of risk factors, treatment deviations, and the patient's symptoms. In one example, the scores can be summed.

[0119] Figure 6 is a flowchart showing an example of implementing the optimization treatment method of Figure 3 using the risk score backing. As shown, method 360 can include collecting data 362 such as patient data, treatment compliance data, and related treatment data.

[0120] Method 360 can also include determining 364 whether the risk score has changed, for example, based on the collected data. The risk score may change based on the previous treatment provided, or may remain the same.

[0121] Furthermore, 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 questions) or perform an action by the patient to collect additional data (e.g., step on a scale).

[0122] Method 360 may include, for example, corroborating a risk score using patient data such as patient input 368 in response to a determination 366 that patient input is required. In one example, the patient data may indicate a high risk score associated with blood pressure, and the patient may be requested to stand in front of a camera to record an image of the patient's eyes. The image of the patient's eyes can be used to confirm or corroborate the presence of a high risk score associated with blood pressure, which may represent out-of-range blood pressure.

[0123] Method 360 may include, for example, updating or determining 370 a patient score in response to corroborating the risk score 368 or in response to determining 366 that no further patient input is required. The patient score can be used to evaluate the overall condition of the patient.

[0124] In addition, method 360 may include, for example, determining 372 whether the patient is stable after treatment according to the current treatment regimen. The stability of the patient can be determined by comparing the 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 region or an unstable region. In particular, the patient can be determined to be stable or unstable based on whether one or more risk scores exceed a particular threshold that defines the boundary between the stable region and the unstable region.

[0125] The stability threshold may correspond to the magnitude value of the score threshold, the rate of change of the score threshold, 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.

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

[0127] In some embodiments, the threshold can be based on the continuous functions used to generate one or more scores and the functions used to combine them with the patient scores. Thus, the threshold may be fixed or may be determined based on relative values to other scores.

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

[0129] In addition, method 360 may include, for example, providing 378 the treatment regimen determined to administer treatment after determining the treatment regimen in 374 or 376. The treatment regimen may be provided to a treatment delivery system for administration.

[0130] Furthermore, method 360 may include verifying compliance with the treatment administered 380. For example, in order to identify the patient, an image of the user's face may be recorded when the drug is dispensed from the drug dispenser. Such compliance data may be used by method 360, for example, for updating the patient score 370.

[0131] In some embodiments, the patient may be unstable 372, and the patient score may indicate that physician input is required instead of management by the treatment 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 examined by a nurse or physician in a hospital, emergency department, ambulance, observation unit, intensive care, or HF / heart disease clinic. In such cases, the treatment management system can automatically notify not only the patient but also the nurse or physician and enter an override mode to stop the administration of the treatment.

[0132] Figures 7-8 show the use of a physician-restricted treatment area for managing a patient's treatment. FIG. 7 is a flowchart showing an example of implementing the optimization treatment method of FIG. 3 by integrating physician input. FIG. 8 is a conceptual diagram showing an example of a physician restriction parameter area that can be used in the method of FIG. 7.

[0133] As shown, method 400 may include receiving a physician restriction parameter region 402 for a given patient. The physician restriction parameter region 402 may vary depending on different patients, different health states (e.g., HF class, NYHA II vs. NYHA III, etc.), and different treatments (e.g., specific agents or drugs). The physician restriction parameter region can be based on the physician's input and, for example, indicates the allowable range of parameters that can be used by the treatment management system to treat the patient without further input from the physician during the physician's examination and between examinations. The physician restriction parameter region can be stored in the memory of the treatment management system and can be described as a parameter region restricted or guided by a given physician.

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

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

[0136] When the treatment regimen is updated or determined, method 400 may include determining 402 whether the treatment regimen is within the physician restriction parameter region.

[0137] This determination can be based on a comparison of the treatment regimen for one or more treatments with the physician restriction parameter region. In some embodiments, the 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 with the physician restriction parameter region. For example, the physician restriction parameter region may include restrictions on various scores, or scores related to the treatment regimen restricted by the physician can be calculated for comparison.

[0138] Method 400 may include, for example, providing a treatment regimen to a treatment delivery system to administer treatment 410 in response to a determination 408 that the treatment regimen is within a physician - restricted parameter region. After administering the treatment, method 400 can return to updating the patient score 404. The physician - restricted parameter region can be received or updated again 402 each time the patient has a doctor's appointment.

[0139] Furthermore, method 400 may include initiating a process 412 to contact a physician in response to a determination 408 that, for example, the treatment regimen is outside the physician - restricted parameter region (e.g., within a physician - assisted region). For example, a treatment regimen outside the physician - restricted parameter region may indicate that the treatment management system cannot provide effective treatment for one or more risks or symptoms based on the treatments available in the physician - restricted parameter region. Method 400 can return to receiving the updated physician - restricted parameter region 402.

[0140] An example of the physician - restricted treatment region is shown in plot 420, which shows a physician - restricted region 422 and a physician - assisted region 424. The physician - restricted region 422 can also be described as a threshold region. The boundary 426 between the physician - restricted region 422 and the physician - assisted region 424 can also be described as a threshold.

[0141] The physician - restricted region 422 can define one or more parameters for treatments within which the treatment management system can operate. Non - limiting examples of parameters that can be defined by the physician - restricted region 422 include treatment dosage, dosing frequency, or cumulative treatment dosage over time.

[0142] In some embodiments, the physician - restricted region 422 can take the shape of a triangle or other geometric shape when shown, for example, in a graph of time versus dosage. As shown, the triangular shape can indicate that lower dosages can be administered over a wider range of time compared to higher dosages that are allowed to be administered only for a short period.

[0143] Figure 9 is a conceptual diagram showing an example of a treatment delivery system that can be used with the treatment management system of FIG. 1. As shown, FIG. 9 shows a treatment 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 a plurality of cartridges. In general, the drug dispenser 500 is configured to hold two or more cartridges 508.

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

[0145] In some embodiments, each cartridge 508 contains a different drug or a different dose of a drug. The drug dispenser 500 may be able to administer a particular drug from a particular cartridge 508 as indicated by the current treatment regimen by tracking the drug identifier 510. In other words, the cartridges 508 can be inserted into the drug dispenser 500 in any position or order, but the drug dispenser can still distinguish the position of each cartridge. The administered drug may be poured into a single cup or other container 512 for use by the patient to take the administered drug.

[0146] In addition, the communication interface 504 can be configured to send requests to deliver one or more new cartridges 508. For example, the communication interface 504 can provide, via the Internet, instructions to initiate delivery of a specific cartridge 508 from a remote location to the patient's home for the patient to keep on hand. The patient or delivery service can insert the cartridge into the receptacle 506 of the drug dispenser 500. When each cartridge 508 is used, a new cartridge can be ordered, which may contain the same drug or a single dose of the drug as the empty cartridge, or a different drug or a single dose of the drug, depending on the requirements of the current treatment regimen.

[0147] 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 only be accessible to the drug dispenser 500.

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

[0149] The communication interface 504 can be configured to detect the drug identifier 510 before, during, or after loading of each cartridge 508. For example, in some embodiments where the cartridge 508 is emptied to load a receptacle, the drug identifier 510 can be detected before or simultaneously with the cartridge 508 being attached to the drug dispenser 500.

[0150] Figure 10 is a conceptual diagram showing an example of managing a patient's treatment using the method of Figure 3. As shown, the plot 600 shows how different treatment regimens are being applied based on changes in a body fluid level risk score (e.g., an impedance risk score). In the plot 600, time is plotted on the x-axis and dosage or body fluid level is plotted on the y-axis. In the example shown, the treatment management system adjusts the treatment to maintain the patient in a constant and stable region even when the body fluid level risk score is in the stable region based on magnitude but not based on the rate of change (e.g., below the OptiVol (trademark) high threshold such as 60 ohm-days but changing rapidly). For example, when the body fluid level increases at time 2, the treatment management system increases the loop diuretic and electrolyte at time 2. When the body fluid level decreases at time 3, the loop diuretic and electrolyte decrease at time 4. When the body fluid level increases again at time 5, the diuretic and electrolyte also increase again at time 5. Other drugs such as ACE inhibitors and beta blockers may not change depending on the risk factors.

[0151] Figure 11 is a conceptual diagram showing another example of managing a patient's treatment using the method of Figure 3. As shown, the plot 650 shows the diuretic treatment level, the renal insufficiency risk score, the dietary sodium intake level, and the HF hospitalization risk score. In the plot 650, time is plotted on the x-axis and dosage or risk is plotted on the y-axis. The treatment management system can administer a treatment that balances various risks such as body fluid level and electrolyte level (e.g., sodium).

[0152] As shown, the acute heart failure (AHF) risk score rises sharply at time 2, for example, due to an increase in impedance from body fluids. The treatment management system increases the dosages of diuretics and electrolytes at time 2 in proportion to the increased risk of AHF. To keep the risk score of renal insufficiency low, the treatment management system increases the dosage of diuretics for only a short period of time. As shown, when the AHF risk score drops at time 3, the dosage of diuretics returns to a low level at time 4 to maintain a low renal risk score. This balance of risk scores and dosages can not only keep both the AHF risk score and the renal risk score low, but also keep the patient's dosage as low as possible.

[0153] Exemplary embodiments The present disclosure, without limitation, the understanding of the various aspects of the disclosure will be obtained through consideration of the specific exemplary embodiments provided below. Various modifications of the exemplary embodiments, as well as additional embodiments of the present disclosure, will become apparent herein.

[0154] In Embodiment A1, the treatment management system includes a sensor system for providing patient data related to the patient or the patient's environment. The treatment management system also includes a treatment delivery system for administering treatment based on a treatment regimen and for providing treatment compliance data. The treatment management system further includes a treatment optimization system operably coupled to the sensor system and the treatment delivery system, which updates the treatment regimen based on patient data from the sensor system and treatment compliance data from the treatment delivery system, and provides the updated treatment regimen to the treatment delivery system.

[0155] In Embodiment A2, the system includes a system according to any A embodiment, and the treatment optimization system is configured to update the treatment regimen at least daily.

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

[0157] In Embodiment A4, the system includes a system according to any A embodiment, and the treatment optimization system is operably coupled to a remote system and receives associated treatment data to train one or both of a risk score generator, a treatment regimen generator to update the treatment regimen.

[0158] In Embodiment A5, the system includes a system according to any A embodiment, and the treatment optimization system includes an override mode for interrupting the treatment regimen, or the treatment delivery system includes an override mode for interrupting the administration of treatment.

[0159] 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.

[0160] In Embodiment A7, the system includes a system according to any A embodiment, and the treatment optimization system is operably coupled to the treatment delivery system via the Internet or integrated into a single unit with the treatment delivery system.

[0161] In Embodiment A8, the system includes a system according to any A embodiment, and the treatment optimization system comprises a treatment regimen generator for providing a treatment regimen based on one or more risk scores.

[0162] In Embodiment A9, the system includes a system according to any A embodiment, and the treatment optimization system comprises a risk score generator for providing one or more risk scores based on patient data.

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

[0164] In Embodiment A11, the system includes a system according to any A embodiment, 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.

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

[0166] In Embodiment A13, the system includes the system according to Embodiment A12, and the patient-implanted sensor includes at least one of an implanted electrical sensor, a biochemical sensor, a motion sensor, a piezoelectric sensor, an optical sensor, a body temperature sensor, a geographical location sensor, or a microphone, which is operably coupled to the circuit of the implanted medical device and includes one or more electrical contacts.

[0167] In Embodiment A14, the system includes the system according to Embodiment A12 or A13, and the patient-wearable sensor includes at least one of an external electrical sensor, a biochemical sensor, a motion sensor, a piezoelectric sensor, an optical sensor, a body temperature sensor, a geographical location sensor, or a microphone, which includes one or more electrical contacts.

[0168] In Embodiment A15, the system includes the system according to any of Embodiments A12 to A14, and the external sensor includes at least one of an image sensor, a weighing scale, a pressure sensor, or a microphone, which is operably coupled to the circuit of the external device.

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

[0170] In Embodiment A17, the system includes a system according to any A embodiment, and the treatment delivery system includes a processor that transmits, via a communication interface, a request to deliver one or more drugs for storage on hand from a remote location based on a treatment regimen.

[0171] 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 treatment based on a treatment regimen. The treatment optimization system also includes a memory configured to store data representing 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 corresponding to administering previous treatment based on a previous treatment regimen, determine a treatment regimen corresponding to the updated patient score and the previous treatment regimen, and provide this treatment regimen to the treatment delivery system.

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

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

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

[0175] In Embodiment B5, the system includes a system according to any B embodiment, and the processor is further configured to update a patient score based on one or more monotonic functions, non - linear functions, or monotonic and non - linear functions applied to one or more risk scores.

[0176] In Embodiment B6, the system includes a system according to any B embodiment, and the treatment regimen includes the administration of a plurality of different treatments.

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

[0178] In Embodiment C1, the treatment optimization system includes a data communication interface that is operably coupled to a sensor system configured to provide patient data and a treatment delivery system configured to administer treatment based on a treatment regimen. The communication interface is configured to receive data representing a predetermined physician-restricted parameter region. The treatment optimization system also includes a memory configured to store data representing a predetermined physician-restricted parameter region, and a processor operably coupled to the data communication interface and the memory. The processor is configured to determine a patient score based on at least one of a risk score, a treatment score, or a symptom score using the patient data, determine a treatment regimen based on the patient score, determine whether the treatment regimen is within a predetermined physician-restricted parameter region, and in response to a determination that the treatment regimen is within the predetermined physician-restricted parameter region, provide the treatment regimen to the treatment delivery system to administer treatment based on the treatment regimen.

[0179] In Embodiment C2, the system includes the system according to any C embodiment, and the processor is further configured to initiate a physician communication process in response to a determination that the treatment regimen is outside a predetermined physician-restricted parameter region.

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

[0181] In Embodiment C4, the system includes the system according to any C embodiment, and the predetermined physician-restricted parameter region is based on at least one of a treatment dosage, a dosing frequency, or a cumulative treatment dosage over time.

[0182] In Embodiment D1, the treatment optimization system includes a data communication interface operably connectable to a sensor system configured to provide patient data and a treatment delivery system configured to administer treatment based on a treatment regimen. The communication interface is configured to receive a 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 there is one or more risk scores within a stability region representing patient stability after administering treatment according to the current treatment regimen, determine a treatment score based on the difference between the current treatment regimen and the physician-based treatment regimen according to one or more risk scores 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.

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

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

[0185] In Embodiment D4, the system includes a system according to any D embodiment, 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.

[0186] In Embodiment E1, the present disclosure includes a therapeutic delivery system that includes 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 to be loaded into respective receptacles. The therapeutic delivery system further includes a controller configured to detect each drug identifier of the one or more cartridges and transmit, via a data communication interface, a request to deliver a new cartridge associated with a particular drug identifier in accordance with an updated treatment regimen.

[0187] In Embodiment E2, the system includes a system according to any E embodiment, and the controller is further configured to deliver requests to a remote delivery system via the Internet using the data communication interface.

[0188] In Embodiment E3, the system includes a system according to any E embodiment, and further includes a data communication interface 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 in any of the receptacles.

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

[0190] 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.

[0191] As such, various embodiments of the adaptive treatment management system are disclosed. The various aspects disclosed herein may be combined in combinations different from those specifically presented in the description and the accompanying drawings. Any particular acts or events of the processes or methods described herein may be performed in a different order depending on the example, and may be added, combined, or completely omitted (e.g., all described acts or events may not be necessary to practice the technique). It should also be understood that while particular aspects of the disclosure may be described as being performed by a single module or unit for clarity, the techniques of the disclosure may be performed, for example, by a combination of units or modules associated with a medical device.

[0192] In one or more embodiments, the techniques described can be implemented in hardware, software, firmware, or any combination thereof. When 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 a non-transitory computer-readable medium corresponding to a tangible medium such as a data storage medium (e.g., RAM, ROM, EEPROM, flash memory, or any other medium that can be used to store the desired program code in the form of instructions or data structures and that can be accessed by a computer).

[0193] The instructions can 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 can refer to any of the foregoing structures or any other physical structure suitable for implementation of the techniques described. Also, the techniques may be implemented entirely in one or more circuits or logic elements.

[0194] All references and publications cited in this specification are hereby expressly incorporated by reference in their entirety for all purposes, except where any aspect directly conflicts with the present disclosure.

[0195] All scientific and technical terms used in this specification have the meanings commonly used in the art, unless otherwise defined. The definitions provided herein are for the purpose of facilitating the understanding of specific terms frequently used herein and are not meant to limit the scope of the present disclosure.

[0196] The terms "coupled" or "connected" refer to elements attached to each other either directly (in direct contact with each other) or indirectly (having one or more elements attaching the two elements between 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 such that the components interact to achieve functionality.

[0197] As used herein, the term "configured" may be used interchangeably with the terms "adapted" or "structured", unless the context of the present disclosure clearly indicates otherwise.

[0198] The singular forms "a", "an", and "the" include embodiments having a plurality of referents, unless the context clearly dictates otherwise.

[0199] As used herein, terms such as "have", "having", "include", "including", "comprise", "comprising", etc. are used in their unrestricted sense and generally mean "including but not limited to". It will be understood that "consisting essentially of", "consisting of", etc. are included in "including", etc.

[0200] References to "one embodiment", "an embodiment", "a particular embodiment", or "some embodiments", etc. 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 appearance of such expressions in various places throughout this specification is not necessarily referring to the same embodiment of the disclosure. Further, the particular features, configurations, compositions, or characteristics may be combined in any suitable manner in one or more embodiments.

Claims

**Claim 1** A heart failure treatment management system, a sensor system for providing patient data regarding a patient or an environment related to the patient using a non-implanted sensor and an implanted sensor, a heart failure treatment delivery system for performing treatment based on a treatment regimen and providing treatment compliance data, a heart failure treatment optimization system operably coupled to the sensor system and the heart failure treatment delivery system, for updating a heart failure treatment regimen based on the patient data from the sensor system and the treatment compliance data from the heart failure treatment delivery system, and providing the updated heart failure treatment regimen to the heart failure treatment delivery system, in a heart failure treatment management system, comprising: wherein the heart failure treatment optimization system has a risk score indicating a decline in the patient's health, a treatment score indicating a difference between a physician-based treatment regimen and the current treatment regimen being administered to the patient, and is provided with a treatment regimen generator for providing the treatment regimen based on a patient score determined based on at least one score selected from a symptom score indicating symptoms of the patient not included in the patient data. A heart failure treatment management system. **Claim 2** The heart failure treatment management system according to claim 1, wherein the heart failure treatment optimization system is configured to update the treatment regimen at least daily. **Claim 3** The heart failure treatment management system according to 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. **Claim 4** The heart failure treatment management system according to any one of claims 1 to 3, wherein the heart failure treatment optimization system is operably coupled to a remote system, receives relevant treatment data, and trains a risk score generator, a treatment regimen generator, or both to update the treatment regimen. **Claim 5** The heart failure treatment management system according to any one of claims 1 to 4, wherein the heart failure treatment optimization system includes an override mode for interrupting the treatment regimen, or the heart failure treatment delivery system includes an override mode for interrupting treatment, or both. **Claim 6** The heart failure treatment management system according to any one of claims 1 to 5, wherein the heart failure treatment optimization system comprises a treatment regimen generator for providing the treatment regimen based on one or more risk scores.

7. The heart failure treatment management system according to any one of claims 1 to 6, wherein the heart failure treatment optimization system comprises a risk score generator for providing one or more risk scores based on patient data.

8. The heart failure treatment management system according to claim 6 or 7, wherein at least one of the heart failure treatment delivery system or the heart failure treatment optimization system is configured to collect patient data to validate the one or more risk scores.

9. The heart failure treatment management system according to any one of claims 1 to 8, wherein the non-implantable sensor of the sensor system includes a wearable sensor of the patient.

10. The heart failure treatment management system according to any one of claims 1 to 9, wherein the implantable sensor of the sensor system includes one or more electrical contacts.

11. The heart failure treatment management system according to claim 10, wherein the external sensor includes at least one of an image sensor, a weighing scale, a pressure sensor, or a microphone operably coupled to a circuit of an external device.

12. The heart failure treatment management system according to any one of claims 1 to 11, wherein the heart failure treatment delivery system includes at least one of a drug dispenser containing one or more drugs, an automatic treatment pump, a graphical user interface for providing treatment information to the patient, or an implantable electrical stimulation device.

13. The heart failure treatment management system according to any one of claims 1 to 12, wherein the heart failure treatment delivery system comprises a processor configured to transmit, via a communication interface, a request for delivering one or more drugs for storage at hand from a remote location based on the treatment regimen.

Images