HEART FAILURE DIAGNOSIS TOOL AND METHOD USING SIGNAL TRACE ANALYSIS - Patent application

Abstract

The disclosed system and method provides improved outcomes for heart failure patients by automatically extracting features from vascular area traces, generating parameters indicative of cardiac health based on the extracted features, and providing a normalized congestion index for assessing the patient's condition. Examples include a diagnostic engine (102) receiving area traces from a trace generator (104) and communicating the patient's condition information via a user interface (116). The diagnostic engine may include a trace feature detector (106), a metrics generator (108), a boundary generator (110), an index generator (112), and a decision logic (114). The disclosed system may be executed using one or more processing devices or within a networked distributed processing system.

Description

[Technical field]

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 318,216, filed March 9, 2022, and entitled "Heart Failure Diagnostic Tools and Methods Using Signal Trace Analysis," the entire contents of which are incorporated by reference herein.

[0002] The present disclosure relates to the diagnosis of heart failure, and more particularly to tools and methods for facilitating the use of data generated by heart failure-related sensors to improve patient outcomes. [Background technology]

[0003] Hemodynamic congestion is currently commonly measured using catheter-based measurements of right atrial pressure (RAP) and pulmonary capillary wedge pressure (PCWP) filling pressure. However, these pressures have a narrow range relative to the potential measurement error, ranging from 2 to 6 mmHg (RAP) and 4 to 12 mmHg (PCWP), making it difficult to capture the associated pressure changes using common pressure-sensing detectors such as Swan-Ganz catheters and other implantable pressure sensors, whose limits of accuracy may generally be in the range of approximately ±5 mmHg.

[0004] Applicant has previously developed and disclosed various sensors that determine a patient's fluid status based on direct measurements of vascular dimensions, which are indicative of the vessel's cross-sectional area and its geometry, such as vessel expansion or contraction. Measurements of the vessels, particularly the inferior vena cava (IVC), may relate more directly to the patient's circulatory volume and hemodynamic status. Thus, these sensor measurements may be used to estimate the patient's circulatory volume and hemodynamic status. In particular, these sensors may be used to determine whether the patient has too much or too little circulatory volume, whether the circulatory volume is increasing or decreasing, and what treatments, such as diuretics or vasodilators, should be prescribed.

[0005] The new devices developed and disclosed by the applicant include external ultrasound devices and implantable sensors that can be placed for long periods of time and are suitable for monitoring patients with chronic diseases. Examples of such implantable wireless sensors and external ultrasound devices are disclosed, for example, in U.S. Patent Application No. 15 / 549,042, filed August 4, 2017, entitled "Implantable Device and Related Method for Heart Failure Monitoring" (U.S. Patent No. 10,905,393, granted February 2, 2021), and U.S. Patent Application No. 16 / 177,183, filed October 31, 2018, entitled "Wireless Vascular Monitoring Implant" (U.S. Patent No. 10,806,352, granted October 20, 2020), each of which is incorporated herein in its entirety. In other clinical situations, such as short-term acute status monitoring and hospital care, vascular dimension sensors for direct fluid status determination and monitoring may be catheter-based. Examples of such catheter-based sensors are disclosed, for example, in U.S. patent application Ser. No. 15 / 750,100, filed February 2, 2018, entitled "Devices and Methods for Measuring Vena Cava Dimensions, Pressure, and Oxygen Saturation" (Patent Document 3: U.S. Patent No. 11,039,813, issued June 22, 2021), the entire contents of which are incorporated herein by reference.

[0006] The applicant has also developed and disclosed novel diagnostic and treatment systems and methods based on the use of the aforementioned sensor devices, some of which are disclosed in the aforementioned patent applications and further in U.S. Patent No. 11,564,596 (Patent Document 4), entitled "System and Method for Patient Fluid Management," issued on January 31, 2023, and U.S. Patent Publication No. US2021 / 0244381A1 (Patent Document 5), entitled "Patient Fluid Management System and Method Employing Integrated Fluid Status Sensing," published on August 12, 2021, each of which is incorporated by reference in its entirety into this specification. [Prior art documents] [Patent documents]

[0007] [Patent Document 1] U.S. Pat. No. 1,090,5393 [Patent Document 2] U.S. Pat. No. 10,806,352 [Patent Document 3] U.S. Pat. No. 1,103,9813 [Patent Document 4] U.S. Pat. No. 1,564,596 [Patent Document 5] US Patent Application Publication No. 2021 / 0244381 Summary of the Invention [Problem to be solved by the invention]

[0008] Despite the aforementioned advances, challenges remain regarding the clinical interpretation of the signals generated by the various vascular area sensing technologies and, in some cases, the new data sets they generate.

[0009] One challenge is to calibrate measurements of vascular volume-based parameters resulting from intra- and inter-individual variability due to heterogeneity of vascular geometry, and generate comparable quantitative output metrics indicative of right atrial filling pressure or congestion status. For example, the area of ​​the inferior vena cava varies from one individual to another and from one location along the inferior vena cava to another, making comparison of absolute area measurements difficult across patient groups and potentially hindering clinical use of the generated data. Although publicly available data normalization algorithms can be applied to address this limitation, it is highly likely that arbitrary normalization of any feature will result in normal ranges being bracketed by unusual and unintuitive value thresholds. That is, normalized variables are expressed in units (possibly dimensionless) and associated thresholds are unfamiliar to clinicians and not part of standard practice or guidelines. Such unconventional numbering poses challenges for physicians and patients, especially as methods evolve, diagnostic algorithms become more complex and refined, and patients become increasingly relevant consumers of data.

[0010] Public clinical acceptance of new data types can also be a challenge. Physiological parameters that have been well known for many years have a well-understood range (e.g., blood pressure, temperature, respiratory rate). These develop over time and become domain-specific knowledge and are included in clinical guidelines, etc. To promote acceptance and usage of new advantageous systems and datasets, correlations between the new signals and known physiological parameters of the datasets need to be developed to facilitate their use by clinicians.

[0011] With multiple discrete inputs to diagnostic and treatment algorithms, it is difficult to set actionable thresholds without overly complicating prescriptions. Thus, there is a need to reduce the burden of data review on users (patients or healthcare providers) as new data sets and parameters are introduced. Challenges faced by users include defining action thresholds and providing reliable inputs to inform drug titration decisions and monitor patient medication adherence.

[0012] Various embodiments disclosed herein address these challenges and present solutions designed to improve the speed and accuracy of heart failure diagnostic and treatment decisions, thereby improving patient outcomes and reducing the incidence and costs of hospitalizations. [Means for solving the problem]

[0013] In one embodiment, the present disclosure relates to an automated heart failure diagnosis device. The device includes a trace feature detector that identifies selected features of received periodic vascular area traces representative of changes in a patient's fluid status over time and at least one of magnitude and timing of the identified features, where the selected features include one or more of interval time per respiratory cycle, area magnitude of respiratory modulation, interval time per cardiac cycle, area magnitude of cardiac modulation, dominant cardiac peak, second cardiac peak, respiratory related area reduction, maneuver type, and maximum and minimum area associated with the identified maneuver. A metrics generator generates cardiac function related parameters for each area trace based on the identified features, magnitude, and timing. The cardiac function related parameters include one or more of maximum vascular area (Amax), minimum vascular area (Amin), mean vascular area (Amean), heart rate (HR), respiratory rate (RR), collapsibility index (CI), collapse (C), and cardiac output (CO). The method includes a boundary generator that uses the generated cardiac function-related parameters to generate at least a patient's lower vascular area boundary (LB) or a patient's upper vascular area boundary (UB), and an index generator that sets a congestion index for the patient based on one or more of the generated cardiac function-related parameters and at least one of the patient's lower vascular area boundary (LB) or upper vascular area boundary (UB), wherein the congestion index indicates the patient's fluid status on a normalized scale for each tracing period.

[0014] In another embodiment, the present disclosure relates to a system for automatically determining a patient's fluid status using periodic vascular area traces, the system including: a trace feature detector for identifying selected features of the vascular area traces and at least one of a magnitude and a timing of the identified features of the vascular area traces; a metrics generator for generating cardiac function-related parameters for each area trace based on the identified magnitude and timing; the cardiac function-related parameters including at least a maximum vascular area (Amax) and a minimum vascular area (Amin); and an index generator for generating a congestion index for the patient based on at least the maximum vascular area (Amax), the minimum vascular area (Amin) and at least one of a lower vascular area boundary (LB) or an upper vascular area boundary (UB), the congestion index indicating the patient's fluid status on a normalized scale for each trace period.

[0015] In yet another embodiment, the present disclosure relates to a computer-based method, comprising: receiving a static respiratory vascular area trace of a patient in at least one processing device; receiving in the processing device patient-specific information including at least a patient weight and a patient age; filtering in the processing device the static respiratory vascular area trace to identify component signals including at least a respiratory trace, a cardiac trace, and an average trace; extracting in the processing device magnitude and timing features from the trace corresponding to at least one or more of area maximum, area minimum, collapse, respiratory collapse, cardiac collapse, heart rate, and respiratory rate; generating in the processing device a cardiac function-related parameter using executable program instructions defining the cardiac function-related parameter based on the extracted magnitude and timing features, the cardiac function-related parameter including one or more of respiratory rate, cardiac output, heart rate, collapsibility index, collapse, maximum vessel area, minimum vessel area, and average vessel area; generating a congestion index for the patient based on one or more of the magnitude features and the cardiac function-related parameter; and applying weights to the congestion index, the cardiac function-related parameter, and the patient-specific information using a machine learning based model to return a hospitalization likelihood score for the patient.

[0016] In yet another embodiment, the present disclosure relates to a method for automatically determining a patient's fluid status using periodic vascular area traces, the method including receiving the vascular area traces, identifying selected features of the vascular area traces and at least one of a magnitude and timing of the identified features, generating cardiac function related parameters for each area trace based on the identified magnitude and timing, the cardiac function related parameters including a measured vascular area and a vascular area boundary, generating a congestion index for the patient representing a relationship between the measured vascular area determined for the area traces and the vascular area boundary of the patient, the congestion index being indicative of the patient's fluid status on a normalized scale for each trace period. [Brief description of the drawings]

