Method and apparatus for estimating the detachment state of a mechanical circulatory assist device.

Abstract

A method and apparatus for determining a patient's withdrawal status in association with a mechanical circulatory support device is provided. The method includes receiving a set of signals from a mechanical circulatory support device implanted in the patient's heart; determining a set of features using a computer processor, at least partially based on the set of signals; providing the set of features as input to a machine learning model trained to output a patient's withdrawal status; and displaying an indication of the patient's withdrawal status output from the machine learning model on a user interface associated with the mechanical circulatory support device.

Description

Technical Field

[0004] , , ,

[0001] The present disclosure relates to techniques for determining a detachment state based on signals from a mechanical circulatory assist device.

Background Art

[0002] Cardiovascular diseases are a major cause of morbidity, mortality, and burden in global healthcare. Various treatment modalities ranging from pharmaceuticals to mechanical devices and transplantation have been developed for heart health. Temporary heart assist devices such as heart pump systems provide hemodynamic assistance and promote heart recovery. Some heart pump systems can be inserted percutaneously into the heart and operate in parallel with the native heart to complement cardiac output. Examples of such devices include the Impella® family of devices (Abiomed, Inc., Danvers, MA). Such heart pump systems can have sensors that detect blood pressure (or assess differential pressure across a membrane), monitor motor current, and use the sensor and motor current readings to help identify pump positioning.

[0003] Such a pump can be positioned, for example, within a heart chamber such as the left ventricle and assist the heart. In this case, the pump can be inserted via the femoral artery using a hollow catheter, advanced to the left ventricle of the patient's heart, and introduced therein. From this position, the pump inlet can draw in blood and the pump outlet can pump blood into the aorta. Thus, the function of the heart can be replaced or at least assisted by the operation of the pump.

[0004] An intravascular blood pump is typically connected to a separate cardiac pump controller that controls the pump, including its motor speed, and collects and displays operational data about the blood pump, such as cardiac signal levels, battery temperature, blood flow rate, and piping integrity. An exemplary cardiac pump controller is available from ABIOMED, ​​Inc. under the trademark name Automated Impella Controller®. The controller sounds an alarm when operational data values ​​exceed predetermined values ​​or ranges, for example, when leakage, aspiration, and / or pump malfunction are detected. The controller may include a video display screen that shows a graphical user interface configured to display operational data and / or alarms. The controller may be configured to transmit data associated with pump operation and / or physiological information associated with the patient in whom the pump is implanted to an auxiliary device that allows healthcare providers to view the information remotely from the patient. [Overview of the project] [Means for solving the problem]

[0005] Percutaneous coronary intervention (PCI) is a minimally invasive procedure used to open blocked coronary arteries. Examples of PCI include balloon angioplasty, stent angioplasty, and atherectomy. Some patients undergoing PCI may receive assistance from a mechanical circulatory support (MCS) device during the procedure. Following PCI, as the patient's natural cardiac function improves and reliance on the MCS device is no longer necessary, the patient may be gradually weaned from the MCS device with the aim of removing it. The timing and extent to which patient support should be reduced with the aim of removing the MCS device can be a multifaceted decision. Currently, there are no established protocols regarding the reduction of MCS device support. Rather, the decision to wean a patient from the MCS device by reducing MCS device support is usually observational, based on the professional best practice of the healthcare provider delivering the treatment to the patient.

[0006] The systems, devices, and methods described herein relate to data-driven techniques that provide context for decisions regarding when and to what extent to wean a patient from MCS device assistance. For example, some embodiments of the present disclosure relate to clinical decision aid tools configured to display indications of a patient's weaning status based at least in part on measurements determined from MCS device signals sensed by one or more sensors on the MCS device and a model trained on historical patient cohort data. In some embodiments, the model may be implemented as a machine learning (ML) model trained to output relative scores and indicate a patient's tolerance to reductions in MCS device assistance.

[0007] In one aspect, a computer implementation method is provided. The computer implementation method includes receiving a set of signals from a mechanical circulatory support device implanted in a patient's heart, determining a set of features using a computer processor based at least partially on the set of signals, providing the set of features as input to a machine learning model trained to output withdrawal states about the patient, and displaying indications of the withdrawal states about the patient output from the machine learning model on a user interface associated with the mechanical circulatory support device.

[0008] In another aspect, the set of signals includes at least one first signal associated with the operation of a mechanical circulatory assistance device and at least one second signal associated with the patient's physiology. In another aspect, determining a set of features based at least in part on the set of signals includes determining one or more of contractility features, pulsatile features, or heart rate features. In another aspect, the method further includes receiving an indication via a user interface for determining a patient's disengagement state, and providing the set of features as input to a machine learning model, which is performed in response to receiving the indication for determining the disengagement state. In another aspect, the method further includes receiving a user input via a user interface associated with disengaging a patient from a mechanical circulatory assistance device, and retraining a machine learning model based at least in part on the user input. In another aspect, the method further includes receiving medical information from an electronic medical record associated with the patient, and providing the medical information as input to a machine learning model. In another aspect, the mechanical circulatory assistance device includes a heart pump, and the method further includes receiving a command via a user interface to reduce the speed of the heart pump, sending a command to the heart pump controller to reduce the speed of the heart pump after receiving the command to reduce the speed, and updating the patient's let-go state after reducing the speed of the heart pump. In another aspect, updating the patient's let-go state includes using a computer processor to determine a second set of features based at least in part on a set of signals received after reducing the speed of the heart pump, providing the second set of features as input to a machine learning model, and displaying an indication of the updated patient's let-go state output from the machine learning model when the second set of features is provided as input, on a user interface associated with the mechanical circulatory assistance device.In another aspect, displaying indications of patient weaning status output from a machine learning model on a user interface associated with a mechanical circulatory support device includes displaying a hemodynamic stability score for the patient. In yet another aspect, the method further includes displaying one or more user interface elements on the user interface that allow a user to simulate patient weaning from a mechanical circulatory support device; performing a weaning simulation in response to receiving user input via one or more user interface elements; and displaying an updated weaning status score on the user interface determined based on performing the weaning simulation.

[0009] In one aspect, a controller for a mechanical circulatory support device is provided. The controller includes at least one hardware processor, which is configured to determine a set of features based at least in part on a set of signals received from a mechanical circulatory support device implanted in the patient's heart, to provide the set of features as input to a machine learning model trained to output a patient-related withdrawal state, and to display an indication of the patient-related withdrawal state output from the machine learning model on a user interface associated with the mechanical circulatory support device.

