Classifications

• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H20/00—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance
  • G16H20/10—ICT specially adapted for therapies or health-improving plans, e.g. for handling prescriptions, for steering therapy or for monitoring patient compliance relating to drugs or medications, e.g. for ensuring correct administration to patients
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
  • G16H50/20—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for computer-aided diagnosis, e.g. based on medical expert systems
• • G—PHYSICS
  • G16—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR SPECIFIC APPLICATION FIELDS
  • G16H—HEALTHCARE INFORMATICS, i.e. INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR THE HANDLING OR PROCESSING OF MEDICAL OR HEALTHCARE DATA
  • G16H50/00—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics
  • G16H50/50—ICT specially adapted for medical diagnosis, medical simulation or medical data mining; ICT specially adapted for detecting, monitoring or modelling epidemics or pandemics for simulation or modelling of medical disorders

Definitions

• FIELD FIELD
• the human heart is a pumping organ that actively circulates blood throughout the body.
• the pumping action is generated by the contraction of the cardiac muscles to decrease the size of a section of the heart, for example, an auricle or ventricle, and exert a mechanical force on the blood contained therein. These contractions, repeated in cycles, create the human heartbeat.
• Cardiac contractility which represents an ability of the heart muscle to contract for the pumping action, is an important cardiovascular parameter that has to be monitored for patients undergoing cardiac treatments.
• Ees left ventricular end-systolic elastance
• Elastances, including Ees are generally measured by pressure to volume ratio within a corresponding heart chamber. Both pressure and the volume in the chamber are determined by the state of contraction of the chamber. For instance, during systole in which the heart contracts, pressure increases to decrease the volume by squeezing the blood out of the corresponding chamber.
• the end- systolic elastance is therefore the pressure to volume ratio when a systole has just ended.
• Ees is the slope of the ESPVR curve for the left ventricle.
• the conventional techniques for measuring E es depend on this 1 1608025632.3 Attorney Docket No.390351-100201 definition—to estimate/measure E es they will have to necessarily determine the left ventricular pressure (P LV ) and left ventricular volume (V LV ) at multiple points to generate a ESPVR curve. [0006] These conventional methods of measuring or estimating Ees pose significant technical challenges.
• V LV estimation methods are inaccurate: it has been experimentally known that the relationship between the true and estimated VLV varies with changes in conditions.
• P LV is not measured for the purposes of monitoring hemodynamics in clinical practice because inserting a catheter to continuously measure PLV outweighs its benefits due to the complications such as the risk of arrhythmia.
• machine learning techniques have been used for Ees estimation, but these techniques have also struggled to achieve a desired level of versatility because of the dearth of training data.
• cardiac therapies particularly in Intensive Care Unit (ICU)/Critical Care Unit (CCU) settings, are conducted without the adequate knowledge of Ees.
• a clinician does not have a way of knowing how Ees is impacted by a particular drug or a combination of drugs. The clinician therefore will have to rely on experience and guesswork to make a mental estimate of the effect of the drug on Ees. Additionally, this lack of knowledge does not allow for a closed-loop hemodynamic control system, where an optimized combination of drugs could be automatically infused. In these situations where the organ as important as a human heart is involved, this lack of knowledge— notwithstanding the clinical expertise and experience—can be fatal for the patient. [0008] As such, a significant improvement in systems, methods, and devices to measure or Ees (and cardiac contractility in general) is therefore desired.
• a computer-implemented method may be provided.
• the method may include receiving, by a computing system, a pulmonary capillary wedge pressure and cardiac output for a human heart.
• the method may also include determining, by the computing system, a cardiac contractility for the human heart based on a left ventricular end- systolic elastance generated as an inverse function of a gradient of a relationship between the pulmonary capillary wedge pressure and the cardiac output, while avoiding singularities in the inverse function.
• the method may further include generating, by the computing system, an optimal combination of drugs to reach a target cardiac contractility from the determined cardiac contractility.
• a system may be provided.
• the system may include a non-transitory storage medium storing computer program instructions and a processor configured to execute the computer program instructions to cause operations.
• the operations may include receiving a pulmonary capillary wedge pressure and cardiac output for a human heart.
• the operations may further include determining a cardiac contractility for the human heart based on a left ventricular end-systolic elastance generated as an inverse function of a gradient of a relationship between the pulmonary capillary wedge pressure and the cardiac output, while avoiding singularities in the inverse function.
• the operations may also include generating an optimal combination of drugs to reach a target cardiac contractility from the determined cardiac contractility.
• a non-transitory storage medium storing computer program instructions may be provided.
• the computer program instructions that when executed may cause a computing system to perform operations.
• the operations may include receiving a pulmonary capillary wedge pressure and cardiac output for a human heart.
• the operations may further include determining a cardiac contractility for the human heart based on a left ventricular end-systolic elastance generated as an inverse function of a gradient of a relationship between the pulmonary capillary wedge pressure and the cardiac output, while avoiding singularities in the inverse function.
• the operations may also include generating an optimal combination of drugs to reach a target cardiac contractility from the determined cardiac contractility.
• FIG. 1 depicts an example computing environment for monitoring cardiac contractility during cardiac treatments, according to example embodiments of this disclosure.
• FIG.2 depicts an example analytical model, according to example embodiments of this disclosure.
• FIG. 3 depicts a flow diagram of an example method, based on the example embodiments of this disclosure.
• FIG 4 depicts example charts visualizing comparison between the different methods, according to example embodiments of this disclosure.
• FIG.5 depicts example charts showing modulation of hemodynamics, based on the example embodiments of this disclosure. 3 1608025632.3 Attorney Docket No.390351-100201
• FIG.6 depicts example charts showing modulation of hemodynamics, based on the example embodiments of this disclosure.
• FIG.7 shows a block diagram of an example computing device that implements various features and processes, according to example embodiments of this disclosure.
• DESCRIPTION [00019] Embodiments disclosed herein generally related to a system and method of estimating cardiac contractility using readily available clinical data. As discussed above, conventional methods for estimating cardiac contractility typically require continuous measurement of left ventricular pressure and volume, which is difficult to achieve in a clinical setting. The one or more techniques disclosed herein improve upon conventional methods by utilizing pulmonary capillary wedge pressure and cardiac output, which are regularly measured metrics in clinical settings using pulmonary artery catheterization.
• such an approach may utilize only a single point of left ventricular end-diastolic pressure and volume—non-invasively estimated using echocardiography—to extrapolate a left ventricular end-diastolic pressure-volume relationship curve.
• This curve may be augmented by physiological constraints and optimized parameters for singularity avoidance, and used with the pulmonary capillary wedge pressure and cardiac output to estimate left ventricular end- systolic elastance (Ees), which is an index of cardiac contractility. Therefore, the clinical feasibility and accuracy of cardiac monitoring and therapy that use the disclosed embodiments is significantly improved in comparison to the conventional systems.
• FIG. 1 depicts an example computing environment 100 for monitoring cardiac contractility during cardiac treatments, according to example embodiments of this disclosure.
• the example computing environment 100 may be configured to estimate Ees as an index of cardiac contractility.
• the computing environment 100 may be based on a client-server model, with a server 102 connected to multiple clients 106a-106d (commonly referred to as a client 106 or collectively referred to as clients 106) and a cardiac monitoring system 122 (which too may be considered a client to the server 102) via a network 104.
• clients 106a-106d commonly referred to as a client 106 or collectively referred to as clients 106
• a cardiac monitoring system 122 which too may be considered a client to the server 102
• the client-server model is just for illustration and 4 1608025632.3 Attorney Docket No.390351-100201 ease of explanation and should not be considered limiting. Therefore, any type of computing environment performing the functionality disclosed herein should be considered within the scope of this disclosure.
• the computing environment 100 may be generally in a clinical setting to monitor cardiac contractility—particularly Ees—for cardiac patients such as patients with acute heart failure.
• the server 102 may store different software modules 108 that may be accessed by the clients 106 and cardiac monitoring system 122 using the network 104.
• the clients 106 themselves may have standalone applications (not shown) to access the software modules 108.
• the clients 106 may access the software modules 108 through a browser application, for example.
• the cardiac monitoring system 122 may access the software modules 108 through any type of firmware and/or software installed in the cardiac monitoring system 122.
• the cardiac monitoring system 122 may communicate with the server 102 using one or more of the clients 106.
• the hardware of the server 102 storing the software modules 108 may include any kind of computing device.
• the server 102 may include any kind of computing device, including but not limited to a server computer, a desktop computer, a laptop computer, a tablet computer, a smartphone.
• the server 102 may not necessarily be at a single location and may be realized by a network of computers.
• the server 102 may not necessarily be co-located within the clinical setting itself, and may be hosted by a third party cloud computing provider.
• the network 104 may include any combination of one or more packet switching networks (e.g., an IP based network) and one or more circuit switching networks (e.g., a cellular telephony network).
• packet switching networks e.g., an IP based network
• circuit switching networks e.g., a cellular telephony network.
• Some non-limiting examples of the network 104 include a local area network, a metropolitan area network, a wide area network such as the Internet, etc.
• non-limiting examples of the clients 106 may include a desktop terminal (e.g., desktop terminal 106a), a laptop computer (e.g., a laptop computer 106b), a tablet computer (e.g., a tablet computer 106c), a smartphone (e.g., a smartphone 106d), etc.
• a desktop terminal e.g., desktop terminal 106a
• a laptop computer e.g., a laptop computer 106b
• a tablet computer e.g., a tablet computer 106c
• smartphone e.g., a smartphone 106d
• Any type of computing device that allows an access to the server 102 through the network 104 should be considered within the scope of this disclosure.
• the functionality 5 1608025632.3 Attorney Docket No.390351-100201 described within this disclosure can be distributed in any fashion, i.e., functionality of the server 102 may be performed by one or more clients 106 and vice versa.
• the cardiac monitoring system 122 may include any combination of diagnostic and therapeutical devices used for cardiac patients.
• the cardiac monitoring system 122 may include cardiac monitors, Holter ECG monitors, cardiac echo devices, cardiac nuclear stress test devices, cardiac catheters, cardiac drug infusing devices, external pacemakers, and/or any other type of cardiac diagnostic and therapeutic devices.
• cardiac monitors Holter ECG monitors
• cardiac echo devices cardiac nuclear stress test devices
• cardiac catheters cardiac drug infusing devices
• external pacemakers and/or any other type of cardiac diagnostic and therapeutic devices.
• a single cardiac monitoring system 122 is shown, any number of monitoring systems is to be considered within the scope of this disclosure.
• one monitoring system 122 may not necessarily localized within a single device and may include a combination of devices (and constituent software/firmware) distributed throughout the clinical setting.
• the functionality between the monitoring system 122 and the server 102 may be interchangeable, for example, some of the software modules 108 implemented in the server 102 may be implemented by the monitoring system 122.
• the cardiac monitoring system 122 may implement a closed-loop hemodynamic control system that controls the amount of drug infused in response to monitored cardiac contractility (e.g., Ees).
• the server 102 may include multiple software modules.
• FIG.1 shows some non-limiting example software modules: a cardiac data input module 110, a cardiac contractility calculation module 112, a closed-loop hemodynamic control module 114, an optimal dosage calculation module 116, a model development and simulation module 118, and an experimental data ingestion module 120.
• the cardiac data input module 110 may receive cardiac data from the clients 106 and the cardiac monitoring system 122.
• the received cardiac data may include any kind of cardiac data measured or estimated in the clinical setting.
• the cardiac data may include left ventricular end-diastolic pressure and volume that may be generated by echocardiography.
• the cardiac data may further include pulmonary capillary wedge pressure and cardiac output measured through pulmonary artery catheterization.
• the received cardiac data may include current cardiovascular metrics for a patient and target cardiovascular metrics.
• the cardiac data input module 110 may support batch processing, where individual cardiac data are batched (e.g., buffered or stored), and the processing may be performed together for the batched data (e.g., during off-peak hours for the server 102). Therefore, the cardiac data input module 110 may manage the receipt of cardiac data from the clients 106 and the cardiac monitoring system 122 for any type of processing.
• the cardiac contractility calculation module 112 may calculate cardiac contractility using the analytical models disclosed throughout this disclosure.
• the cardiac contractility module may calculate Ees as an index of cardiac contractility. Such Ees calculation may be based on left ventricular end-diastolic pressure and volume measured non-invasively through echocardiography.
• the closed-loop hemodynamic control module 114 may implement an automatic infusion of optimal combination of drugs (e.g., calculated by the optimal dosage calculation module 116). That is, the closed-loop hemodynamic control module 114 may regularly monitor E es calculated by the cardiac contractility module, and based on this monitoring, transmit instructions to the cardiac monitoring system 122 to infuse the optimal combination of drugs. This automatic infusion may not necessarily require clinician intervention to keep a patient within a desired range of cardiac contractility.
• the model development and simulation module 118 may provide an interface, e.g., a graphical user interface, for the model developer to define one or more analytical models. Furthermore, the model development and simulation module 118 may allow the model developer to upload and/or port a pre-defined analytical module to the server 102. The model development and simulation module 118 may therefore generally provide any kind of computing environment support to develop the analytical models described throughout this disclosure. [00031] The model development and simulation module 118 may further allow the model developer to simulate the analytical models. The simulations may include, for example, numerical simulation, where collected numerical data may be used on the analytical models to observe the outputs. The simulations may produce, for example, numerical data, graphical data, and/or any other type of output data.
• the model development and simulation module 118 may generally allow for validations of the analytical models based on these simulations (e.g., to determine whether the analytical models perform as desired with simulated scenarios).
• the experimental data ingestion module 120 may ingest experimental data used for model development.
• the experimental data may include measured cardiovascular parameters and/or metrics of animals.
• Such experimental data may be used by the model development and simulation module 118 to simulate the analytical models.
• Other experimental data may include a detailed experimental data containing both inputs and outputs, and can be used to compare the real-world results with the simulated results.
• the experimental data may include a continuous stream of data as the patients are being treated in clinical settings, which may be used to continuously modify and/or refine the analytical models.
• the experimental data ingestion module 120 may receive any kind of real-world numerical data that may be used to develop, refine, and/or modify the analytical modules disclosed throughout this disclosure.
• clinicians may use the software modules 108 within the server 102 in the therapy of patients such as acute heart failure patients.
• a clinician may use the cardiac monitoring system 122 to non-invasively measure a single point of left ventricular end-diastolic volume and pressure using echocardiography techniques. This measurement may either be entered by the clinician to a client 106 to be transmitted to the server 102 and/or directly transmitted by the cardiac monitoring system 122 to the server 102.
• the clinician may further measure pulmonary capillary wedge pressure and cardiac output using a pulmonary artery 8 1608025632.3 Attorney Docket No.390351-100201 catheterization (which may be functionality supported by the cardiac monitoring system 122). This measurement too may be transmitted to the server 102 through a client 106 and/or the cardiac monitoring system 122.
• the cardiac data input module 110 may receive these measurements, perform pre-processing as needed, and provide them to the cardiac contractility calculation module 112.
• the cardiac contractility calculation module 112 may use these measurements to estimate the cardiac contractility (e.g., E es ). This estimated cardiac contractility may be used by the optimal dosage calculation module 116 to provide a recommended dosage to the clinician (e.g., on a client 106 and/or on the cardiac monitoring system 122).
• FIG. 2 depicts an example analytical model 200, according to example embodiments of this disclosure.
• the example analytical model 200 may be used by the software modules 108 described in FIG.1.
• the model development and simulation module 118 may be used to define (and/or port) and simulate the analytical model 200
• the experimental data ingestion module 120 may be used to receive experimental data to validate, modify, and/or refine the analytical model 200.
• the cardiac data input module 110 may receive data to be used by the analytical model 200, the cardiac contractility calculation may calculate cardiac contractility (e.g., E es ) based on the received cardiac data, the optimal dosage calculation module 116 may use the analytical model 200 to calculate an optimal dosage, and the closed-loop hemodynamic control module 114 may provide instructions to the cardiac monitoring system 122 to automatically infuse the calculated dosage.
• the analytical model 200 is just an example and should not be considered limiting: analytical models with additional, alternative, or fewer number of steps, and/or components should be considered within the scope of this disclosure.
• the analytical model 200 is based on a first chart 202 that shows a pressure volume (PLV - VLV) relationship in the left ventricle and a second chart 204 that shows a relationship between cardiac output (CO) and pressure in the left auricle (P LA ).
• the first chart 202 shows multiple pressure volume loops 206a- 206d (commonly referred to as a pressure volume loop 206 and collectively referred to as pressure volume loops 206).
• Ped measured pressure ventricle
• Ved measured in ml
• Vd measured in ml
• ⁇ ⁇ ⁇ ⁇ l og( ⁇ ⁇ ⁇ + ⁇ ⁇ ⁇ ) ⁇ log ⁇ ⁇ ⁇ + ⁇ ⁇ ⁇ ( ⁇ ⁇ ⁇ 0) (8) provided that CO and P LA are measurable (e.g., as shown in chart 204) and the constant parameters for the ESPVR model represented by equation (1) and the EDPVR model represented by equation (4) are given.
• ⁇ ( ⁇ ) ⁇ ⁇ ⁇ ( exp ⁇ ⁇ ⁇ ( ⁇ 0 ⁇ ⁇ ⁇ ) ⁇ ⁇ 1 ) (11)
• ⁇ [ ⁇ 0 , ⁇ 0 , ⁇ ⁇ , ⁇ 0 ] is the vector of constant parameters of both EDPVR and ESPVR be understood that ⁇ ( ⁇ ) can be determined by using only the ESPVR and EDPVR parameters and that ⁇ ( ⁇ ) corresponds to the P LA intercept of the Frank-Starling curve of equation (6).
• the above- described parameters can be optimized to avoid the singularities.
• the optimization problem can be formulated as a constrained nonlinear least squares problem as follows: minimize (16) ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ⁇ ( ⁇ ⁇ ⁇ ; ⁇ ) 2 + ⁇ ⁇ ⁇ ⁇ ⁇ ( ⁇ ) ⁇ 2 1608025632.3
• yedpvr is the dataset of end-diastolic points (VLV, PLV), fedpvr (Ved; ⁇ ) is the EDP
• FIG.3 depicts a flow diagram of an example method 300, based on the example embodiments of this disclosure.
• the example method 300 may be performed by any combination of components of the computing environment 100 shown in FIG. 1, using any portion of the analytical model 200 shown in FIG. 2. It should be understood that the steps of the method 300 are just examples and should not be considered limiting.
• the method 300 may begin at step 302.
• server 102 may receive an input of cardiac data.
• a desktop terminal in a hospital terminal may be used by a clinician to enter the cardiac data.
• the clinician may enter the cardiac data on a smartphone or a tablet computer.
• the cardiac data may be sent by a cardiac monitoring system.
• the cardiac data may include, for example, single point of left ventricular end-diastolic volume and pressure (non-invasively measured through echocardiography), pulmonary capillary wedge pressure, and cardiac output.
• the server 102 may calculate cardiac contractility based on the received input cardiac data. For example, the server 102 may use the single point of left ventricular end-diastolic volume to extrapolate an EDPVR curve to generate more samples from the single point (e.g., by using equation 16 associated with the analytical model 200). The server 102 may then impose physiological constraints and singularity avoidance (as per the analytical model 200) to update the EDPVR parameters. The server 102 may then estimate Ees (as an index of cardiac contractility) based on the received pulmonary capillary wedge pressure 13 1608025632.3 Attorney Docket No.390351-100201 and cardiac output.
• Ees an index of cardiac contractility
• the server 102 may consider the pulmonary capillary wedge pressure as left atrial pressure, and also by using the pulmonary artery catheter to estimate cardiac output. [00054] At step 306, the server 102 may calculate an optimal drug combination based on the cardiac contractility. For example, the optimal drug combination calculation may be based on a desired cardiac contractility vis-à-vis the calculated cardiac contractility. [00055] In some embodiments, method 300 may include step 308a. At step 308a, the server 102 may output the optimal drug combination (e.g., at the requesting device) to assist clinical decision making. That is, the clinician can rely on the tested and simulated models to aid the decision making and rely less on guesswork.
• the optimal drug combination e.g., at the requesting device
• method 300 may include step 308b.
• the server 102 may use the optimal drug combination for closed-loop hemodynamic system. That is, the server 102 may send instructions to the cardiac monitoring system 122 to automatically infuse the optimal drug combination.
• server 102 may perform both of the steps 308a, 308b.
• the disclosed analytical model 200 have been evaluated experimentally and through simulation. In an animal experiment, a dog was anesthetized and its bilateral carotid bioreceptors and vagal trunk were denervated.
• a thoracotomy was conducted, after which the dog was connected to a system that measures arterial pressure (AP) from right femoral artery, cardiac output (CO) via ultrasonic flow meter around ascending aorta, left atrial pressure (PLA) and right atrial pressure (P RA ) from fluid filled catheters, left ventricular pressure (P LV ) from micromanometer, and hear rate (HR) from an electrocardiogram (ECG) sensor.
• AP arterial pressure
• CO cardiac output
• PPA left atrial pressure
• P RA right atrial pressure
• HR left ventricular pressure
• ECG electrocardiogram
• Two pairs of sono-micrometry crystals were placed in the left ventricle to estimate left ventricular volume (VLV) using a method based on modified ellipsoid formula.
• IVCO inferior vena cava occlusion
• a drug library represents an effect of a combination of drugs on cardiovascular parameters.
• ⁇ [ ⁇ 1, ⁇ 2, ⁇ 3, ⁇ 4] ⁇ ⁇ R4, which includes the above-described drugs in the treatment of acute heart failure: DOB, NE, SNP, and DEX.
• the drug infusion u directly affects the cardiovascular parameters x based on drug pharmacology.
• cardiovascular parameter x for example Ees—multiple cardiovascular metrics such as MAP(t), CO(t), PLA(t) are modulated.
• the drug library B i.e., the input matrix
• the gains from each drug input ui to each cardiovascular parameter xi were identified by fitting a first order single-input single-output process model.
• the simulator modeled blood flow through the cardiovascular system by using establishing electrical analogs for fluid dynamics, representing vascular resistance as electrical resistors and compliance as electrical capacitors.
• the model further used a time-time varying elastance function for each heart chamber, with the valves at the exit of each chamber modeled with electrical diodes and electrical resistors.
• Each time-varying elastance function therefor depended upon the chamber specific parameters of the ESPVR and EDPVR; and on each cardiac cycle the function simulated contraction as a sinusoidal increase in elastance to a peak of that chamber’s Ees, flowed by a combined sinusoidal and exponential relaxation (indicating a decrease in elastance).
• Modified Windkessel vascular components may be used to represent systemic and pulmonary circulations, with each including a characteristic impedance along with resistance and capacitance distributed between the arterial, capillary, and venous portions of the circulation. Taken together, these cardiac and vascular components may allow the simulation of time-varying pressures and flows throughout the cardiovascular system, similar to the lumped parameter model. This model was simulated using MATLAB and Simulink computing software (version R2021b, The MathWorks, Inc.), which outputs P LA , P RA , CO, and MAP being simulated for different parameter values. The identified drug library may be used to modulate the cardiovascular parameters within this model and obtain hemodynamic simulation results under the relevant drug infusion scenarios.
• FIG. 4 depicts example charts 402-408 visualizing comparison between the different methods, according to example embodiments of this disclosure.
• the E es may further be validated by simulating hemodynamic changes (i.e., changes in the cardiovascular metrics).
• hemodynamic changes i.e., changes in the cardiovascular metrics
• it may be important to accurately reproduce hemodynamics behavior (i.e., changes in cardiovascular metrics) caused by the change in Ees following drug administration.
• a drug library e.g., matrix B
• the simulation may reproduce pharmacological effects to cardiovascular parameters x, which in turn modulate cardiovascular metrics.
• this simulation may consider two E es estimation methods: (i) E es by the inverse estimation with singularity avoidance and (ii) Ees by linear regression to the end- systolic points.
• FIG.5 depicts example charts 502-508 showing modulation of hemodynamics, based on the example embodiments of this disclosure.
• chart 502 shows metrics space ( ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ) simulated based on the analytical models of ESPVR disclosed herein and ESPVR derived by linear fitting, both compared to real-world animal experimental data for infusion of the drug Dobutamine.
• Chart 504 shows metrics space ( ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ) simulated based on the analytical models of ESPVR disclosed herein and ESPVR derived by linear fitting, both compared to real-world animal experimental data for infusion of the drug Norepinephrine.
• Chart 506 shows metrics space ( ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ) simulated based on the analytical models of ESPVR disclosed herein and ESPVR derived by linear fitting, both compared to real-world animal experimental data for infusion of the drug Sodium Nitroprusside.
• Chart 508 shows metrics space ( ⁇ ⁇ ⁇ ⁇ , ⁇ ⁇ ⁇ ) simulated based on the analytical models of ESPVR disclosed herein and ESPVR derived by linear fitting, both compared to real-world animal experimental data for infusion of the drug Dextran.
• FIG.6 depicts example charts 602-608 showing modulation of hemodynamics, based on the example embodiments of this disclosure.
• chart 602 shows metric space ⁇ ⁇ ⁇ ⁇ simulated based on the analytical models of ESPVR disclosed herein and ESPVR derived by linear fitting, both compared to real-world animal experimental data for infusion of the drug Dobutamine.
• Chart 604 shows metric space ⁇ ⁇ ⁇ ⁇ simulated based on the analytical models of ESPVR disclosed herein and ESPVR derived by linear fitting, both compared to real-world animal experimental data for infusion of the drug Norepinephrine.
• Chart 606 shows metric space ⁇ ⁇ ⁇ ⁇ simulated based on the analytical models of ESPVR disclosed herein and ESPVR derived by linear fitting, both compared to real-world animal experimental data for infusion of the drug Sodium Nitroprusside.
• Chart 608 shows metric space ⁇ ⁇ ⁇ ⁇ simulated based on the analytical models of ESPVR disclosed herein and ESPVR derived by linear fitting, both compared to real-world animal experimental data for infusion of the drug Dextran.
• Embodiments disclosed herein may therefore improve the robustness of E es estimation via decreased sensitivity to the nonlinearity of ESPVR.
• E es estimated by the analytical models disclosed herein may not substantially change after the drug administration, which Ees estimated by linear fitting may be affected by the nonlinearity of ESPVR.
• chart 508 in FIG. As further shown in chart 508 in FIG.
• FIG. 7 shows a block diagram of an example computing device 700 that implements various features and processes, according to example embodiments of this disclosure.
• computing device 700 may function as the server 102, the clients 106, the cardiac monitoring system 122, or a portion or combination thereof in some embodiments. Additionally, the computing device 700 may partially or wholly host and deploy analytical model 200. The computing device 700 may also perform one or more steps of the method 300.
• the computing device 700 is implemented on any electronic device that runs software applications derived from compiled instructions, including without limitation personal computers, servers, smart phones, media players, electronic tablets, game consoles, email devices, etc.
• the computing device 700 includes one or more processors 702, one or more input devices 704, one or more display devices 706, one or more network interfaces 708, and one or more computer-readable media 712. Each of these components is be coupled by a bus 710.
• Display device 706 includes any display technology, including but not limited to display devices using Liquid Crystal Display (LCD) or Light Emitting Diode (LED) 19 1608025632.3 Attorney Docket No.390351-100201 technology.
• LCD Liquid Crystal Display
• LED Light Emitting Diode
• Processor(s) 702 uses any processor technology, including but not limited to graphics processors and multi-core processors.
• Input device 704 includes any known input device technology, including but not limited to a keyboard (including a virtual keyboard), mouse, track ball, and touch-sensitive pad or display.
• Bus 710 includes any internal or external bus technology, including but not limited to ISA, EISA, PCI, PCI Express, USB, Serial ATA or FireWire.
• Computer-readable medium 712 includes any non-transitory computer readable medium that provides instructions to processor(s) 702 for execution, including without limitation, non-volatile storage media (e.g., optical disks, magnetic disks, flash drives, etc.), or volatile media (e.g., SDRAM, ROM, etc.).
• Computer-readable medium 712 includes various instructions 714 for implementing an operating system (e.g., Mac OS®, Windows®, Linux).
• the operating system may be multi-user, multiprocessing, multitasking, multithreading, real-time, and the like.
• the operating system performs basic tasks, including but not limited to: recognizing input from input device 704; sending output to display device 706; keeping track of files and directories on computer-readable medium 712; controlling peripheral devices (e.g., disk drives, printers, etc.) which can be controlled directly or through an I/O controller; and managing traffic on bus 710.
• Network communications instructions 716 establish and maintain network connections (e.g., software for implementing communication protocols, such as TCP/IP, HTTP, Ethernet, telephony, etc.).
• Cardiac contractility calculation instructions 718 includes instructions that implement the disclosed process for calculating cardiac contractility for clinical decision making and/or closed-loop hemodynamic control system, as described throughout this disclosure.
• Application(s) 720 may comprise an application that uses or implements the processes described herein and/or other processes. The processes may also be implemented in the operating system.
• the described features may be implemented in one or more computer programs that may be executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device.
• a computer program is a set of instructions that can be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result.
• a computer program may be written in any form of programming language (e.g., Objective-C, Java), including compiled or interpreted languages, and it may be deployed in any form, including as a stand-alone program or as a 20 1608025632.3 Attorney Docket No.390351-100201 module, component, subroutine, or other unit suitable for use in a computing environment. In one embodiment, this may include Python.
• the computer programs therefore are polyglots.
• Suitable processors for the execution of a program of instructions may include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors or cores, of any kind of computer.
• a processor may receive instructions and data from a read-only memory or a random access memory or both.
• the essential elements of a computer may include a processor for executing instructions and one or more memories for storing instructions and data.
• a computer may also include, or be operatively coupled to communicate with, one or more mass storage devices for storing data files; such devices include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks.
• Storage devices suitable for tangibly embodying computer program instructions and data may include all forms of non-volatile memory, including by way of example semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
• semiconductor memory devices such as EPROM, EEPROM, and flash memory devices
• magnetic disks such as internal hard disks and removable disks
• magneto-optical disks and CD-ROM and DVD-ROM disks.
• the processor and the memory may be supplemented by, or incorporated in, ASICs (application-specific integrated circuits).
• ASICs application-specific integrated circuits
• the features may be implemented on a computer having a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.
• a display device such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor for displaying information to the user and a keyboard and a pointing device such as a mouse or a trackball by which the user can provide input to the computer.
• the features may be implemented in a computer system that includes a back- end component, such as a data server, or that includes a middleware component, such as an application server or an Internet server, or that includes a front-end component, such as a client computer having a graphical user interface or an Internet browser, or any combination thereof.
• the components of the system may be connected by any form or medium of digital data communication such as a communication network.
• Examples of communication networks include, e.g., a telephone network, a LAN, a WAN, and the computers and networks forming the Internet.
• the computer system may include clients and servers.
• a client and server may generally be remote from each other and may typically interact through a network.
• the relationship of client and server may arise by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
• 21 1608025632.3 Attorney Docket No.390351-100201
• An API may define one or more parameters that are passed between a calling application and other software code (e.g., an operating system, library routine, function) that provides a service, that provides data, or that performs an operation or a computation.
• the API may be implemented as one or more calls in program code that send or receive one or more parameters through a parameter list or other structure based on a call convention defined in an API specification document.
• a parameter may be a constant, a key, a data structure, an object, an object class, a variable, a data type, a pointer, an array, a list, or another call.
• API calls and parameters may be implemented in any programming language.
• the programming language may define the vocabulary and calling convention that a programmer will employ to access functions supporting the API.
• an API call may report to an application the capabilities of a device running the application, such as input capability, output capability, processing capability, power capability, communications capability, etc.
• Additional examples of the presently described method and device embodiments are suggested according to the structures and techniques described herein. Other non-limiting examples may be configured to operate separately or can be combined in any permutation or combination with any one or more of the other examples provided above or throughout the present disclosure.

Landscapes

• Engineering & Computer Science (AREA)
• Health & Medical Sciences (AREA)
• Medical Informatics (AREA)
• Public Health (AREA)
• Epidemiology (AREA)
• Biomedical Technology (AREA)
• Primary Health Care (AREA)
• General Health & Medical Sciences (AREA)
• Data Mining & Analysis (AREA)
• Pathology (AREA)
• Databases & Information Systems (AREA)
• Chemical & Material Sciences (AREA)
• Bioinformatics & Cheminformatics (AREA)
• Medicinal Chemistry (AREA)
• Measuring Pulse, Heart Rate, Blood Pressure Or Blood Flow (AREA)

Applications Claiming Priority (2)

Publications (1)

Family

ID=92907506

Family Applications (1)

Country Status (2)

Family Cites Families (4)

• 2024
  • 2024-03-29 EP EP24782081.4A patent/EP4687647A2/de active Pending
  • 2024-03-29 WO PCT/US2024/022367 patent/WO2024206920A2/en not_active Ceased

Also Published As

Similar Documents

Legal Events