[0017] [Figure 1] FIG. 1 is a high-level schematic diagram of the system involved in this disclosure. [Diagram 2] Figure 2 is an example of an IVC area trace, including a detailed view of a portion of the trace where some key trace features are identified. [Diagram 3] FIG. 3 is a block diagram of an embodiment of an overall system according to the present disclosure. [Figure 4] FIG. 4 is a block diagram of an embodiment of a trace generator according to the present disclosure. [Diagram 5] FIG. 5 is a block diagram of an embodiment of a feature detector according to the present disclosure. [Figure 6] FIG. 6 is a series of area trace plots showing the area response to various patient maneuvers. [Figure 6A] FIG. 6A is an enlarged detail of the area trace of the supine breath-hold maneuver shown in FIG. [Figure 7] FIG. 7 is a block diagram of an embodiment of a metrics generator according to the present disclosure. [Figure 7A] FIG. 7A is a block diagram illustrating an embodiment of components of a metrics generator for extracting respiration rate from area traces. [Figure 7B]FIG. 7B includes an example spectrogram generated from the area trace and illustrates different components of a metrics generator in an alternative embodiment for extracting heart rate and respiration rate from the area trace. [Figure 7C] FIG. 7C is an area trace illustrating another component of a metrics generator in an alternative embodiment for determining characteristics of the area trace. [Figure 7D] FIG. 7D is an area trace illustrating components of a metrics generator in an alternative embodiment for determining the collapsibility index. [Figure 8] FIG. 8 is a block diagram of an embodiment of a boundary generator according to the present disclosure. [Figure 9] FIG. 9 shows area trace plots of normal breathing and an inspiration breath-hold maneuver, illustrating an example of using the maneuver to identify an upper boundary. [Figure 10] FIG. 10 is a block diagram of an embodiment of an exponent generator according to the present disclosure. [Figure 11] FIG. 11 is a block diagram of an embodiment of decision logic according to the present disclosure. [Figure 12] FIG. 12 is a block diagram illustrating an embodiment of an interface device according to the present disclosure. [Figure 13] FIG. 13 is a flow diagram illustrating an embodiment of an overall system flow according to the present disclosure. [Figure 14] FIG. 14 is a block diagram illustrating components of an exemplary computing device. [Figure 15] FIG. 15 illustrates an example of derivation of the IVC axis based on area and collapse parameters according to embodiments disclosed herein. [Figure 16] FIG. 16 shows an example of estimation of venous return or cardiac output based on changes in vessel area according to further embodiments disclosed herein. [Figure 17]1 shows example signal traces used to determine cardiac output in accordance with an embodiment; trace (A) is a measured area trace, trace (b) is a filtered respiratory component trace, and trace (c) is a filtered cardiac component trace. [Figure 18] FIG. 18 is a flow diagram illustrating another alternative embodiment for estimating cardiac output based on sensor data. [Figure 19] 13A-13C show further examples of signal traces used to determine cardiac output in accordance with an embodiment, where trace (A) is a measured area trace, trace (b) is a simulated respiratory component trace, and trace (c) is a simulated cardiac component trace. [Figure 20] 20A-D show an example of the use of systemic vascular resistance based on sensor data and blood pressure data showing trends as a function of days in a heart failure patient experiencing symptoms in accordance with embodiments disclosed herein, where FIG. 20A shows SVR, FIG. 20B shows IVC area average, FIG. 20C shows respiratory rate, and FIG. 20D shows daily diuretic dosage. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0018] For the purpose of illustrating the invention, the drawings show aspects of one or more embodiments of the invention, it being understood, however, that the invention is not limited to the precise arrangements and instrumentalities shown in the drawings.

[0019] FIG. 1 illustrates at a high level a system 10 for receiving and analyzing hemodynamic sensor traces to aid in more accurate diagnosis and provision of improved treatment of heart-related diseases, particularly in heart failure patients. In general, a system according to embodiments described herein includes a sensor subsystem that generates signals representative of a patient's hemodynamic function, a data analysis subsystem that receives signal data from the sensor subsystem and processes the received data to automatically generate diagnostic and treatment recommendations, and an interface subsystem that allows patients and healthcare providers to interact with the system. The system 10 shown in FIG. 1 illustrates one such embodiment, including an implanted sensor 12 and a patient-worn processing device 14 that receives raw sensor signals and provides initial signal processing. The processing device 14 communicates with another processing platform 16 via a wireless communication link 18. Between the processing device 14 and the processing platform 16, the system 10 reads and interprets cardiac health information contained in the sensor signals to provide diagnostic and treatment recommendations based on the extracted information. Data communication can optionally be facilitated via the patient's personal device 20, such as a phone or tablet, which also serves as an input / output device for the patient, as described further herein. An optional healthcare provider device 22 is also provided to facilitate healthcare provider interaction with the patient and the system, as further described herein.

[0020] The sensor 12 may be comprised of an external sensor system or an implantable sensor system. Examples of the sensor 12 include a vessel dimension sensor, such as an IVC area or diameter sensor, and a vessel pressure sensor. With respect to the vessel dimension sensor, a number of different sensor types may be used to generate the area trace signal, including, for example, an implantable variable inductance coil, and an implantable or external ultrasound device. In one particular implementation, the sensor 12 is an implantable wireless resonant circuit sensor, and the processing unit 14 includes an embedded belt antenna, such as described in USP 10,806,352. Other sensor types, such as implantable or external ultrasound, and implantable resistance-based sensors, may be used as described in the aforementioned incorporated patents and published applications.

[0021] The communication link 18 may be wired, wireless, or a combination thereof, based on the particular configuration of the system according to the present disclosure. One skilled in the art can configure an appropriate data transmission protocol for the communication link 18 selected from among many available standards. The communication link 18 is preferably a bidirectional communication link. For example, a personal area network (PAN) connection such as Bluetooth can connect the sensor processing device 14 to the patient's personal device 20. In some embodiments, the personal device 20 can include one or more software applications for performing signal processing functions on the sensor signals. In other embodiments, the personal device 20 functions in this system only as an edge device to facilitate communication with the processing platform (16) configured as a cloud platform, with the communication being via a cellular data link. The communication links 18 between the different system platforms and components may also include, for example, an Internet connection to provide data transfer between the cloud platform, including the processing platform 16, and the healthcare provider device 22. In some embodiments, all or part of the functionality of the processing device 14 may also be performed as a cloud-based computing device.

[0022] An example of an IVC area signal trace generated by the system 10 is shown in FIG. 2. In general, an area trace as used herein refers to a signal indicative of vascular area as a function of time over a particular discrete time period corresponding to the reading of the trace, and includes data representative of cardiac and respiratory function, etc. A processing platform 16, such as a diagnostic engine 102, described below, interprets features of the area trace to extract data therefrom. Several features of the area trace are identified in the enlarged boxed portion of FIG. 2. As shown therein, feature (A) represents the interval time per respiratory cycle (ti,resp). Feature (b) represents the area magnitude of the respiratory modulation. Feature (c) represents the interval time per cardiac cycle (ti,card). Feature (d) represents the area magnitude of the cardiac modulation in the IVC. Feature (e) represents the major cardiac peak. Feature (f) represents the second cardiac peak in the same cardiac cycle as the previous peak (e). Feature (g) represents a respiration-related area decrease in the IVC.

[0023] Based on the teachings of the present disclosure, one skilled in the art can derive many different ways to configure and execute the system 10 of FIG. 1. One exemplary embodiment is illustrated as system 100 in FIG. 3. As shown therein, the sensor subsystem of the system 100 is composed of a data analysis subsystem including an area trace generator 104, a diagnostic engine 102 including modules such as a feature detector 106, a metrics generator 108, a boundary generator 110, an index generator 112, and a decision logic 114, and an interface subsystem including one or more interface devices 116 that facilitate user interaction with the system, such as uploading patient-specific data and receiving reports and notifications regarding the patient's cardiac health. The diagnostic engine 102 can also communicate with one or more databases 118 and receive additional patient-related information as external input from other patient sensors 120.

[0024] The trace generator 104 is a combination of hardware and processing equipment consisting of a data acquisition device 200 and a signal processing device 202, as shown in FIG. 4. The data acquisition device 200 can include one or more of the sensors 12 described above. The signal processing device 202 is a signal amplifier / processor configured to receive raw data signals from the data acquisition device 200 and generate readable area trace signals suitable for communication and further processing within the diagnostic engine 102. An example of a signal processing device is shown in FIG. 4 of incorporated USP 10,806,352. In other examples, the signal processing device 202 can include a software app running on the patient's personal device or a cloud platform. Examples of area traces generated by the signal processing device 202 for communication with the feature detector 106 include a normal respiration trace 204 and a maneuver trace 206.

[0025] The feature detector 106 is a device, such as a circuit, software, or combination thereof, that extracts relevant data from the area trace signal. The extracted data typically includes the magnitude and timing of selected features identified in the area trace throughout the reporting period (shown as the 60 second trace in FIG. 2): interval time per respiratory cycle, area magnitude of respiratory modulation, interval time per cardiac cycle, area magnitude of cardiac modulation, dominant cardiac peak, second cardiac peak, and respiration-related area decline. As shown in FIG. 5, functional components for this purpose are commonly understood and configurable by those skilled in the art and may include an input signal integrity check, envelope detection 302, region of interest (ROI) detection 304, peak detection 306, and frequency analyzer 308. In some embodiments, the feature detector 106 may be an artificial intelligence-driven pattern recognizer 310. The pattern recognizer 310 employs machine learning. Pattern analysis techniques are used to identify specific patterns within the area traces, which may be relevant for normalization and diagnostic and treatment decisions, as described in more detail below.