[0010] In another aspect, the set of signals includes at least one first signal associated with the operation of a mechanical circulatory assistance device and at least one second signal associated with the patient's physiology. In another aspect, the set of features includes one or more of contractile features, pulsatile features, or heart rate features. In another aspect, at least one hardware processor is further configured to receive an indication via a user interface for determining the patient's disengagement state, and to provide the set of features as input to a machine learning model, in response to receiving the indication for determining the disengagement state. In another aspect, at least one hardware processor is further configured to receive a user input via a user interface associated with disengaging the patient from the mechanical circulatory assistance device, and to retrain a machine learning model based at least in part on the user input. In another aspect, at least one hardware processor is further configured to receive medical information from an electronic medical record associated with the patient, and to provide the medical information as input to a machine learning model. In another aspect, the mechanical circulatory assistance device includes a heart pump, and at least one hardware processor is further configured to receive a command via a user interface to reduce the speed of the heart pump, to reduce the speed of the heart pump after receiving the command to reduce the speed, and to update the patient's let-go state after reducing the speed of the heart pump. In another aspect, updating the patient's let-go state includes determining a second set of features based at least in part on a set of signals received after reducing the speed of the heart pump, providing the second set of features as input to a machine learning model, and displaying an indication of the updated patient's let-go state output from the machine learning model when the second set of features is provided as input, on a user interface associated with the mechanical circulatory assistance device.In another aspect, displaying indications of patient weaning status output from a machine learning model on a user interface associated with a mechanical circulatory support device includes displaying a hemodynamic stability score for the patient. In yet another aspect, at least one hardware processor is further configured to display one or more user interface elements on the user interface that allow a user to simulate patient weaning from a mechanical circulatory support device, to perform the weaning simulation in response to receiving user input via one or more user interface elements, and to display an updated weaning status score on the user interface determined based on the performance of the weaning simulation.

[0011] In one aspect, a cardiac pump system is provided. The cardiac pump system includes a cardiac pump including at least one pressure sensor configured to sense pressure within a portion of a patient's heart, and a controller. The controller is configured to determine a set of features, at least in part, based on a set of signals received from the cardiac pump, wherein the set of features is a first feature based on sensed pressure, and to provide the set of features as input to a machine learning model trained to output out-of-bounds states relating to a patient, and to display an indication of the patient out-of-bounds states output from the machine learning model on a user interface associated with the cardiac pump system.

[0012] In another aspect, the set of signals includes at least one first signal associated with the operation of the heart pump and at least one second signal associated with the patient's physiology. In another aspect, the set of features includes one or more of contractile features, pulsatile features, or heart rate features. In another aspect, the controller is further configured to receive indications via a user interface for determining the patient's detachment state, and to provide the set of features as input to a machine learning model, in response to receiving indications for determining the detachment state. In another aspect, the controller is further configured to receive user inputs via a user interface associated with detaching the patient from the mechanical circulatory assistance device, and to retrain the machine learning model based at least in part on the user inputs. In another aspect, the controller is further configured to receive medical information from an electronic medical record associated with the patient, and to provide the medical information as input to a machine learning model. In another aspect, the controller is further configured to receive a command via the user interface to reduce the rate of the cardiac pump, to reduce the rate of the cardiac pump after receiving the command to reduce the rate, and to update the patient's attrition status after reducing the rate of the cardiac pump. In another aspect, updating the patient's attrition status includes determining a second set of features based at least in part on a set of signals received after reducing the rate of the cardiac pump, providing the second set of features as input to a machine learning model, and displaying an indication of the updated patient's attrition status output from the machine learning model when the second set of features is provided as input on the user interface. In another aspect, displaying an indication of the patient's attrition status output from the machine learning model on the user interface includes displaying a hemodynamic stability score for the patient.In another aspect, the controller is further configured to display one or more user interface elements on the user interface that allow the user to simulate patient weaning from a mechanical circulatory assist device, to perform the weaning simulation in response to receiving user input via one or more user interface elements, and to display an updated weaning state score on the user interface determined based on the performance of the weaning simulation.

[0013] In one aspect, a computer implementation method is provided for training a machine learning model used to determine the weaning status of a patient. The computer implementation method includes receiving historical patient cohort data relating to a plurality of patients, each of the plurality of patients having an implanted mechanical circulatory support device, and the historical patient cohort data including a set of signals associated with the mechanical circulatory support device for each of the plurality of patients; associating labels in the historical patient cohort data with each of the plurality of patients, the labels indicating whether the patient was able to tolerate weaning from the mechanical circulatory support device or not; and training a machine learning model at least in part on the historical patient cohort data and the labels associated with the plurality of patients. [Brief explanation of the drawing]

[0014] [Figure 1A] Figure 1A shows an illustrative cardiac assist device that may be used in conjunction with some embodiments of the present disclosure.

[0015] [Figure 1B] Figure 1B shows an illustrative cardiac support system including the cardiac support device shown in Figure 1A.

[0016] [Figure 2] Figure 2 illustrates a flowchart of the process for training a model and outputting the patient's withdrawal status, according to several embodiments of this technology.

[0017] [Figure 3A] Figure 3A schematically illustrates exemplary features that can be used to train a model and predict a patient's withdrawal state, according to some embodiments of the present technology.

[0018] [Figure 3B] Figure 3B schematically illustrates a patient timeline associated with PCI procedures for patients who withstood withdrawal and patients who did not withstand withdrawal, according to some embodiments of the present technology.

[0019] [Figure 4A] Figure 4A schematically illustrates different scenarios for classifying historical patient cohort data, according to some embodiments of the present technology.

[0020] [Figure 4B] Figure 4B illustrates an exemplary decision tree for determining labels for historical patient cohort data used to train a model, according to some embodiments of the present technology.

[0021] [Figure 4C] Figure 4C illustrates an alternative exemplary decision tree for determining labels for historical patient cohort data used to train a model, according to some embodiments of the present technology.

[0022] [Figure 5] Figure 5 illustrates a flowchart of a process for determining a patient's withdrawal state using a trained model, according to some embodiments of the present technology.

[0023] [Figure 6] Figure 6 illustrates a part of a user interface for initiating a withdrawal state determination process, according to some embodiments of the present technology.

[0024] [Figure 7] Figure 7 illustrates a portion of an alternative user interface for initiating the detachment state determination process according to some embodiments of this technology.

[0025] [Figure 8] Figure 8 illustrates a portion of the user interface showing the calculation of an ongoing departure state determination process according to several embodiments of this technology.

[0026] [Figure 9] Figure 9 illustrates a portion of a user interface configured to display an indication of a patient's withdrawal status, according to several embodiments of the present technology.

[0027] [Figure 10] Figure 10 illustrates a portion of an alternative user interface configured to display an indication of the patient's withdrawal status, according to some embodiments of the present technology.

[0028] [Figure 11] Figure 11 schematically illustrates the tracking of a patient's withdrawal status over time, according to several embodiments of this technology. [Modes for carrying out the invention]