[0026] In one embodiment, the pattern recognizer 310 compares the input area trace signal to known area trace patterns to determine whether the input area trace reflects features such as signal responses to patient maneuvers. As used herein, a "maneuver" refers to a physical action that the patient performs, either spontaneously or in response to instructions, that stimulates a discernible variation in IVC area. Several example area traces for various patient maneuvers are shown in FIG. 6, including supine: quiet breathing, sniffing, supine: PLR (passive leg raising), supine: breath-hold, sitting, and sitting to stand. A close-up of the area trace pattern for supine breath-hold is shown in FIG. 6A. The area trace patterns representing different maneuvers are stored, such as in the database 118 (FIG. 3), and accessed by the pattern recognizer 310. In one embodiment, this was achieved by converting the trace signal into a collection of words and applying a Boss of SFA Symbols (BOSS) model. The model was then trained to detect features related to the maneuvers from such a collection of words to classify the presence or absence of a maneuver with an accuracy of 80% or higher. Knowledge of the type of trace pattern is utilized by the boundary generator 110, as described further below. In another embodiment, the pattern recognizer 310 can be used to identify features within the area trace signal that have been shown to predict clinical occurrences such as atrial fibrillation and tricuspid regurgitation.

[0027] The feature detector 106 can also perform a data integrity check. Features of the area trace signal can be used to verify whether the system is being used correctly. For example, a quality check can be trained on the monitoring data, e.g., the type of maneuver prescribed. A model predicting the type of maneuver or artifacts can be used to perform a quality check of all area traces to avoid deriving corrupted information, such as excessive movement during recording, or lack of amount or quality of the performed maneuvers. Auxiliary sensors, such as accelerometers, blood pressure, weight, activity monitors, patient inputs, etc., can also be used to facilitate the data integrity check.

[0028] The data extracted from the area trace signal by the feature detector 106 is provided to a metrics generator 108. The metrics generator 108 is a software-based machine made up of several different modules that generate specific cardiac-related metrics on which cardiac-related diagnostic and treatment decisions are based, as shown in FIG. 7. The frequency-derived metrics group 311 includes at least a heart rate module 312 and a respiration rate module 314. Based on the information received from the feature detector 106, the heart rate module 312 determines the heart rate (HR) based on the following relationship:

[0029]

number

[0030] Here, ti,card is the cardiac cycle interval time, and the mean or median can be used (feature (c) in Figure 2). Also based on the information from the feature detector 106, the respiration rate module 314 calculates the respiration rate (RR) based on the following relationship:

[0031]

number

[0032] Here, ti,resP is the respiratory cycle interval time, and the mean or median can be used (Feature (A) in Figure 2). Another embodiment for extracting from the area trace to determine respiratory rate is shown in FIG. 7A and described in further detail below.

[0033] The area derived metrics group 318 includes at least three area determination modules and a collapsibility index module 326. Additional optional modules include collapse 328 and cardiac output 329 determination modules. The maximum IVC area (Amax) module 320 can determine Amax based on the value of the largest dominant cardiac peak occurring during the relevant sampling period, as shown in feature (e) of FIG. 2. The minimum IVC area (Amin) module 322 can determine Amin based on the value of the largest respiratory area decrease valley occurring during the relevant sampling period, as shown in feature (g) of FIG. 2. Alternatively, the maximum and minimum area values ​​are extracted from the trace by finding the global maximum and minimum values, excluding abnormal trace sections from the entire trace, and excluding area sections of the trace that may be corrupted by artifacts. An example of this technique is shown in FIG. 7C. The mean IVC area (Amean) module 324 determines Amean based on the maximum and minimum areas (half the sum of Amax and Amin), as shown in FIG. 7D, for example.

[0034] The collapsibility index (CI) module 326 of the metrics generator 108 uses the determined area parameters to determine a collapsibility index of the IVC based on the following relationship:

[0035]

number

[0036] In yet another embodiment, collapse (identified in the area trace of FIG. 7D) is separately included via the collapse module 328, where collapse is determined based on the following relationship:

[0037]

number

[0038] Therefore, the collapsibility index can also be expressed as:

[0039]

number

[0040] For example, respiratory failure can be determined from the area trace. This has the potential advantage of being another somewhat independent signal that can be used to predict volume or congestion state or pressure. High volume / pressure results in low failure, normal volume / normal pressure results in high failure, and reduced volume / low pressure results in low failure, resulting in an 'n' shaped failure vs area curve. Features of the raw trace or trends in the manipulated trace may also prove useful, i.e., an accelerated increase in area may require more urgent or severe treatment than a gradual increase. In another example, other frequency-based signals may also be extracted and used as inputs for calculations. As a further example, the IVC area signal is known to change with each breath of the patient, and thus low frequency oscillations of the IVC can be used to extract respiratory rate. Respiratory rate has been shown to predict heart failure state and thus is a powerful input to overall patient state estimation. Additionally, metrics may be determined that combine frequency and area inputs 316.

[0041] Input from wearable devices such as activity trackers can also predict outcomes for cardiac patients and can be incorporated into the calculation where reduced activity is a predictor of worsening condition. Weight is also a factor that can be used to predict decompensation in heart failure, for example, an increase of more than about 2 kg over a two-day period is considered significant. Patients who measure their weight daily can also be incorporated into the calculation. Sleep, activity, heart rate variability, blood pressure, and other wearable outputs can also be incorporated into the congestion index. Additionally, data from embedded sensors and the entire system 100 can be incorporated into the wearable device's system as a source of additional data for predicting and / or monitoring health status.

[0042] The metrics group 332 from other inputs includes metrics derived from other external sensors (meaning external with respect to the system 100, which may include both in vivo and ex vivo sensors), such as pulse oximetry, temperature, blood pressure, urine volume, cardiac output, catheter pressure, etc. The patient specific information 334 generally includes information about the patient's physiological parameters, such as height, age, weight, sex, etc., and may also include current activity information entered by the patient or caregiver via a user interface. Another alternative external sensor input is accelerometer readings from a patient-worn component of the sensing system (such as the patient-worn processing unit 14), which may be embodied as an antenna belt, as described in the incorporated patent publications. Such accelerometer readings may be used to determine the patient's position and activity / movement during the trace period, enhancing the accuracy of the metrics derived from the trace.

[0043] 3 and 11, the metrics from the metrics generator 108 may be provided directly to decision logic 114 for application per specific diagnostic or treatment algorithm. The metrics may be provided to an interface device 116 for display and monitoring by a user. Area-based metrics are also provided to a boundary generator 110 for use in boundary determination.

[0044] To overcome the calibration challenges posed by intra- and inter-individual variability resulting from heterogeneity in vascular geometry as discussed above, embodiments of the present disclosure generate specific reference points against which periodic IVC area measurements are compared to assess the current patient fluid status and associated cardiac health. In one example, a boundary generator 110, shown in FIG. 8, uses IVC area data extracted or predicted from the area trace to determine upper and lower bounds for this purpose. Boundaries can be considered static or dynamic. Static boundaries are maximum / absolute values ​​that are not expected to change significantly over time. Absolute maximum / minimum area values ​​represent the upper and lower limits of an individual IVC area range and can be considered as static boundaries. The absolute maximum area can be related to the total circulating blood volume. It can be assumed that these boundaries are anatomical constants and that a particular patient's IVC can only ever be a certain size. In this way, boundaries can be considered static over time. This allows one to understand the patient's IVC range in one operation and use those boundaries over time. This basically means that a single calibration of the function is performed. Static boundaries can be used, for example, in relation to a particular set of conditions to be diagnosed.

[0045] Dynamic boundaries, on the other hand, can change over shorter periods of time. Dynamic boundaries do not necessarily represent absolute anatomical limits, but rather represent current limits resulting from changes in physiological parameters such as venous tone and intra-abdominal pressure. Dynamic boundaries may therefore represent new clinically relevant limits for each resting breath measurement, or occasionally when estimation is possible from manipulations or other means to use information closest in time to the measurement used for volume status assessment. In other words, based on the patient's overall fluid status in terms of total fluid distribution between vascular and extravascular fluids, the dynamic boundaries defined here may represent more clinically relevant criteria for assessing the patient's fluid status at the time of a particular measurement. Furthermore, the dynamic maximum area boundary may be related to right atrial pressure or vascular tone.

[0046] As shown in FIG. 8, the boundary generator 110 includes two components for generating boundaries: a lower boundary determination module 336 and an upper boundary determination module 340. In various embodiments, the lower boundary determination module 336 and the upper boundary determination module 340 may alternatively be configured to determine the lower and upper boundaries based on a maneuver or to predict the boundaries based on normal breathing. Further alternatively, the lower boundary determination module 336 and the upper boundary determination module 340 may comprise both a maneuver determination sub-module 338, 350 and a prediction sub-module 342a, 342b. FIG. 9 illustrates the operation of the maneuver determination sub-modules 338, 350, showing an area trace of an inspiration breath-hold maneuver superimposed on a normal breathing area trace. The lower boundary determination 336 takes into account physiological or device-related constraints that prevent the IVC from completely collapsing, such as the radial force of the sensor, the location of the sensor across the venous branches, or other physical constraint characteristics of the anatomy or implanted device. The sub-module 350 may receive information regarding the type of maneuver in various ways. In an embodiment using a feature detector 106 including a trace pattern recognizer 310, the system can provide the type of operation information directly. Alternatively, a user, such as a healthcare provider, can input information via the interface device 116 informing the patient of the instruction to perform the operation when instructing the patient to perform the operation. If a trace pattern recognizer 310 is present, it can also be used to verify the patient's compliance with the operation instruction by comparing the received area trace pattern with a stored pattern of the prescribed operation. Regardless of the source, when the operation is notified to be performed, the operation decision submodule 350 identifies the maximum area of ​​the operation area trace (point 349 in FIG. 9) as the upper boundary.

[0047] In some circumstances, it may be impractical or undesirable to require the patient to perform an action. The prediction submodule 342a is configured to predict an upper boundary (UB) based on the normal breathing area trace based on the following relationship developed by applicant:

[0048]

number

[0049] In one alternative, the "slope" used in equation [6] is -0.18% / mm as specified by Huguet et al., Three-Dimensional Inferior Vena Cava for Assessing Central Venous Pressure in Patients with Cardiogenic Shock. J Am Soc Echocardiogr. 2018; 31: 1034-43 (https: / / doi.Org / 10.1016 / j.echo.2018.04.003). 2 is a fixed baseline slope of, which is incorporated herein by reference in its entirety. The slope used may be obtained from data storage 346. In other alternative embodiments, the slope may be individualized based on each patient's area and collapse data, or may be trained based on a collection of area and collapse data or other data over a period of time. Further alternative techniques for upper bound generation 344 can also be derived based on the teachings of this disclosure.

[0050] The lower boundary (LB) determination module 336, in some embodiments, uses the operation determination submodule 338 to identify the lower boundary as the minimum area point in the operation area trace (351 in FIG. 9) in substantially the same manner as the upper boundary determination submodule 350 identifies the upper boundary. For example, the determination of the lower boundary can be made by a sniff operation, or other operation that reduces the IVC size, using the methodology described above. Alternatively, the lower boundary prediction 342b predicts the lower boundary using individual patient or population area and collapse data using a method similar to the upper boundary prediction 342a using equation [7].

[0051]

number

[0052] Yet another alternative sub-module 339 may also be provided that derives the lower limit from a population-based basis as the average minimum sensor size measured in the inferior vena cava, from sensor information regarding the inferior vena cava area at a given equivalent pressure, such as by comparing a sensor-derived area / pressure curve to a standard area / pressure curve (determined from radial or plate force information), or may be a programmed constant for all patients.

[0053] The upper and lower boundaries generated by the boundary generator 110 are provided to an index generator 112, shown in FIG. 10. These boundary values ​​allow the area measurement of the vessel to be normalized to return a number ranging from 0% to 100% or 0 to 10, where 0% is close to an internal filling pressure of 0 mmHg or is low volume / hypostasis / low volume, and 100% is close to the maximum possible filling pressure of this vessel (approximately 20 mmHg) or is high volume / hypostasis / high volume. The index generator 112 assigns the boundaries to a relative scale, setting the lower boundary as the minimum value of the scale and the upper boundary as the maximum value of the scale. In some embodiments, the relative scale is established as a 0 to 100% scale. Once the relative scale is established, the current area reading is scored on the relative scale, e.g., an area reading halfway between the upper and lower boundaries is scored as 50%. Since each patient can display a different IVC area based on numerous factors, including but not limited to anatomical size, current fluid status, body position, vascular tone, cardiac and abdominal pressures, the normalization described herein takes these parameters into account to generate a more standardized congestion index that is comparable across patients over time and across patients, helping to facilitate more accurate diagnosis and treatment of heart failure related diseases. As previously mentioned, initially, the novel IVC area-based metrics disclosed herein may not be well understood, and correlations with well-known physiological metrics will aid in clinical understanding for early adopters and ultimately clinical populations. In one embodiment, the Congestion Index can be determined based on the relationship of the mean area to the upper and lower boundaries, as in Equation [8].

[0054]

number

[0055] In another embodiment, the index generator 112 generates a vascular congestion index from the lower bound determined from the bound generator 110 and the collapsibility index 326 using the following formula:

[0056]

number

[0057] An alternative to this formula is to subtract from 100 and reverse the exponent, giving us

[0058]

number

[0059] As a further alternative, the congestion index can be determined using only the upper boundary as the ratio of the average area to the upper boundary as follows:

[0060]

number

[0061] In yet another embodiment, the index generator 112 optionally receives metrics from the metrics generator 108 and the boundary generator 110 and incorporates them into a normalized IVC congestion index. In such an embodiment, the index generator 112 can compress multiple features into a single metric. For example, the index generator 112 can be configured to output a single numeric value within a standardized range for each patient. This single numeric output can be an index of a measurable variable such as RAP, worsening heart failure, impending hospitalization, likelihood of an impending event, or a prompt for medication change. This output is common to all patients and includes or summarizes information from all inputs to provide an actionable output to the clinician. In a sense, this is comparable to a scale such as temperature, where 37 degrees is an accepted normal level and acceptable high and low thresholds. In such a configuration, the index generator 112 can output a congestion index ranging from 0 to 100% that indicates the risk of impending hospitalization due to heart failure in a selected time period, e.g., the next 30 days.

[0062] The IVC congestion index generated by the index generator 112 is reported directly by the user interface device 116, but can also be a valuable input to the decision logic 114, as shown in FIG. 11. The decision logic 114 includes one or more instruction sets for determining the patient's cardiac health status and treatment recommendations based on the cardiac function parameters and congestion index generated by the metrics generator 108. The decision logic 114 can be incorporated in one or more circuits, executed by one or more data processing devices, or distributed across a combination of such platforms. In general, the congestion index, optionally together with other metrics from the metrics generator 108, is a selectable input to various diagnostic and treatment algorithms 358, 360 executed in the decision logic 114. In one example, the thresholds can be set as follows: 0-30%: Below the normal range, indicating the lowest risk of hospitalization for heart failure due to volume overload, but with the risk of hypovolemia, caution and consideration of patient data is required, and diuretics may be reduced. 30%-70%: Normal range, potential to optimize medical treatment according to guidelines 70%-100%: Above normal range, indicating possible increased risk of hospitalization due to heart failure; caution and review of patient data; possible increase in diuretic dosage. In this way, any one feature of the daily congestion index with selected cutoff thresholds (lower and upper boundaries) is adjusted to a final congestion index as follows: (1) The low range from 0 to the lower threshold is adjusted to 0 to 30%. (2) The normal range from the lower threshold to the upper threshold is adjusted to 30% to 70%. (3) The high range from the upper threshold to 100% will be adjusted from 70% to 100%.

[0063] Approaches such as those outlined above can be used to create priority list algorithms to, for example, move patients to a higher priority status after a certain number of days above a threshold and remove patients who have been within the normal range for a certain number of consecutive days. Additionally, the primarily area-based congestion index described above may be enhanced by taking into account additional cardiac function related parameters as further described below to provide a more complete picture of a patient's cardiac health. Other examples of such algorithms are disclosed in the aforementioned USP 11,564,596, and in alternative embodiments may inform titration of up or down of certain medications such as diuretics, vasodilators, or other medications based on a pre-specified patient-specific prescription. Additional examples of conditions that may be diagnosed by algorithms 358 and 360 and for which treatment recommendations may be generated include conditions such as tricuspid regurgitation, atrial / ventricular tachycardia / bradycardia, and the like.

[0064] In other embodiments, manipulations or similar changes can be utilized to move the patient between two or more different states. Differences in the signals between these states can be indicative of different physiological states. An example is the case of a HFpEF patient, where a worsening of the state parameters is only evident upon exercise. In this case, the no exercise and exercise states can be used to provide signals to diagnose the presence of HFpEF. Venous pneumonia is another example where manipulations can cause shortness of breath, which may also be evidenced by signals indicating changes in respiratory rate / magnitude. These manipulations can be detected from the signal of the feature detector 106 or can be input from the interface device 116.

[0065] The decision logic 114 may utilize any number of metrics as inputs. In some cases, only individual metrics or groups of related metrics, such as area metrics, may be used. In one alternative embodiment, the metric weighting submodule 354 applies a weighting factor to one or more of the individual metric inputs. The weighting factor is determined by analysis of clinical and preclinical data and may be pre-specified or calculated and updated continuously based on user-specific inputs. The notification in this case may include instructions to take a therapeutic action, to take additional readings, or to alert the healthcare provider to a potentially clinically problematic situation.

[0066] As shown in FIG. 12, it is envisioned that the interface device 116 includes at least one user interface 402 accessible by the care provider, for example, via the care provider device 400, for data entry 404, such as patient-specific information, prescription details, user settings, operating instructions, algorithm updates, and other system hygiene. The user interface 402 may also provide notifications generated by the decision logic 114 or other components of the diagnostic engine 102, and may be a web-based or mobile application. In some embodiments, the interface device 116 may include processing capabilities in the form of one or more processors 406 and associated hardware / software. Diagnostic or therapeutic alerts 408 may also be delivered via the care provider device 400, for example, as described in the aforementioned incorporated U.S. Pat. No. 11,564,596. The interface device 116 may also include a patient personal device 410, which may be used for various functions within the system in addition to patient notifications, for example, as shown in FIG. 1.

[0067] An embodiment of the present disclosure may be described in terms of a continuous process flow, such as the example process flow 500 shown in FIG. 13, or alternative embodiments of the system may have a version of this configuration. As shown there, different data types invoke different processes. For example, data 504 representing a sensor time series of quiescent breathing invokes a process 506 of filtering (respiratory trace, cardiac trace, average trace, noise trace) and a process 508 of feature extraction (Amax, Amin, collapse, CI, respiratory collapse, cardiac collapse, heart rate, respiratory rate). Similarly, data 512 representing a sensor time series of maneuver invokes a process 514 of filtering and transforming using BOSS (bag of symbolic Fourier approximation (SFA) symbols) and a process 516 of evaluating the maneuver trace using features from BOSS as well as features from other common descriptive statistics to evaluate trace quality and extract maximum area achieved. External data 518, such as blood pressure, weight, blood oxygenation, etc., invokes a process 520 that incorporates data representing other features externally sensed from other sensors or direct inputs. The output of these processes may be stored in a database 510.

[0068] The features output from database 510 (or directly from an upstream process) invoke process 522 to generate metrics as described herein, including, for example, congestion index 524, right atrial pressure (RAP) 526, respiratory rate (RR) 528, cardiac output (CO) 530, systemic vascular resistance (SVR) 532, IVC tone 534, heart rate (HR) 536, patient weight 538, patient activity 540, and other metrics as described herein. The generated metrics are then processed (542) to generate an IVC congestion index score 544 based or enhanced on all metrics. This is either presented to the user or used as input to decision logic 114 as the basis for further diagnostic or treatment decisions.