[0029] Detailed explanation Determining the timing and extent to which a patient is weaned from the support provided by a mechanical circulatory support (MCS) device following an MCS-assisted PCI procedure can be a multifaceted decision, typically informed solely by the observations and expertise of the healthcare provider treating the patient. We recognize and understand that both patients and healthcare providers can benefit from data-driven techniques that provide context to the weaning decision process by predicting the patient's hemodynamic stability. For example, quantifying the acute risks of not weaning a patient from MCS device support, or the acute risks of weaning a patient too early, based solely on observation, can be difficult. If weaned too early, such patients may be at a higher risk of decompensation or MCS device reimplantation within a short time (e.g., 48 hours) following device removal. Furthermore, there can be significant variability among healthcare providers regarding the timing and extent to which MCS-assisted patients are weaned following a PCI procedure. This variability can be exacerbated based on the healthcare provider's experience level, which can play a significant role in determining whether, when, and to what extent a patient can be weaned. To this end, some embodiments of this technology may enable healthcare providers with varying experience levels to leverage the collective expertise of a large number of healthcare providers and patients who have successfully or unsuccessfully weaned patients from MCS devices following PCI procedures.

[0030] In some embodiments, data collected from a cohort of patients who have undergone MCS-assisted PCI procedures and subsequently been weaned from the MCS device (including successfully or unsuccessfully) following the PCI procedure may be used to train a predictive model (e.g., a machine learning model). Through training, the model may learn characteristics in the input data that best predict whether a patient is likely to successfully wean from the MCS device. For example, the model may apply greater weights to those characteristics throughout the learning process. Following training, the trained model may be used to guide the weaning process for a patient based on current data associated with the patient, such as that recorded by the implanted MCS device. For example, the trained model may be trained to output a weaning status score representing the patient's predicted tolerance to reduced assistance from the MCS device.

[0031] Figure 1A shows an illustrative embodiment of a blood pump assembly 100 according to the present disclosure. The blood pump assembly 100 may include a pump 101, a pump housing 103, a proximal end 105, a distal end 107, a cannula 108, an impeller (not shown), a non-traumatic extension 102, a catheter 112, an inlet region 110, an outlet region 106, and a blood drainage opening 117. In some embodiments, the catheter 112 may be connected to the inlet region 110 of the cannula 108. The inlet region 110 may be located near the proximal end 105 of the cannula, and the outlet region 106 may be located toward the distal end 107 of the cannula 108. The inlet region 110 may include a pump housing 103 having a peripheral wall 111 extending about the rotation axis of the impeller blades, the peripheral wall 111 positioned radially outward from the inner surface with respect to the rotation axis of the impeller. The impeller may be rotatably coupled to the pump 101 in the inlet region 110 adjacent to a blood discharge opening 117 formed within the wall 111 of the pump housing 103. The pump housing 103 may be made of metal, according to several implementations. An extension 102, also referred to as a "pigtail," may be connected to the distal end 107 of the cannula 108 and may help stabilize the blood pump assembly 100 and / or position it correctly within the heart. The pigtail 102 may be configured from a straight configuration to a partially curved configuration. The pigtail 102 may be made of a flexible material, at least partially, and may have dual rigidity. It should be understood that some embodiments of the pump assembly may not include the pigtail 102.

[0032] The cannula 108 may have a shape that matches (or resembles) the biostructure of the patient's right ventricle. In the exemplary embodiment shown in Figure 1A, the cannula has a proximal end 105 positioned near the patient's inferior vena cava and a distal end 107 positioned near the pulmonary artery. The cannula 108 may include a first compartment Sl extending from the inflow region to point B between the inlet region 110 and the outlet region 106. The cannula 108 may also include a second compartment S2 extending from point C between the inlet region 110 and the outlet region 106 to the outlet region 106. In some implementations, points B and C may be located in the same place along the cannula 108. The first compartment Sl of the cannula may form an "S" shape in a first plane. In some implementations, the compartment Sl may have a curvature of 30 to 180 degrees. The second compartment S2 of the cannula may form an "S" shape in the second plane. In some implementations, compartment S2 can have a curvature of 30 to 180 degrees (e.g., 40°, 50°, 60°, 70°, 80°, 90°, 100°, 110°, 120°, 130°, 140°, 150°, 160°, or 170°). The second plane may differ from the first plane. In some implementations, the second plane may be parallel to or the same as the first plane.

[0033] While shown with an "S" shape, it should be understood that other implementations of the blood pump assembly may be formed with other shapes (e.g., a "U" shape) or without any shape at all when outside the body. In such implementations, the cannula may be formed from a flexible material so that it can bend during insertion and achieve the desired shape when it comes inside the patient's heart.

[0034] In some implementations, the blood pump assembly 100 can be percutaneously inserted into the right ventricle through the internal jugular vein, through the right atrium. When properly positioned, the blood pump assembly 100 can deliver blood from an inlet region 110 located inside the patient's right atrium, through a cannula 108, to a blood discharge opening 117 of the pump housing 103 positioned in the pulmonary artery. Alternatively, in some implementations, the blood pump assembly 100 can be percutaneously inserted into the left ventricle through the femoral artery, delivering blood from the left ventricle into the aorta.

[0035] Figure 1B shows that the blood pump assembly 100 may form part of a cardiac assist system 120. The cardiac assist system 120 may also include a controller 130 (e.g., an Automated Impella Controller®, hereafter referred to as “AIC”, manufactured by ABIOMED, ​​Inc., Danvers, Mass.), a display 140, a purge subsystem 150, a connector cable 160, a plug 170, and a repositioning unit 180. As shown, the controller 130 may include a display 140. The controller 130 may be configured to monitor and control the operation of the blood pump assembly 100. During operation, the purge subsystem 150 may be configured to deliver purge fluid to the blood pump assembly 100 through a catheter 112 to prevent blood from entering the motor of the cardiac pump (not shown). In some implementations, the purge fluid is a glucose solution (e.g., 5% glucose in water with 25 or 50 IU / mL heparin, although the solution does not necessarily have to contain heparin in all embodiments). A connector cable 160 may provide an electrical connection between the blood pump assembly 100 and the controller 130. A plug 170 may connect the catheter 112, the purge subsystem 150, and the connector cable 160. In some implementations, the plug 170 may include a storage device (e.g., memory) configured to store, for example, operating parameters, to facilitate patient transfer to another controller if necessary. A repositioning unit 180 may be used to reposition the blood pump assembly 100 within the patient's heart (e.g., by maintaining the position of the pump assembly relative to the patient).