[0069] In some embodiments, the enhanced indexing process 542 is configured as an AI or machine learning based model that is trained based on all described inputs and determines the optimal weighting of each metric to predict a particular output, such as "worsening heart failure," "increasing congestion," "likelihood of hospitalization," etc. One such example is a multiple logistic regression model that uses the training data set to develop a model that returns the likelihood of hospitalization based on the inputs 524-540 or a subset of the inputs. Another embodiment is a decision tree model that splits the data from each input based on the training set data, classifying it as, for example, "likely to be hospitalized" or "not likely to be hospitalized," and repeats this process for each input parameter until a model is created that can accurately predict the likelihood of hospitalization.

[0070] Further alternative embodiments for generating various metrics within the components of the metrics generator 108 are described below with reference to Figures 7A-B and 15-20A-D. For example, an additional alternative embodiment of the respiration rate module 314 of the metrics generator 108 extracts the respiration rate from the area trace, as shown in Figure 7A. As shown, the respiration rate module 314A receives the area trace as an input 375. The input signal is then filtered using a Butterworth bandpass filter module 377 to remove baseline wander and high frequency components. An example range for this filter is 0.08Hz to 0.75Hz. The signal is then split into a number of windows with a specific delay (module 379). In this example, 512 windows with a delay of 4 seconds. The mean value is then subtracted from each window (module 381). These windows from 381 are then used to estimate the power spectral density (PSD). This is done using the Welch method to account for possible non-stationarity in the signal, i.e., changes in the respiration rate module 383. For example, a Hann window with a sample size of 256 can be used. The power spectral density from module 383 is then filtered to look at possible respiration rates module 385, for example between 8 and 40 beats per minute. All peaks in this filtered spectrum are then detected in module 387, for example using peak prominence. The maximum peak detected is extracted in module 389. The signal quality of this peak is then evaluated in comparison with the signal quality outside the range excluding potential harmonics of this peak. If the signal quality is greater than a threshold in module 391, the respiration rate per minute estimated by the maximum peak is accepted for the window, otherwise the respiration rate of the window is rejected in module 393. Modules 383, 385, 387, 389, 391 and 393 are repeated over all windows specified by 381. Module 395 receives as input all these respiration rates expressed in respirations per minute.If the number of breath rates is greater than the threshold, the average of the accepted breath rates is returned as the global breath rate at input 375. The final output 397 of this breath rate module 314A returns individual values ​​for each of the breath rate (RR), signal quality (SQ), and respiratory collapse index derived for each area trace input.

[0071] As yet another metric example, each beat of the heart also perturbs the IVC, and this high frequency signal can also be extracted from the IVC area trace by spectrally decomposing the area trace using a fast Fourier transform (FFT), as shown in Figure 7B. Heart rate is also well known to be a useful metric in patient management and can be included in the generated metrics. Increased or decreased heart rate, or increased heart rate variability, can be predictors of poor outcome. Pacing-related metrics can also be determined from the area trace.

[0072] In another example, assuming an ideal "n"-shaped curve for IVC area versus IVC collapse, as shown in Figure 15, allows one to estimate the ellipticity of the IVC (thus providing an approximation of the IVC diameter when using existing diameter-based clinical guidelines as a threshold). One can also assume that the IVC shape varies from a flat ellipse to a perfect circle along that "n" curve, and the axial ratio varies accordingly from low (-0.1) to equal (1) along the curve. Thus, knowing both the collapse and area, one can roughly determine the location on the "n" shape, thereby estimating the axial ratio of the IVC. The approximate axial ratio can be substituted into the ellipse area equation, reducing the number of unknown variables to 1 and providing an accurate solution for the major and minor diameters of the IVC (for comparison with existing clinical guidelines).

[0073] In another embodiment, the change in area seen by the IVC is used to estimate venous return (VR) / cardiac output (CO) by measuring the change in area per time as the integral under the curve (AUC) and performing a simple initial calibration to clinical cardiac output measurements. This measurement is based on the volume passing through the IVC, causing a temporal dilation of the IVC to its minimum size. Figure 16 shows this distortion in an ideal cross-sectional depiction of the IVC in (b) and (d), which corresponds to the same features of the area trace (Figure 2) and identifies the shift in the circle and area. In this example, cardiac output can be determined using the following equation

[12] :

[0074]

number

[0075] The correction factors (corfacresp and corfaccard) are derived from the measured calibration step reference cardiac output (e.g., ultrasound estimating cardiac output). The correction factors can be separated into respiratory and cardiac contributions. This is because the distance from the device to the heart can affect the cardiac component detected for respiratory modulation. For example, two-thirds of blood flow to the right atrium originates from the IVC. As blood flows through the IVC, it expands as a flexible vasculature. Changes in IVC cross-sectional area are correlated with cardiac output, as was reported by Barberi et al. in 2004 [Intensive Care Med (2004) 30: 1740-1746, DOI 10.1007 / s00134-004-2259-8] (incorporated herein by reference in its entirety). The IVC changes with respiratory effort and cardiac activity. The concept of relating changes in IVC area to cardiac output is based on four main features: changes in area due to respiration and cardiac activity, and changes in area due to heart rate and respiratory rate. Venous return / cardiac output is a time integral and therefore of a complex nature, m 2The area time integral measured in 0m must be calibrated in relation to cardiac output measured in liters per minute. This requires at least one synchronized cardiac output measurement in conjunction with a recording of the free-breathing IVC sensor area. 2 and assuming 0 liters / min is the second calibration point, a simple linear calibration is possible, ultimately resulting in liters / min / m 2 A unit conversion factor f is obtained, so that

[0076]

number

[0077] In another embodiment, multiple calibration points are created by phlebotomy / withdrawal and reinfusion of blood or by injecting saline with a known bolus volume. It is expected that the accuracy of cardiac output will improve if respiratory area modulation is related to cardiac area modulation in a weighted manner. Furthermore, tricuspid regurgitation information can be incorporated to correct for regurgitation-related area modulation. A weighting correction factor may be included to adjust for cardiac and respiratory contributions seen in collapse. This approach requires multiple single reference points for calibration. For example, in cardiac output measurements during provocative maneuvers such as inspiration or expiration breath-holds, the respiratory component can be separated from the cardiac component because only the cardiac component is visible during the breath-hold.

[0078] As further shown in FIG. 17, the measured area traces and the filtered respiratory and cardiac component traces can be used to calculate an area under the curve (AUC) as a metric for cardiac output. The change in area within the vessels correlates with the volume delivered to the right atrium, commonly known as venous return. Venous return is considered to be equal to cardiac output. Venous return consists of blood flow from the superior and inferior vena cava. The sensor is placed at one of these locations, so an initial calibration step is necessary. A baseline cardiac output level can be obtained by common clinical measurement methods such as ultrasound or thermodilution, and other methods. In some embodiments, a single cardiac output measurement can be used, or a second cardiac output and sensor reading can be obtained using manipulation or other methods. Using such a baseline and the calculated AUC, a correction factor is established that links the two. The correction factor can be further refined by adding information about the respiratory and cardiac contributions to the flow at each sensor location, for example, by dividing the single correction factor by a predetermined ratio that applies to the heart and the respiratory.

[0079] In another embodiment, cardiac output estimation process 700 can be used to estimate cardiac output directly from sensor data, as shown in FIG. 18. Inputs 703 to process 700 include extracted features related to area under the curve, such as cardiac collapse (Hcol) and respiratory collapse (Rcol), as well as heart rate (HR) and respiratory rate (RR). With these inputs, the cardiac component of the output is set at 706 as the product of heart rate, cardiac collapse and sensor length. Similarly, the respiratory component of the output is set at 709 as the product of heart rate, respiratory collapse and sensor length. The sensor length in this process can refer to the longitudinal length of the sensor coil portion of a wireless resonant circuit sensor implant configured and dimensioned to be implanted in a patient's blood vessel in contact with the vessel wall. One example of such a sensor implant comprises an expandable and foldable variable inductance coil with multiple adjacent wire strands formed around an open center to allow substantially unimpeded blood flow through the open center. In some such embodiments, the coil is configured and dimensioned to (i) stretch along the inner circumference of the vessel when implanted within the vessel, and (ii) move with the vessel wall in response to the vessel's expansion and contraction. The sensor implant also includes a capacitance that, together with the variable inductance coil, forms a variable inductance resonant circuit having a variable characteristic frequency that correlates with the diameter or area of ​​the expandable and contractable variable inductance coil. In yet another alternative, the expandable and contractable variable inductance coil includes multiple wire strands, and the inductance varies based on the change in cross-sectional area or diameter across the open center of the coil in response to the coil's expansion and contraction. Such sensor implants are described in detail, for example, in U.S. Pat. No. 10,806,352, which is incorporated by reference (e.g., RC-WVM implant 12 and height (A) corresponding to the sensor length described therein). It should be noted that steps 706 and 709 can be performed in any order or simultaneously. The total cardiac output is set at 712 by multiplying the sum of the two component outputs by a correction factor. One skilled in the art can derive correction factors based on the teachings of the present application using examples of respiratory and cardiac components that correlate with measured cardiac output.

[0080] As further shown in Figures 19(A)-(c), the parameters cardiac collapse (Hcol), respiratory collapse (Rcol), heart rate (HR), and respiration rate (RR) can be used to synthetically calculate the respiration and cardiac traces (simulated area modulation), again using the AUC method as another alternative means of assessing cardiac output. In this embodiment, the collapse component is used to inform the oscillation magnitude, and the rate informs the oscillation frequency. Thus, the Respiration Trace (b) of Figure 19 can be simulated as follows:

[0081]

number

[0082] where Time Samples are a linear range of values ​​from a starting value to a final timestamp, in discrete steps defined by the sampling frequency. In analog, the Cardiac Trace (c) can be simulated as follows:

[0083]

number

[0084] In a further alternative embodiment, right atrial pressure (RAP) can be estimated by correlation with area trace data. For example, paired data of IVC area trace and RAP can be calculated as: Vascular tone measured by the pressure catheter can be used to create a regression model using training data at an individual or population level. It can then be used to predict RAP based on the input of area metrics (e.g., area mean) generated from the area traces of the sensors. Vascular tone refers to the degree of constriction of the blood vessels relative to their maximally dilated state and can also be estimated based on area trace data. For example, changes in extracted features over time (e.g., Amax achieved at different operations on different days) may indicate changes in IVC tone. Thus, an estimate of IVC tone can be obtained by using the training model to correlate with area trace data.

[0085] In another embodiment, mean arterial pressure (MAP) can be determined using an external blood pressure cuff and, in combination with the aforementioned cardiac output and RAP (directly measured or estimated as above), the systemic vascular resistance (SVR) can be estimated using the following equation

[16] :

[0086]

number

[0087] An example of this calculation based on human sensor data is shown in Figure 20A-D, showing trend data for a heart failure patient experiencing symptoms (dyspnea) as a function of days. Traces of SVR (systemic vascular resistance), area average from the sensor, respiratory rate from the sensor, and daily dose of diuretic (furosemide) are displayed. Towards symptom worsening (dyspnea / shortness of breath) in mid-March, area increased logarithmically with rising respiratory rate. SVR increased exponentially and sharply towards the end of dyspnea. With increasing diuretic dose, area decreased significantly within a few days and SVR initially recovered, but then temporarily increased for a few days after which the drug was ideally titrated to bring the patient's respiratory rate down to normal.

[0088] The systems and methods described herein can be implemented using one or more computing devices, and unless otherwise specified, can include standard computing components of a processor, memory, storage, and communication bus, as well as high-resolution graphics rendering hardware and software, as needed. Such components can be configured and programmed by one of ordinary skill in the art based on the teachings of this disclosure. Software programming implementing the systems and methods described herein resides as a computer program product on a non-transitory computer-readable medium. Typical computing devices also include cloud-based computing embodiments and computing systems with elements distributed across a network.

[0089] In various alternative embodiments, the signal processing, data extraction, diagnostic and treatment related functions, such as trace generator 104, feature detector 106, metrics generator 108, boundary generator 110, index generator 112, decision logic 114, or interface device 116 including processor 406, may be implemented as one or more computing devices or collectively implemented in a single or multiple computing devices, as non-limiting examples. FIG. 14 illustrates an example of such a computing device, where computing device 600 includes one or more processors 602, memory 604, storage device 606, high-speed interface 608 connecting memory 604 and high-speed expansion port 610, and low-speed interface 612 connecting low-speed bus 614 and storage device 606. Each of components 602, 604, 606, 608, 610, and 612 are interconnected using various buses or other suitable connections, as shown in FIG. 8 by the arrows connecting the components. The processor 602 may process instructions, including instructions stored in the memory 604 or storage device 606, for execution within the computing device 600 to display graphical information via the GUI 618 on the display 620 or to an external user interface device connected to the high speed interface 608. As one skilled in the art will appreciate, certain functions described may not require a separate GUI or display. In other implementations, multiple processors and / or multiple buses, and multiple memories and memory types may be used as desired. Also, multiple computing devices 600 may be connected, with each device providing a portion of the required operations (e.g., as a server bank, a group of blade servers, or a multi-processor system).

[0090] The memory 604 stores information within the computing device 600. In one embodiment, the memory 604 is a computer-readable medium. In one embodiment, the memory 604 is a volatile memory unit. In another embodiment, the memory 604 is a non-volatile memory unit.

[0091] The storage device 606 can provide mass storage for the computing device 600 and can include information such as timing control, time slice size, and / or static color saturation and timing, as described above. In one embodiment, the storage device 606 is a computer-readable medium. In various different embodiments, the storage device 606 can be a floppy disk device, a hard disk device, an optical disk device, or a tape device, a flash memory or other similar solid-state memory device, or an array of devices including devices in a storage area network or other configuration. In one embodiment, a computer program product is tangibly embodied in an information carrier. The computer program product includes instructions that, when executed, perform one or more methods as described above. The information carrier is a computer or machine-readable medium, such as the memory 604, the storage device 606, or a memory on the processor 602.

[0092] The high-speed interface 608 manages the bandwidth-intensive operations of the computing device 600, and the low-speed interface 612 manages the less bandwidth-intensive operations. Such role assignments are merely exemplary. In one embodiment, the high-speed interface 608 is coupled to the memory 604, the display 620 (e.g., via a graphics processor or accelerator), and a high-speed expansion port 610 that can accept various expansion cards (not shown). In this embodiment, the low-speed interface 612 is coupled to the storage device 606 and the low-speed expansion port 614. The low-speed expansion port, which can include various communication ports (e.g., USB, Bluetooth, Ethernet, wireless Ethernet), may be coupled to one or more input / output devices as part of the GUI 618 or as additional external user interfaces such as a keyboard, pointing device, scanner, or network devices such as switches and routers.

[0093] Various implementations of the systems and techniques described herein may be realized in digital electronic circuitry, integrated circuits, specially designed ASICs (application specific integrated circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations include implementation in one or more computer programs executable and / or interpretable by a programmable system that includes at least one programmable processor (special purpose or general purpose) coupled to receive data and instructions from, and transmit data and instructions to, the storage system, the at least one input device, and the at least one output device.

[0094] These computer programs (also referred to as programs, software, software applications, or code) contain machine instructions for a programmable processor and may be implemented in high level procedural and / or object oriented programming languages ​​and / or in assembly / machine languages. As used herein, the terms "machine-readable medium" and "computer-readable medium" refer to computer program products, apparatus, and / or devices (such as magnetic disks, optical disks, memories, programmable logic devices (PLDs), etc.) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as a machine-readable signal. The term "machine-readable signal" refers to a signal used to provide machine instructions and / or data to a programmable processor.

[0095] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer with a display device separate from the video display 620. Although LED displays are most common today, older display technologies (e.g., CRT (cathode ray tube) or LCD (liquid crystal display) monitors) can also be used. Other interface devices include keyboards and pointing devices (e.g., mice or trackballs) that allow a user to provide input to the computer. Other types of devices can also be used to provide interaction with a user. For example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback), and input from the user can be received in any form, including acoustic, speech, or tactile input.

[0096] The systems and techniques described herein may be implemented in a computing system that includes a back-end component (e.g., a data server), a computing system that includes a middleware component (e.g., an application server), a front-end component (e.g., a client computer with a graphical user interface or web browser through which a user may interact with implementations of the systems and techniques described herein), or any combination of such back-end, middleware, or front-end components. The components of the system may be interconnected by any form or medium of wired or wireless digital data communication (e.g., a communications network). Examples of communications networks include a local area network ("LAN"), a wide area network ("WAN"), and the Internet.

[0097] A computing system may include clients and servers. Clients and servers are typically remote from each other and typically interact through a communication network. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other. The functionality described herein may also be implemented as cloud-based or other network-based processing modules, and may also be implemented using a Software as a Service ("SaaS") model.

[0098] Further alternative embodiments of the present disclosure include a method for creating a patient-specific heart failure diagnostic tool. Such a method may include monitoring a patient's physiological parameter (having a measurable value) that correlates with the patient's body fluid volume, instructing the patient to perform an action, recording the change in the value of the monitored physiological parameter as the patient performs the action, setting the value of the physiological parameter when the patient performs the action as the patient's maximum value, determining a minimum value, and setting the maximum value as the upper limit and the minimum value as the lower limit of a standardized scale that correlates with the risk of a heart failure adverse event to establish a heart failure risk assessment tool customized for the patient. In such a methodology, the measured value of the monitored physiological parameter can be compared to the standardized scale to determine the level or type of medical intervention.

[0099] In another alternative embodiment, a method for diagnosing heart failure includes monitoring a patient's physiological parameter having a measurable value that correlates to the patient's body fluid volume; instructing the patient to perform an action; recording a change in value of the monitored physiological parameter in response to the patient performing the action; setting the value of the physiological parameter at the time the patient performs the action as a maximum value for the patient; determining a minimum value; setting the maximum value as an upper limit and the minimum value as a lower limit of a standardized scale that correlates to a risk of an adverse heart failure event; comparing the measured value of the monitored physiological parameter to the standardized scale; and determining a level or type of medical intervention for the patient based on the comparison to the standardized scale.

[0100] The aforementioned method may further include collecting IVC area trace data for a plurality of patients in a plurality of fluid volume states, storing the collected data in a database, analyzing the data to determine a curve between the maximum and minimum values ​​of a number of different maximum values, and creating a standardized scale based on the determined curve. In other embodiments, the patient's physiological parameter that correlates with the patient's fluid volume includes an IVC dimension, and the monitoring includes measuring the IVC dimension. The monitoring may further include measuring the IVC dimension with an implanted wireless sensor. In another alternative, the monitoring may include measuring the IVC dimension and an external ultrasound imaging device. The systems and methods described herein provide unique data and novel data interpretation tools to help clinicians manage heart failure, reduce hospitalizations, better manage patient treatment, and therefore improve patient outcomes compared to traditional heart failure management programs.

[0101] The above is a detailed description of an exemplary embodiment of the present disclosure. In this specification and the appended claims, conjunctions such as "at least one of X, Y, and Z" and "one or more of X, Y, and Z" mean that each item in the connected list can be present in any number of times except for all other items in the list, or in any number of times in combination with any or all of the other items in the connected list, and each item can also be present in any number of times, unless otherwise stated or indicated. Applying this general rule, the conjunctions in the above example, where the connected list is composed of X, Y, and Z, respectively, include one or more of X, one or more of Y, one or more of Z, one or more of Y, one or more of Z, one or more of X, one or more of Y, and one or more of Z.

[0102] Various modifications and additions can be made without departing from the spirit and scope of the present disclosure. The features of each of the various embodiments described above can be combined with the features of other embodiments as necessary to provide various combinations of features in related new embodiments. Moreover, although a number of separate embodiments have been described above, what has been described herein is merely illustrative of the application of the principles of the present disclosure. Moreover, although certain methods herein have been illustrated and / or described as being performed in a particular order, the order can be varied widely within the ordinary skill of the art to achieve aspects of the present disclosure. Thus, this description should be construed as illustrative only and not limiting of the scope of the present disclosure or the invention as set forth in the following claims.