[0036] As shown in Figure 1B, in some embodiments, the cardiac support system 120 may include a purge subsystem 150 having a container 151, a supply line 152, a purge cassette 153, a purge disc 154, purge tubing 155, a check valve 156, a pressure reservoir 157, an infusion filter 158, and a side arm 159. The container 151 may be, for example, a bag or a bottle. As understood, in other embodiments, the cardiac support system 120 may not include the purge subsystem. In some embodiments, the purge fluid may be stored in the container 151. The supply line 152 may provide a fluid connection between the container 151 and the purge cassette 153. The purge cassette 153 may control the extent to which the purge fluid in the container 151 is delivered to the blood pump assembly 100. For example, the purge cassette 153 may include one or more valves to control the pressure and / or flow rate of the purge fluid. The purge disc 154 may include one or more pressure and / or flow sensors to measure the pressure and / or flow rate of the purge fluid. As shown, the controller 130 may include the purge cassette 153 and the purge disc 154. Purge tubing 155 may provide a fluid connection between the purge disc 154 and the check valve 156. A pressure reservoir 157 may provide additional filling volume during purge fluid exchange. In some implementations, the pressure reservoir 157 may include a flexible rubber diaphragm with an expansion chamber to provide additional filling volume. An infusion filter 158 may help prevent bacterial contamination and air from entering the catheter 112. A side arm 159 may provide a fluid connection between the infusion filter 158 and the plug 170. Although shown to have separate purge tubing and connector cables, it should be understood that in some embodiments, the cardiac support system 120 may include a single connector having both fluid and electrical lines connectable to the controller 130.

[0037] During operation, the controller 130 may be configured to receive measurements from one or more pressure sensors (not shown) included as part of the blood pump assembly 100 and purge disk 154. The controller 130 may also be configured to control the operation of the motors (not shown) of the blood pump assembly 100 and purge cassette 153. In some embodiments, the controller 130 may be configured to control and measure the pressure and / or flow rate of the purge fluid via the purge cassette 153 and purge disk 154. During operation, after exiting the purge subsystem 150 through the side arm 159, the purge fluid may be guided through a purge lumen (not shown) in the catheter 112 and plug 170. The catheter 112, connector cable 160, and sensor cable (not shown) in the plug 170 may provide electrical connections between components of the blood pump assembly 100 (e.g., one or more pressure sensors) and the controller 130. A catheter 112, a connector cable 160, and a motor cable (not shown) within a plug 170 may provide an electrical connection between the motor of the blood pump assembly 100 and the controller 130. During operation, the controller 130 may be configured to receive measurements from one or more pressure sensors of the blood pump assembly 100 through a sensor cable (e.g., optical fiber) and to control the power delivered to the motor of the blood pump assembly 100 through the motor cable. By controlling the power delivered to the motor of the blood pump assembly 100, the controller 130 may be operable to control the speed of the motor.

[0038] Various modifications can be made to the cardiac assist system 120 and one or more of its components. For example, one or more additional sensors may be added to the blood pump assembly 100. In another embodiment, a signal generator may be added to the blood pump assembly 100 to generate a signal indicating the rotational speed of the motor of the blood pump assembly 100. In yet another embodiment, one or more components of the cardiac assist system 120 may be isolated. For example, the display 140 may be incorporated into another device that communicates with the controller 130 (e.g., wirelessly or through one or more electrical cables).