Claims

1. a trace feature detector for identifying selected features and at least one of a magnitude and a timing of the selected features for the received periodic vascular area trace representative of the patient's change in fluid status over time, the selected features including one or more of an interval time per respiratory cycle, an area magnitude of respiratory modulation, an interval time per cardiac cycle, an area magnitude of cardiac modulation, a dominant cardiac peak, a second cardiac peak, a respiratory related area decrease, a maneuver type, and a maximum and minimum area associated with the identified maneuver; a metrics generator that generates cardiac function-related parameters for each area trace based on the selected features, magnitude, and timing, the cardiac function-related parameters including one or more of maximum vascular area (Amax), minimum vascular area (Amin), mean vascular area (A), heart rate (HR), respiratory rate (RR), collapsibility index (CI), collapse (C), and cardiac output (CO); a boundary generator for generating at least a lower vascular area boundary (LB) of the patient or an upper vascular area boundary (UB) of the patient using the generated cardiac function related parameters; an index generator for setting a congestion index for the patient based on one or more of the generated cardiac function related parameters and at least one of a patient's lower vascular area boundary (LB) or a patient's upper vascular area boundary (UB), the congestion index being indicative of the patient's fluid status on a normalized scale for a period of the trace. Automated heart failure diagnostic device.

2. The apparatus of claim 12 , further comprising a trace generator configured to generate the periodic vascular area trace.

3. The apparatus of claim 1 or 2, further comprising a decision logic configured to determine at least one of a diagnostic status and a treatment protocol for a patient based at least on the congestion index from the index generator.

4. The boundary generator: As the average smallest area measured in the IVC using either multiple measurements from a patient or population information from multiple patients, (-1 / S)·C+Amean, where (S) is the received reference gradient, and as the minimum vessel area (A) of the area trace associated with the detected maneuver; setting a vascular lower area boundary (LB) according to one or more of the following relationships:

4. Apparatus according to claim 1, 2 or 3.

5. The boundary generator: As the mean maximum area measured in the IVC using either multiple measurements from a patient or population information from multiple patients, (-1 / S)·CI+Amean, where (S) is the received reference gradient, and as the maximum vessel area (A) of the area trace associated with the detected maneuver; setting a vascular upper area boundary (UB) according to one or more of the relationships: An apparatus according to any one of claims 1 to 4.

6. The apparatus of any one of claims 1 to 4, wherein the index generator sets the congestion index according to one or more of the following relationships: Equal to (Amax-Amin) / (Amax-LB)*100%; Equal to 100*(Amean / UB); is equal to 100*((Amean-LB) / (UB-LB)); and Equal to 100-(Amax-Amin) / (Amax-LB)*100%.

7. The metrics generator further comprises: Generates one or more of right atrial pressure (RAP), IVC strain, or systemic vascular resistance (SVR). The RAP is predicted based on the correlation of the receiving area tracing with the measured right atrial pressure. IVC tone is correlated with the maximum area of ​​the area trace over time using a training model.

2. Apparatus according to any one of the preceding claims, wherein the SVR is set equal to the measured mean atrial pressure minus the RAP divided by the collapse pressure (CO).

8. 2. The apparatus of claim 1, further comprising a machine learning based model that applies weightings to the congestion index, the generated cardiac function related parameters, and input patient-specific information to return a patient's likelihood of hospitalization score.

9. The trace generator includes: External ultrasonic transducer, Embedded ultrasonic sensors, embedded resonant circuit coil sensor, or Implantable sensor including sensing electrodes - Patents.com The device according to any one of claims 2 to 8, comprising at least one of:

10. 1. A system for automatically determining a patient's fluid status using periodic vascular area tracings, comprising: A trace feature detector that identifies selected features of the vessel area trace and at least one of a magnitude and a timing of the identified features of the vessel area trace. a metrics generator that generates cardiac function-related parameters for each area trace based on the identified magnitudes and timings, the cardiac function-related parameters including at least a maximum vessel area (A) and a minimum vessel area (A); an index generator that generates a congestion index for the patient based on at least the maximum vessel area (Amax), the minimum vessel area (Amin), and at least one of a lower vessel area boundary (LB) or an upper vessel area boundary (UB) of the patient, the congestion index being indicative of the patient's fluid status on a normalized scale for each of the trace periods; system.

11. 11. The system of claim 10, wherein the selected area trace features further include one or more of interval time per respiratory cycle, area magnitude of respiratory modulation, interval time per cardiac cycle, area magnitude of cardiac modulation, dominant cardiac peak, secondary cardiac peak, respiratory related area reduction, maneuver type, and maximum and minimum areas associated with the identified maneuver.

12. 12. The system of claim 10 or claim 11, wherein the metrics generator generates cardiac function related parameters further including one or more of mean vascular area (Amean), heart rate (HR), respiratory rate (RR), collapsibility index (CI), collapse (C), and cardiac output (CO).

13. The system of any one of claims 10 to 12, wherein the metrics generator is configured to receive patient-specific information and generate a cardiac function related parameter based on the received patient-specific information.

14. The system according to any one of claims 10 to 13, further comprising a boundary generator for generating at least the vascular lower area boundary (LB) or the vascular upper area boundary (UB) using the generated cardiac function related parameters.

15. The boundary generator: Receive at least the operation detection and the minimum hull area (Amin); Set the vessel lower area boundary (LB) as the minimum vessel area (A) of the area trace associated with the manipulation detection; The system of claim 14.

16. The boundary generator: Receive the collapse value (C), the mean area (Amean), and the reference slope (S); Set the vessel lower area boundary (LB) equal to (-1 / S)·C+Amean; The system of claim 14.

17. The boundary generator: Receive a minimum area (A) of a selected number of area traces; Using multiple measurements from an individual patient or population information from multiple patients, set the lower vascular area boundary (LB) as the average minimum area measured in the IVC; The system of claim 14.

18. The boundary generator: Receive at least the operation detection and maximum vessel area, setting the vascular upper area boundary (UB) as the maximum vascular area of ​​an area trace associated with the manipulation detection; A system according to any one of claims 14 to 17.

19. The boundary generator: Receive the collapsibility index value (CI), the mean area (Amean), and the baseline slope (S); Set the upper boundary (UB) to (-1 / S)·CI+Amean; A system according to any one of claims 14 to 17.

20. The boundary generator: receiving a maximum area (A) of a selected number of area traces; setting a vascular upper area boundary (UB) measured at the IVC as the average maximum area using at least one of a plurality of measurements from the patient or population information from a plurality of patients; A system according to any one of claims 14 to 17.

21. 20. The system of claim 1, further comprising a decision logic that determines at least a diagnostic status and a treatment protocol for the patient based at least on the congestion index from the index generator.

22. The decision logic comprises: Responsive to a congestion index being between about 0 and 30, generating instructions to alert a user and identify a risk of hypovolemia; generating an indication to a user that the patient's fluid status is within a normal range in response to the congestion index being between about 30 and 70; Responsive to a congestion index between about 70 and 100, generating an instruction to alert a user and identify a risk of hypervolemia; 22. The system of claim 21.

23. The decision logic further receives a plurality of cardiac function related parameters from the metrics generator; The decision logic includes a data set training model that returns a likelihood of hospitalization of a patient based on a congestion index and inputs an input cardiac function related parameter.

23. A system according to claim 21 or 22.

24. 2. The system of claim 1, further comprising one or more interface devices in communication with the metrics generator, the index generator, and the decision logic.

25. the one or more interface devices include a patient personal device configured to wirelessly communicate with at least the metrics generator and the index generator; the patient personal device is configured to input patient-specific information; The patient personal device is configured to receive and display the patient's congestion index.

25. The system of claim 24.

26. the one or more interface devices include a healthcare provider device in communication with the metrics generator, the index generator, and the decision logic; the healthcare provider device is configured to input patient-specific information; the healthcare provider device is configured to input changes to therapeutic and diagnostic algorithms in the decision logic; the healthcare provider device is configured to receive and display the generated cardiac function related parameters, patient treatment or diagnostic status alerts, and patient congestion index.

26. The system of claim 25.

27. Further comprising a trace generator; The trace generator includes: at least one transducer configured to monitor a change in blood vessel area and generate a sensor signal representative of the monitored change; a processing system configured to receive a sensor signal and generate the periodic area trace based on the sensor signal. A system according to any one of the preceding claims.

28. 30. The system of claim 27, wherein the at least one transducer comprises an implantable coil configured to generate a variable frequency signal that correlates with a change in vessel area when placed within a vessel.

29. 30. The system of claim 28, wherein the processing system comprises a patient-wearable antenna, a powering circuit in communication with the antenna, and a signal receiving circuit in communication with the antenna.

30. The sensor includes: an expandable and collapsible variable inductance coil having a plurality of adjacent wire strands formed about an open center, the coil allowing substantially unimpeded blood flow therethrough, the coil being configured and dimensioned to move with the vessel wall in response to the vessel expanding and collapsing; and a capacitance that, together with the variable inductance coil, forms a variable inductance resonant circuit having a variable characteristic frequency that is correlated to a diameter or area of ​​the expandable and foldable variable inductance coil.

30. A system according to any one of claims 27, 28 or 29.

31. The metrics generator calculates the cardiac cycle interval time (ti card ) and calculate the heart rate (HR) by 1 / (ti card 31. The system of claim 12, wherein the first and second inputs are set equal to each other.

32. The metrics generator calculates the interval time (ti resp ) and calculate the respiratory rate (RR) by 1 / (ti resp 32. The system of claim 12, wherein the first and second inputs are set equal to each other.

33. 33. The system of claim 12, wherein the metrics generator receives a maximum vessel area (Amax) and a minimum vessel area (Amin) and sets collapse (C) equal to Amax-Amin.

34. 34. The system of claim 12, wherein the metrics generator receives collapse (C) and maximum vessel area (Amax) and sets a collapsibility index (CI) equal to C / Amax * 100%.

35. 35. The system of claim 12, wherein the metrics generator receives the cardiac component of collapse (Hcol), the respiratory component of collapse (Rcol), the heart rate (HR) and the respiratory rate (RR) and sets cardiac output (CO) as the sum of the product of Hcol and HR and the product of Rcol and RR.

36. The system of any one of claims 12 to 34, wherein the metrics generator receives an area trace and returns cardiac output (CO) as the product of the area-time integral of the area trace and a correction factor.

37. 37. The system of claim 10, wherein the index generator receives a maximum vessel area (Amax), a minimum vessel area (Amin), and a vessel lower area boundary (LB) and sets a congestion index equal to (Amax-Amin) / (Amax-LB)*100%.

38. The system of any one of claims 10 to 36, wherein the index generator receives a mean vessel area and a vessel upper area boundary (UB) and sets the congestion index equal to 100*(Amean / UB).

39. 37. The system of claim 10, wherein the index generator receives a maximum vessel area (Amax), a minimum vessel area (Amin), an upper vessel area boundary (UB), and a lower vessel area boundary (LB) and sets the congestion index equal to 100*((Amean-LB) / (UB-LB)).

40. 37. The system of claim 36, wherein the exponent generator is further set equal to 100-(Amax-Amin) / (Amax-LB)*100%.

41. receiving a static respiratory vascular area trace of the patient in at least one processing device; receiving, within said processing device, patient specific information including at least a patient weight and a patient age; filtering the static respiratory vascular area trace in said processing unit to identify component signals including at least a respiratory trace, a cardiac trace, and an average trace; extracting, in said processing device, magnitude and timing features from said tracings corresponding to at least one or more of maximum area, minimum area, collapse, respiratory collapse, cardiac collapse, heart rate, and respiratory rate; generating, with the processing device, cardiac function-related parameters based on the extracted magnitude and timing features using executable program instructions defining the cardiac function-related parameters, the cardiac function-related parameters including one or more of respiratory rate, cardiac output, heart rate, collapsibility index, collapse, maximum vascular area, minimum vascular area and mean vascular area; generating a congestion index for the patient based on one or more of the size characteristics and a parameter related to cardiac function; and Using a machine learning based model to apply weights to the congestion index, cardiac function related parameters, and patient specific information to return a patient's likelihood of admission score; The computer-based method includes:

42. 42. The method of claim 41, further comprising generating a user-directed alert including instructions for modifying or maintaining treatment depending on the returned likelihood of admission.

43. receiving external sensor input including at least patient-worn accelerometer data indicative of a patient's activity level; The external sensor input is incorporated into the weighting of a machine learning model.

43. The method of claim 41 or 42.

44. generating and weighting additional cardiac function related parameters including one or more of right atrial pressure (RAP), IVC tone, or systemic vascular resistance (SVR); RAP is predicted based on the correlation between the receiving area tracing and the measured right atrial pressure; IVC tone was correlated with the maximum area of ​​the area trace over time using a trained model, The SVR is set equal to the measured mean atrial pressure minus the RAP divided by the collapse (CO).

44. The method of claim 41, 42 or 43.

45. 45. A computer-based system including one or more processing and storage devices configured and programmed to carry out the method of any of claims 41, 42, 43 or 44.

46. 1. A method for automatically determining a patient's fluid status using periodic vascular area tracing, comprising: receiving a vascular area trace; identifying selected features of the vascular area trace and at least one of a magnitude and a timing of the identified features; generating cardiac function related parameters for each area trace based on the identified magnitudes and timings, the cardiac function related parameters including measured vessel areas and vessel area boundaries; and generating a patient congestion index representing the relationship between the measured vascular area determined for the area trace and the patient's vascular area boundary, said congestion index indicating the patient's fluid status on a normalized scale for each period of the trace;

47. using the generated cardiac function-related parameters to generate at least one of a lower vascular area boundary (LB) or an upper vascular area boundary (UB); generating the congestion index for the patient based on at least one of the lower vascular area boundary or the upper vascular area boundary; 47. The method of claim 46.

48. Generating at least one of the lower vascular area boundary (LB) or the upper vascular area boundary (UB) comprises: Detecting operations within a trace of a receiving area; detecting a minimum vessel area corresponding to the detected manipulation; and Setting the vessel lower area boundary (LB) as the minimum vessel area detected Including, 48. The method of claim 47.

49. Generating at least one of the lower vascular area boundary (LB) or the upper vascular area boundary (UB) comprises: receiving the collapse value (C) and the mean area (A) of the area trace; receiving a reference gradient (S); and Setting the lower vascular area boundary (LB) equal to (-1 / S) C + Amean. Including, 48. The method of claim 47.

50. Generating at least one of the lower vascular area boundary (LB) or the upper vascular area boundary (UB) comprises: receiving a minimum area (A min ) of a selected number of area traces; and Using multiple measurements from an individual patient or population information from multiple patients, set the lower vessel area boundary (LB) as the average minimum sensor size measured at the IVC. Including, 48. The method of claim 47.

51. Generating at least one of the lower vascular area boundary (LB) or the upper vascular area boundary (UB) comprises: Detecting operations within a trace of a receiving area; detecting a maximum vessel area corresponding to the detected manipulation; and Setting the vessel upper area boundary (UB) as the maximum vessel area detected Including, 51. The method according to any one of claims 47 to 50.

52. Generating at least one of the vascular lower area boundary (LB) or the vascular upper area boundary (UB) comprises: receiving a collapsibility index value (CI) and a mean area (Amean) of the area trace; receiving a reference gradient (S); and Setting the vascular upper area boundary (UB) to (-1 / S)·CI+Amean Including, 51. The method according to any one of claims 47 to 50.

53. Generating at least one of the lower vascular area boundary (LB) or the upper vascular area boundary (UB) comprises: receiving a maximum vessel area (A) for a selected number of area traces; and Setting a vascular upper area boundary (UB) as the average maximum sensor size measured at the IVC using at least one of multiple measurements from the patient or population information from multiple patients. Including, 51. The method according to any one of claims 47 to 50.

54. 54. The method of any one of claims 47 to 53, further comprising determining a diagnostic status of the patient based at least on said congestion index.

55. The method of any one of claims 47 to 54, further comprising determining a patient treatment protocol based at least on said congestion index.

56. generating an alert to alert the user and identify the risk of hypovolemia when the congestion index is between about 0 and 30; notifying a user that the patient's fluid status is within normal range when the congestion index is between about 30 and 70; and When the congestion index is between about 70 and 100, an alert is generated to alert the user and identify the risk of hypervolemia.

56. The method of claim 54 or claim 55, further comprising:

57. 57. The method of any one of claims 54, 55 or 56, further comprising using the dataset training model to determine the likelihood of hospitalization of the patient based on a weighting of the congestion index and the plurality of additional generated cardiac function related parameters.

58. 2. The method of claim 1, further comprising generating a periodic vascular area trace of the patient.

59. generating the periodic vessel area trace, monitoring a change in vascular area using a transducer and generating a sensor signal representative of the monitored change; and Processing the sensor signal to generate said periodic area trace. Including, 59. The method of claim 58.

60. The monitoring includes: receiving a sensor signal from a sensor implanted in the IVC, the sensor signal being configured to generate a variable frequency signal correlating to a change in vascular area; Including, 60. The method of claim 59.

61. Generating the cardiac function related parameter comprises: The cardiac cycle interval (ti card ) and Heart rate (HR) is 1 / (ti card ) Including, 61. The method according to any one of claims 46 to 60.

62. Generating the cardiac function related parameter comprises: respiratory cycle (ti resp ) an interval time; and Respiratory rate (RR) is 1 / (ti resp ) Includes 62. The method according to any one of claims 46 to 61.

63. Generating the cardiac function related parameter comprises: receiving a maximum vessel area (Amax) and a minimum vessel area (Amin); and Set collapse (C) equal to Amax-Amin Including, 63. The method according to any one of claims 46 to 62.

64. Generating the cardiac function related parameter comprises: Receiving collapse (C) and maximum vessel area; and Set the Collapse Index (CI) equal to C / Amax * 100% Including, 64. The method according to any one of claims 46 to 63.

65. Generating the cardiac function related parameter comprises: receiving a cardiac component of collapse (Hcol), a respiratory component of collapse (Rcol), a heart rate (HR), and a respiratory rate (RR); and Define cardiac output (CO) as the sum of the product of Hcol x HR and the product of Rcol x RR. Including, 65. The method according to any one of claims 46 to 64.

66. Generating a patient congestion index receiving a maximum vessel area (Amax), a minimum vessel area (Amin), and a lower area boundary (LB); and Setting said congestion index equal to (Amax-Amin) / (Amax-LB)*100% Including, 66. The method according to any one of claims 46 to 65.

67. Generating a patient congestion index receiving a mean vessel area and an upper boundary; and Setting the congestion index equal to 100*(Amean / UB) Including, 66. The method according to any one of claims 46 to 65.

68. Generating a patient congestion index receiving a maximum vessel area (Amax), a minimum vessel area (Amin), a vessel upper area boundary (UB), and a vessel lower area boundary (LB); and setting said congestion index equal to 100*((Amean-LB) / (UB-LB)); Including, 68. The method according to any one of claims 46 to 67.

69. 69. The method of any one of claims 46 to 68, wherein the selected area trace features further include one or more of interval time per respiratory cycle, area magnitude of respiratory modulation, interval time per cardiac cycle, area magnitude of cardiac modulation, dominant cardiac peak, secondary cardiac peak, reduction in respiratory related area, type of maneuver, and maximum and minimum areas associated with the identified maneuver.

70. Producing the cardiac function related parameter includes generating one or more of a heart rate (HR), a respiratory rate (RR), a collapse index (CI), collapse (C) and cardiac output (CO).

70. The method according to any one of claims 46 to 69.

71. A method according to any one of claims 46 to 70, wherein the method is a computer-based method, wherein the steps are carried out on one or more processors.

Images