[0039] Figure 2 illustrates a flowchart of process 200 for training a model and outputting predictions of patient tolerance to reduced MCS device assistance, according to several embodiments of the present technology. Process 200 begins with act 210, in which historical patient cohort data relating to several patients who have undergone MCS device-assisted PCI procedures (also referred herein as “high-risk PCI” or “HRPCI” procedures) are received. In some embodiments, the historical patient cohort data may include values ​​relating to one or more features captured during the withdrawal time window between patient withdrawal following a PCI procedure. Examples of features that may be included in the historical patient cohort data are shown in Figure 3A. For example, such features may include, but are not limited to, cardiac pump operation features 302 (e.g., motor current, pressure information, pump speed, blood flow) and patient physiological features 304 (e.g., left ventricular end-diastolic pressure (LVEDP), heart rate, pulsatile, contractile, mean arterial pressure (MAP)). In some embodiments, one or more of the features may depend on the motor speed of the cardiac pump (e.g., P level). For example, contractility features may include the ratio of contractility at high P levels compared to low P levels, contractility normalized for a specific amount of assistance provided by the pump (e.g., normalized based on P level), etc. In some embodiments, other features (e.g., features derived from the patient's electronic health record) may also be included in the historical patient cohort data.

[0040] An exemplary patient treatment timeline 300 for a patient with an implanted MCS device is shown in Figure 3B. As shown in timeline 300, the patient may undergo an MCS-assisted PCI procedure during a first time window 310. After the PCI procedure, the patient may enter a weaning decision time window 312, during which a decision is made as to whether or not to wean the patient from the MCS device, and if applicable, to initiate weaning by reducing the assistance provided by the MCS device (e.g., by reducing the pump rate). Plot 320 shows characteristic values ​​over time for patients who tolerated weaning from the MCS device following the PCI procedure. For example, as shown in plot 320, when the pump rate (P level) is reduced during the weaning decision time window 312, and as a result blood flow through the MCS device is reduced, the aortic pressure (AoP) measured from the patient's heart remains at a steady value, indicating tolerance to the weaning process. As shown in timeline 300, some patients may not be able to tolerate the weaning process well, and as a result, the patient may continue to receive assistance from the MCS device for a time interval 314. After at least some additional MCS device assistance has been provided, another weaning decision time window 316 may occur, during which weaning may be attempted. Plot 330 shows characteristic values ​​over time for patients who could not tolerate weaning from the MCS device following the PCI procedure. For example, as shown in plot 330, if the pump speed (P level) is reduced during the first weaning decision time window, the patient's aortic pressure becomes unstable, resulting in the patient being transferred to the intensive care unit and continued assistance being provided from the MCS device.

[0041] Returning to process 200 shown in Figure 2, after historical patient cohort data is received in action 210, process 200 may proceed to action 220, where the received historical data is labeled. As shown in Figure 4A, in some embodiments, the received historical data may be labeled according to four different scenarios. In the first scenario, weaning is attempted and tolerated by the patient. An embodiment of the first scenario is depicted in plot 320 in Figure 3B. In the second scenario, the typical weaning process of gradually reducing the pump speed was not attempted, but nevertheless, the MCS device was successfully extracted. In this scenario, the pump speed may be reduced from a higher assist level to the minimum pump speed (e.g., P0) almost immediately (e.g., during the weaning decision time window 312 shown in timeline 300 in Figure 3B) without the series of gradually decreasing pump speeds that are typical of weaning. In the third scenario, weaning is attempted but not tolerated by the patient. For example, a gradual reduction in pump speed may be attempted during weaning, but the patient may be returned to a higher level of support and transferred to the ICU (or fail to meet other criteria, examples of which are described below). An example of this scenario is depicted in plot 330 of Figure 3B. In a fourth scenario, weaning is not attempted and is not tolerated by the patient. In this scenario, the patient may be immediately transferred to the ICU following the PCI procedure at the end of the PCI procedure (e.g., during the weaning decision time window 312 shown in timeline 300 of Figure 3B) without any reduction in pump speed level.

[0042] Figure 4B illustrates an embodiment of decision tree 400 that, in some embodiments, can be used to determine whether patients with data within the received historical patient cohort data were able to tolerate or not tolerate reduced MCS device assistance. As shown in act 402 of Figure 4B, at the end of the PCI procedure, extraction may not be attempted for some patients, and they may continue to receive MCS assistance (e.g., the fourth scenario above). Those patients may be labeled as unable to tolerate reduced MCS device assistance. For patients in whom extraction (act 404) was attempted following the PCI procedure, it may be determined whether the patient died or survived. If the patient died (act 406) within a certain time (e.g., 48 hours) following extraction (act 408), the patient may be labeled as unable to tolerate reduced MCS device assistance. If the patient survives (Act 410) or dies after a specific time (e.g., 48 hours) following the removal (Act 412), it may be determined whether the patient suffered any adverse events. If the patient did not suffer any adverse events (Act 414), the patient may be labeled as having tolerated the reduced MCS device support. If the patient suffered one or more adverse events (Act 416), it may be determined whether the adverse events occurred within a specific time (e.g., 48 hours) following the removal. If the patient suffered (one or more) adverse events more than a specific time (e.g., 48 hours) after the removal (Act 418), the patient may be labeled as having tolerated the reduced MCS device support. Otherwise (Act 420), the patient may be labeled as having not tolerated the reduced MCS device support.

[0043] Figure 4C illustrates another embodiment of decision tree 450, which in some embodiments may be used to determine whether a patient with data within the received historical patient cohort data was able to tolerate or not tolerate reduced MCS device support. As shown in action 452 of Figure 4C, the MCS device may be implanted in the patient and a high-risk PCI procedure may be performed. Then, in action 454, it may be determined whether the MCS device support lasted less than a first threshold amount (e.g., 6 hours). If it is determined that the MCS device support lasted less than a first threshold amount, in action 456, it may be determined whether the MCS device was successfully removed (e.g., in a cardiac catheterization lab) and the patient is alive. If it is determined that the MCS device was removed and the patient is alive, the patient may be labeled as having tolerated reduced MCS device support. If, in action 454, it is determined that the duration of MCS device assistance has exceeded a first threshold amount, then in action 458, it may be determined whether the duration of MCS device assistance has exceeded a second threshold amount (e.g., 12 hours). If, in action 460, it is determined that the duration of MCS device assistance has exceeded a second threshold amount, then it may be determined whether the patient continued to receive MCS device assistance and / or was transferred to the intensive care unit. If the patient continued to receive MCS device assistance and / or was transferred to the intensive care unit, the patient may be labeled as unable to tolerate reduced MCS device assistance. Although not shown in Figure 4C, the decision tree 450 may also include actions to consider the occurrence of adverse events after cardiac pump removal (e.g., occurring within a specific time period after removal), an example thereof, is described in relation to the decision tree 400 shown in Figure 4B.

[0044] The decision trees 400 shown in Figure 4B and 450 shown in Figure 4C are illustrative, and it should be understood that different labeling schemes using different inclusion and / or exclusion criteria may, in some embodiments, be used to label patients in historical patient cohort data as tolerable or not tolerable to reduced MCS device assistance.

[0045] Returning to process 200 shown in Figure 2, after each patient included in the historical patient data has been labeled in action 220 as tolerable / not tolerable with reduced MCS device assistance, process 200 may proceed to action 230, where a model (e.g., a machine learning model) is trained using the labeled data. For example, values ​​for multiple features extracted at specific time intervals (e.g., 5-second, 15-second, 30-second intervals) during patient-specific withdrawal cycles within the historical patient cohort may be provided to the model as input, and the model may be trained to output associated labels (e.g., tolerable / not tolerable) for the patients. The values ​​for features may be values ​​at a single point in time, medians or means determined over a specific time window, and / or measures of variability (e.g., standard deviation) of values ​​over a specific time window.

[0046] In some embodiments, the model may be trained (or retrained) on at least in part the inputs provided by the healthcare provider. For example, after receiving an indication of a patient's withdrawal state, the healthcare provider may, using one or more of the techniques described herein, provide feedback based on the received indication and / or information associated with the patient used to generate the withdrawal state indication (e.g., information from the patient's EMR, trend data measured or estimated from the cardiac pump, etc.). The feedback provided by the healthcare provider may be used to train the model, which in turn may refine the withdrawal state indications provided by the model in further iterations of the withdrawal state determination process. In some embodiments, feedback from the healthcare provider may be provided during the initial training of the model. For example, the healthcare provider may scrutinize the data within the historical patient cohort and the withdrawal states provided as output of the model and provide feedback (for example, via a user interface) that may be used to further train the model. Thus, some embodiments may provide physician-informed withdrawal state recommendations with clinically relevant context.

[0047] When trained on a large amount of data contained within a historical patient cohort, the model can learn the properties of feature values ​​that predict corresponding labels about patients from the labeled data (e.g., by changing the weights in the model). In some embodiments, the model is a classification model. In such embodiments, any suitable classification model may be used, and it should be understood that such embodiments include neural network (e.g., deep learning) based models, random forest classifier models, decision tree models (e.g., gradient boosting decision tree models), or logistic regression models. Process 200 then proceeds to action 240, where the trained model is output for use in predicting dropout status scores for patients not included in the historical patient cohort data.

[0048] Figure 5 is a flowchart of process 500 for determining the withdrawal state associated with a patient to whom an MCS device is implanted. Process 500 begins with action 510, in which an indication for determining the withdrawal state with respect to the patient is received. It should be understood that the determination of the withdrawal state with respect to a patient using one or more of the techniques described herein may be performed at any preferred time. For example, in some embodiments, the withdrawal state may be determined during the PCI procedure and prior to withdrawal to determine when to initiate the withdrawal process (e.g., based on whether the patient is likely to tolerate a reduction in pump speed in their current state). In other embodiments, the withdrawal state may be determined during the withdrawal process to assess the extent to which the patient is tolerating a reduction in pump speed during withdrawal. When assessed during withdrawal, the patient's withdrawal state may be used, for example, to guide the timing of further pump speed reductions and / or increases while the patient's withdrawal state is being monitored.

[0049] Figure 6 illustrates some embodiments of the user interface 600, in which a user (e.g., a healthcare provider) can interact with the user interface 600 to initiate the withdrawal state determination process. For example, information associated with pump operation and physiological parameters associated with the patient to whom the MCS device is implanted may be displayed on the user interface. In the exemplary user interface 600, the display includes different widgets to show different types of data, including the current pump speed (e.g., P level), the patient's heart rate, and other measurements, including the number and / or total duration of low suction events, the number and / or duration of loss of pulsatile (LOP) events (e.g., any region where pulse pressure falls below a certain pressure threshold (e.g., 20 mmHg)), and the duration of elevated left ventricular end-diastolic pressure (LVEDP). Some widgets may be configured to display trend information over time regarding various measurements such as cardiac output (CO), aortic pressure (AoP), and LVEDP. One or more of the displayed (or undisplayed) measurements may be used to determine the patient's abstinence status in accordance with the techniques described herein. In addition, in some embodiments, one or more measurements from the patient's electronic health record (EHR) may be used to determine the patient's abstinence status. In some embodiments, information based at least partially on the patient's determined abstinence status may be automatically stored in the patient's EHR.

[0050] As shown in Figure 6, the user interface 600 may include an instruction to initiate the dissociation state determination process. In the embodiment shown in Figure 6, the user is instructed to reduce the pump speed to a lower level (e.g., the P level of P-2) prior to initiating the dissociation state determination process. However, it should be understood that not all embodiments of the Art require reducing the pump speed prior to initiating dissociation state determination. Rather, in some embodiments, the patient's dissociation state may be determined at any preferred pump speed, including, but not limited to, the pump speed at which the pump is operating when an indication to initiate dissociation state determination is received in action 510 of process 500. Figure 7 illustrates some embodiments of the user interface 700 configured to display user interface elements that enable a user to initiate dissociation state determination, according to some embodiments of the Art.

[0051] In some embodiments, the user interface 700 may be further configured to display one or more user interface elements (not shown) to which a healthcare provider may interact with one or more user interface elements to simulate the extent to which a change in pump speed or some other operating characteristic of the pump can be tolerated by the patient. For example, a pump implanted in a patient may currently be operating at a pump speed of P-7. In some embodiments, a healthcare provider may interact with the user interface 700 to simulate a reduction in pump speed down to a pump speed of P-6. In response to receiving an indication that a healthcare provider wishes to perform such a simulation, a set of feature values ​​may be provided to a training model, and simulated disengagement indications (e.g., disengagement scores) relating to the patient may be output. By enabling healthcare providers to simulate the extent to which changes in pump operating parameters (e.g., pump speed) affect disengagement indications, healthcare providers may gain a deeper understanding of the extent to which different features contribute to the determination of disengagement indications. In addition, the simulation results may allow healthcare providers to better estimate the likelihood that a patient can tolerate a reduction in pump speed at one or more levels prior to initiating the weaning process and / or during the weaning process. In another embodiment, the simulation may allow healthcare providers to determine to what extent the weaning state indication would change if patient health data changed in a particular way and / or if the pump speed was maintained at a certain level rather than weaning the patient. Such information can be beneficial to healthcare providers when making decisions regarding treatment options for the patient.

[0052] Returning to process 500, in response to receiving an indication for determining the patient's withdrawal status, process 500 may proceed to action 520, where a set of feature values ​​may be provided as input to a training model (e.g., a machine learning model trained according to the techniques described herein). For example, a user may interact with user interface elements displayed on a user interface (e.g., user interface 700), and in response, several values ​​relating to features associated with the patient and / or pump may be determined and provided as input to the trained model. In some embodiments, the same set of features used to train the model may be determined and provided as input to the trained model in action 520. In other embodiments, a subset of the set of features used to train the model (e.g., only those features that best predict tolerance / intolerance) may be determined and provided as input to the trained model in action 520. In some embodiments, one or more features not used to train the model (e.g., one or more values ​​received from the patient's EHR) may also be used to determine the patient's withdrawal status. Figure 8 illustrates some embodiments of the user interface 800, which, according to some embodiments of the present technology, is configured to display an indication that the patient's withdrawal state is calculated based on a set of feature values ​​provided to a model trained as input.

[0053] After providing a set of feature values ​​as input to a trained model, process 500 may proceed to action 530, in which an indication of the patient's weaning state may be displayed on the user interface, and the weaning state indication is determined at least in part based on the output of the trained model. Figure 9 illustrates a portion of the user interface 900 configured to display the patient's weaning state 910 according to some embodiments of the present technology. In the embodiments shown in Figure 9, the weaning state 910 represents a hemodynamic stability score and includes a percentage and associated color bar measurement, which can be used at least in part to determine whether the patient is ready to initiate the weaning process or whether they are tolerating the weaning process well as determined during the weaning process. A healthcare provider browsing the user interface 900 may use the weaning state 910 to guide a decision about whether, when, and / or to what extent a reduction in pump speed should be provided as the patient progresses through the weaning process. Thus, some embodiments of the present technology can be used as a clinical decision aid to facilitate decision-making regarding weaning a patient from an MCS device. Figure 10 illustrates a portion of a user interface 1000 configured to display a patient's withdrawal state 1010, according to some embodiments of the present technology.

[0054] In some embodiments, a user interface configured to display aspiration status indicators (e.g., user interface 900, user interface 1000) may further be configured to display one or more user interface elements that allow a healthcare provider to provide feedback. For example, a healthcare provider may interact with (one or more) user interface elements and comment on the aspiration status indicators (e.g., how the aspiration progressed, whether the aspiration recommendation was followed (e.g., "yes" or "no", and if "no", why)). As described herein, the feedback provided by the healthcare provider may, in some embodiments, be used to retrain the model and refine the aspiration status indicators output from the model in future iterations of the aspiration status determination process.

[0055] In some embodiments, the patient's weaning status can be tracked over time. For example, the weaning status can be tracked during the PCI procedure to identify when the patient is ready to begin weaning and to determine the extent to which the patient is tolerating weaning throughout the entire weaning process. As shown in Figure 11, the weaning status tracked over time may be displayed to the user and / or used to determine the probability or other likelihood that the patient will tolerate further reductions in MCS device assistance.

[0056] It should be understood that any of the user interfaces described herein may be displayed on a controller associated with an MCS device, and / or on an auxiliary display coupled to the controller of the MCS device, for example, across one or more networks.

[0057] While some aspects and embodiments of the technology described herein have been described above, it should be understood that various modifications, alterations, and improvements will be readily conceivable to those skilled in the art. Such modifications, alterations, and improvements are intended to be within the spirit and scope of the technology described herein. For example, those skilled in the art will readily conceivable various other means and / or structures for carrying out the functions described herein and / or obtaining one or more of the results and / or benefits, and each of such modifications and / or alterations will be considered within the scope of the embodiments described herein. Those skilled in the art will be able to recognize many equivalents to the specific embodiments described herein, or confirm them by using only routine experimentation. Therefore, it should be understood that the embodiments described herein are presented only as examples, and that embodiments of the invention may be practiced in ways other than those specifically described. In addition, any combination of two or more features, systems, articles, materials, kits, and / or methods described herein is included within the scope of this disclosure, provided that such features, systems, articles, materials, kits, and / or methods are not mutually inconsistent.

[0058] The embodiments described above can be implemented in any of a number of ways. One or more aspects and embodiments of the Disclosure involving the implementation of a process or method may utilize program instructions executable by a device (e.g., a computer, processor, or other device) to implement or control the implementation of the process or method. In this regard, various concepts of the Invention may be embodied as a computer-readable storage medium (or more computer-readable storage mediums) encoded with one or more programs (e.g., computer memory, one or more floppy disks, compact disks, optical disks, magnetic tape, flash memory, field-programmable gate arrays, or circuit configurations in other semiconductor devices, or other tangible computer storage mediums), which, when executed on one or more computers or other processors, implements a method of implementing one or more of the various embodiments described above. The (one or more) computer-readable mediums may be transportable, and the (one or more) programs stored thereon may be loaded onto one or more different computers or other processors to implement various aspects of the aspects described above. In some embodiments, the computer-readable medium may be a non-transient medium.

[0059] The embodiments of this technology described above can be implemented in any of a number of ways. For example, the embodiments may be implemented using hardware, software, or a combination thereof. When implemented in software, the software code can run on any suitable processor or set of processors, whether provided on a single computer or distributed across multiple computers. It should be understood that any component or set of components that perform the functions described above can generally be considered a controller that controls the functions described above. The controller can be implemented in a number of ways, such as using dedicated hardware or using general-purpose hardware (e.g., one or more processors) programmed with microcode or software to perform the functions listed above, and when the controller corresponds to multiple components of a system, it may be implemented in a combination of these ways.

[0060] Furthermore, it should be understood that, in non-limiting embodiments, computers can be embodied in any of several forms, such as rack-mount computers, desktop computers, laptop computers, or tablet computers. In addition, computers can be embedded in devices that are not generally considered computers but possess suitable processing capabilities, including personal digital assistants (PDAs), smartphones, or any other suitable portable or fixed electronic devices.

[0061] Furthermore, a computer may have one or more input and output devices. These devices can, among other things, be used to present a user interface. Embodiments of output devices that can be used to provide a user interface include a printer or display screen for visual presentation of output and a speaker or other sound-generating device for audible presentation of output. Embodiments of input devices that can be used for a user interface include a keyboard and pointing devices such as a mouse, touchpad, and digitized tablet. In another embodiment, a computer may receive input information through speech recognition or in other audible formats.

[0062] Such computers may be interconnected by one or more networks in any preferred form, including local area networks or wide area networks such as enterprise networks, and intelligent networks (INs) or the Internet. Such networks may be based on any preferred technology, operate according to any preferred protocol, and may include wireless networks, wired networks, or fiber optic networks.

[0063] Furthermore, as will be explained, several aspects may be embodied in one or more ways. The actions performed as part of the method may be ordered in any preferred way. Thus, embodiments may be constructed in which the actions are performed in a different order than those illustrated, and may include performing several actions simultaneously, even if they are shown as sequential actions in the illustrative embodiments.

[0064] It should be understood that all definitions defined and used herein take precedence over dictionary definitions, definitions in literature incorporated by reference, and / or the ordinary meaning of the defined term.

[0065] The indefinite articles "a" and "an" as used herein should be understood to mean "at least one" unless explicitly indicated otherwise.

[0066] The phrase "and / or" as used herein should be understood to mean "either one or both" of the elements thus combined, that is, elements that exist conjugately in some cases and disjunctly in others. Multiple elements listed using "and / or" should be interpreted in the same manner, that is, "one or more" of the elements thus combined. Other elements other than those specifically identified by the "and / or" clause may exist, whether related to or unrelated to those specifically identified elements. Therefore, in non-restrictive embodiments, a reference to "A and / or B," when used in conjunction with non-restrictive terms such as "comprising," may refer in one embodiment to A only (optionally including elements other than B), in another embodiment to B only (optionally including elements other than A), and in yet another embodiment to both A and B (optionally including other elements), and so on.

[0067] As used herein, the phrase “at least one” referring to a list of one or more elements means at least one element selected from any one or more of the elements in the list of elements, but it should be understood that it does not necessarily include at least one of every element specifically enumerated in the list of elements, nor does it exclude any combination of elements in the list of elements. This definition also allows for the optional presence of elements other than those specifically identified in the list of elements to which the phrase “at least one” refers, whether related to or unrelated to those specifically identified elements. Therefore, in non-limiting embodiments, “at least one of A and B” (or equivalently “at least one of A or B” or equivalently “at least one of A and / or B”) may refer to, in one embodiment, at least one A (and optionally including elements other than B) which may not include any B; in another embodiment, at least one B (and optionally including elements other than A) which may not include any A; and in yet another embodiment, at least one A which may include one or more, and at least one B (and optionally including other elements), and so on.

[0068] Furthermore, the terminology and grammar used herein are for illustrative purposes only and should not be considered limiting. The use of “including,” “comprising,” “having,” “containing,” “involving,” and their variations herein means that they encompass the items listed below and their equivalents, as well as any additional items.

[0069] In this specification, all transitional phrases such as "comprising," "including," "carrying," "having," "containing," "involving," "holding," "composed of," and their equivalents are understood to be open-ended, meaning they include but are not limited to. Only the transitional phrases "consisting of" and "consisting essentially of" are considered restrictive or semi-restrictive transitional phrases, respectively.

Claims

1. A computer implementation method, wherein the method is Receiving a set of signals from a mechanical circulatory support device implanted in the patient's heart, Using a computer processor, determine a set of features based at least partially on the set of signals, The set of features is provided as input to a machine learning model trained to output the withdrawal status of the patient, On the user interface associated with the mechanical circulatory support device, the indication of the patient's withdrawal status, output from the machine learning model, is displayed. Methods that include...

2. The computer implementation method according to claim 1, wherein the set of signals includes at least one first signal associated with the operation of the mechanical circulatory assistance device and at least one second signal associated with the physiology of the patient.

3. The computer implementation method according to claim 1, wherein determining a set of features based at least partially on the set of signals includes determining one or more of contractile features, pulsatile features, or heart rate features.

4. The computer implementation method further includes receiving an indication via the user interface for determining the patient's withdrawal state, The computer implementation method according to claim 1, wherein providing the set of features as input to a machine learning model is performed in response to receiving the indication for determining the departure state.

5. The user interface receives user input associated with detaching the patient from the mechanical circulatory support device, Retraining the machine learning model based at least partially on the user input. The computer implementation method according to claim 1, further comprising:

6. Receiving medical information from electronic medical records associated with the aforementioned patient, The medical information is provided as input to the machine learning model. The computer implementation method according to claim 1, further comprising:

7. The mechanical circulatory support device includes a heart pump, and the computer implementation method further includes The user interface receives a command to reduce the speed of the heart pump, After receiving the command to reduce the speed, a command is sent to the heart pump controller to reduce the speed of the heart pump, After reducing the speed of the cardiac pump, the withdrawal state relating to the patient is updated. The computer implementation method according to claim 1, including the method described in claim 1.

8. Updating the withdrawal status for the aforementioned patient means Using the computer processor, determine a second set of features based at least in part on the set of signals received after reducing the speed of the heart pump. The second set of the aforementioned features is provided as input to the machine learning model, On the user interface associated with the mechanical circulatory support device, an updated withdrawal status indication for the patient, output from the machine learning model when a second set of the features is provided as input, is displayed. The computer implementation method according to claim 7, including the method described in claim 7.

9. The computer implementation method according to claim 1, wherein displaying an indication of the patient's withdrawal status output from the machine learning model on a user interface associated with the mechanical circulatory support device includes displaying a hemodynamic stability score for the patient.

10. Displaying one or more user interface elements on the user interface that enable the user to simulate the patient being detached from the mechanical circulatory support device, In response to receiving user input via one or more user interface elements, the system performs an exit simulation. The updated departure status score, determined based on performing the departure simulation, is displayed on the user interface. The computer implementation method according to claim 1, further comprising:

11. A controller for a mechanical circulation assist device, wherein the controller comprises at least one hardware processor, The at least one hardware processor is Determining a set of features based at least partially on a set of signals received from a mechanical circulatory support device implanted in the patient's heart, The set of features is provided as input to a machine learning model trained to output the withdrawal status of the patient, On the user interface associated with the mechanical circulatory support device, the indication of the patient's withdrawal status, output from the machine learning model, is displayed. A controller configured to perform the following actions.

12. The controller according to claim 11, wherein the set of signals includes at least one first signal associated with the operation of the mechanical circulatory assist device and at least one second signal associated with the patient's physiology.

13. The controller according to claim 11, wherein the set of features includes one or more of contractile features, pulsatile features, or heart rate features.

14. The aforementioned at least one hardware processor further, The user interface is configured to receive an indication for determining the patient's withdrawal state. The controller according to claim 11, wherein providing the set of features as input to a machine learning model is done in response to receiving the indication for determining the departure state.

15. The aforementioned at least one hardware processor further, The user interface receives user input associated with detaching the patient from the mechanical circulatory support device, Retraining the machine learning model based at least partially on the user input. The controller according to claim 11, configured to perform the following:

16. The aforementioned at least one hardware processor further, Receiving medical information from electronic medical records associated with the aforementioned patient, The medical information is provided as input to the machine learning model. The controller according to claim 11, configured to perform the following:

17. The mechanical circulatory support device includes a heart pump, and the at least one hardware processor further includes The user interface receives a command to reduce the speed of the heart pump, After receiving the command to reduce the speed, the speed of the heart pump is reduced, After reducing the speed of the cardiac pump, the withdrawal state relating to the patient is updated. The controller according to claim 11, configured to perform the following:

18. Updating the withdrawal status for the aforementioned patient means Determining a second set of features based at least partially on the set of signals received after reducing the speed of the heart pump, The second set of the aforementioned features is provided as input to the machine learning model, On the user interface associated with the mechanical circulatory support device, an updated withdrawal status indication for the patient, output from the machine learning model when a second set of the features is provided as input, is displayed. The controller according to claim 17, including the controller described in claim 17.

19. The controller according to claim 11, wherein displaying an indication of the patient's withdrawal status output from the machine learning model on a user interface associated with the mechanical circulatory support device includes displaying a hemodynamic stability score for the patient.

20. The aforementioned at least one hardware processor further, Displaying one or more user interface elements on the user interface that enable the user to simulate the patient being detached from the mechanical circulatory support device, In response to receiving user input via one or more user interface elements, the system performs an exit simulation. The updated departure status score, determined based on performing the departure simulation, is displayed on the user interface. The controller according to claim 11, configured to perform the following:

21. A cardiac pump system, wherein the cardiac pump system is A cardiac pump including at least one pressure sensor configured to sense pressure within a portion of the patient's heart, Controller and Equipped with, The aforementioned controller, Determining a set of features based at least in part on a set of signals received from the heart pump, wherein the set of features is a first feature based on the perceived pressure, The set of features is provided as input to a machine learning model trained to output the withdrawal status of the patient, Displaying the patient's withdrawal status indicator, output from the machine learning model, on a user interface associated with the cardiac pump system. A system configured to perform the following actions.

22. The cardiac pump system according to claim 21, wherein the set of signals includes at least one first signal associated with the operation of the cardiac pump and at least one second signal associated with the physiology of the patient.

23. The cardiac pump system according to claim 21, wherein the set of features includes one or more contractile features, pulsatile features, or heart rate features.

24. The controller further, The user interface is configured to receive an indication for determining the patient's withdrawal state. The cardiac pump system according to claim 21, wherein providing the set of features as input to a machine learning model is performed in response to receiving the indication for determining the withdrawal state.

25. The controller further, The user interface receives user input associated with detaching the patient from the cardiac pump, Retraining the machine learning model based at least partially on the user input. The cardiac pump system according to claim 21, configured to perform the following:

26. The controller further, Receiving medical information from electronic medical records associated with the aforementioned patient, The medical information is provided as input to the machine learning model. The cardiac pump system according to claim 21, configured to perform the following:

27. The controller further, The user interface receives a command to reduce the speed of the heart pump, After receiving the command to reduce the speed, the speed of the heart pump is reduced, After reducing the speed of the cardiac pump, the withdrawal state relating to the patient is updated. The cardiac pump system according to claim 21, configured to perform the following:

28. Updating the withdrawal status for the aforementioned patient means Determining a second set of features based at least partially on the set of signals received after reducing the speed of the heart pump, The second set of the aforementioned features is provided as input to the machine learning model, On the user interface, display an updated withdrawal status indication for the patient, which is output from the machine learning model when a second set of the features is provided as input. The cardiac pump system according to claim 27, including the following:

29. The cardiac pump system according to claim 21, wherein displaying an indication of the patient's withdrawal status output from the machine learning model on the user interface includes displaying a hemodynamic stability score for the patient.

30. The controller further, Displaying one or more user interface elements on the user interface that enable the user to simulate the patient being detached from the heart pump, In response to receiving user input via one or more user interface elements, the system performs an exit simulation. The updated departure status score, determined based on performing the departure simulation, is displayed on the user interface. The cardiac pump system according to claim 21, configured to perform the following:

31. A computer implementation method for training a machine learning model used to determine the withdrawal status of a patient, wherein the computer implementation method is Receiving historical patient cohort data relating to multiple patients, each of which has an implanted mechanical circulatory support device, and the historical patient cohort data for each of the multiple patients includes a set of signals associated with the mechanical circulatory support device. Associating a label with each of the multiple patients in the aforementioned chronological patient cohort data, wherein the label indicates whether the patient was able to tolerate weaning from the mechanical circulatory support device or not. Training a machine learning model based at least partially on the aforementioned patient cohort data and the labels associated with the aforementioned multiple patients. Computer implementation methods, including those mentioned above.

Images