Real-time intradialytic hypotension prediction

Abstract

To provide a method and a system for a real-time intradialytic hypotension (IDH) prediction.SOLUTION: A system includes: acquiring past hemodialysis treatment data to be segmented into a set of machine learning training data according to temporal proximity to an IDH event; and training a machine learning model to predict an IDH event according to the set of machine learning training data.SELECTED DRAWING: Figure 3

Description

Related Applications

[0001] This application claims the benefit of U.S. Patent Application No. 16 / 897,430, filed June 10, 2020, entitled "REAL-TIME INTRADIALYTIC HYPOTENSION PREDICTION," and U.S. Provisional Patent Application No. 62 / 951,259, filed December 20, 2019, entitled "REAL-TIME INTRADIALYTIC HYPOTENSION PREDICTION," both of which are incorporated herein by reference in their entireties. [Background technology]

[0002] Intradialytic hypotension (IDH) is one of the most common complications encountered during hemodialysis. By some estimates, IDH occurs in up to 30 percent (30%) of all hemodialysis sessions. See, for example, Intradialytic hypotension: frequency, sources of variation, and correlation with clinical outcome. Sands JJ, Usvyat LA, Sullivan T, Segal JH, Zabetakis P, Kotanko P, Maddux FW, Diaz-Buxo JA. Hemodial Int. 2014 Apr;18(2):415-22. doi: 10.1111 / hdi.12138. Epub 2014 Jan 27).

[0003] IDH is a major risk factor for increased morbidity and mortality. For example, IDH can lead to dizziness, vomiting, loss of consciousness, and / or other complications. Managing IDH episodes requires significant staff attention and increases the overall cost of the procedure. Therefore, for these and / or other reasons, improving IDH risk management has become an important goal in many clinical settings. For example, the U.S. healthcare system appears to be moving toward a comprehensive care model for end-stage renal disease (ESRD), in which improved IDH risk management may be highly relevant to overall treatment outcomes.

[0004] The approaches described in this section were not necessarily conceived and / or pursued prior to the filing of the present application, and therefore, unless otherwise indicated, the approaches described in this section should not be construed as prior art. [Technical Field]

[0005] The present disclosure relates generally to predicting intradialytic hypotension. Summary of the Invention

[0006] One or more embodiments improve IDH prediction over prior approaches and enable real-time IDH prediction. One or more embodiments include machine learning that uses negative-class patient data (i.e., data from a time period before an IDH event when the patient was below the threshold for predicting IDH) and positive-class patient data (i.e., data from a time period before an IDH event when the patient was equal to or above the threshold for predicting IDH). The use of negative-class patient data can help the trained model distinguish between negative and positive conditions in real time. The use of negative-class patient data can also help prevent premature IDH predictions. One or more embodiments include machine learning that uses non-IDH-class patient data (i.e., data from patients who did not experience an IDH event). The use of non-IDH-class patient data can help the trained model distinguish between pre-IDH and non-IDH conditions in real time. One or more embodiments include machine learning that omits or otherwise ignores data in a time window immediately preceding an IDH event, for example, 15 minutes of data preceding the IDH event. Ignoring data in the time window immediately preceding an IDH event can help the trained model predict IDH events in real time with enough time for clinical intervention.

[0007] In general, in one aspect, one or more non-transitory computer-readable media store instructions that, when executed by one or more processors, cause the instructions to: acquire historical hemodialysis treatment data, the historical hemodialysis treatment data being segmented into sets of machine learning training data based on temporal proximity to an intradialytic hypotension (IDH) event; and train a machine learning model to predict an IDH event based on the sets of machine learning training data. The sets of machine learning training data may include a first set of machine learning training data labeled as a positive class, the first set including medical data recorded within a minimum period before the IDH event and a maximum period before the IDH event, where the minimum period is at least long enough to allow medical intervention before the IDH event and includes medical data recorded beyond the maximum period before the IDH event.

[0008] The one or more non-transitory computer-readable media may further store instructions that, when executed by the one or more processors, cause the instructions to: acquire real-time hemodialysis data associated with a hemodialysis patient; and apply the real-time hemodialysis data to a machine learning model to predict whether an IDH event is imminent for the hemodialysis patient. Based on the real-time hemodialysis data, the machine learning model may predict that an IDH event is not imminent. Based on the real-time hemodialysis data, the machine learning model may predict that an IDH event is imminent.

[0009] The one or more non-transitory computer-readable media may further store instructions that, when executed by the one or more processors, cause, in response to predicting an impending IDH event, to adjust, without human intervention, the hemodialysis patient's treatment to prevent the IDH event. Adjusting, without human intervention, the hemodialysis patient's treatment may include one or more of reducing the ultrafiltration rate, lowering the dialysate temperature, or mechanically repositioning the hemodialysis patient.

[0010] In general, in one aspect, a system includes at least one device including a hardware processor. The system is configured to perform operations including: acquiring historical hemodialysis treatment data, the historical hemodialysis treatment data being segmented into sets of machine learning training data based on temporal proximity to an intradialytic hypotension (IDH) event; and training a machine learning model to predict an IDH event based on the set of machine learning training data. The sets of machine learning training data may include a first set of machine learning training data labeled as a positive class, the first set including medical data recorded within a minimum period before the IDH event and a maximum period before the IDH event, where the minimum period is at least long enough to allow medical intervention before the IDH event and includes medical data recorded beyond the maximum period before the IDH event, and a second set of machine learning training data labeled as a negative class, the second set including medical data recorded beyond the maximum period before the IDH event.

[0011] The operations may further include obtaining real-time hemodialysis data associated with the hemodialysis patient and applying the real-time hemodialysis data to a machine learning model to predict whether an IDH event is imminent for the hemodialysis patient. Based on the real-time hemodialysis data, the machine learning model may predict that an IDH event is not imminent. Based on the real-time hemodialysis data, the machine learning model may predict that an IDH event is imminent.

[0012] The operations may further include, in response to predicting an impending IDH event, adjusting treatment of the hemodialysis patient without human intervention to prevent the IDH event. Adjusting treatment of the hemodialysis patient without human intervention may include one or more of reducing the ultrafiltration rate, lowering the dialysate temperature, or mechanically repositioning the hemodialysis patient.

[0013] In general, in one aspect, a method includes obtaining historical hemodialysis treatment data that is segmented into sets of machine learning training data based on temporal proximity to an intradialytic hypotension (IDH) event, and training a machine learning model to predict an IDH event based on the set of machine learning training data. The sets of machine learning training data may include a first set of machine learning training data labeled as a positive class that includes medical data recorded within a minimum period before the IDH event and a maximum period before the IDH event, where the minimum period is at least long enough to allow medical intervention before the IDH event and a second set of machine learning training data labeled as a negative class that includes medical data recorded beyond the maximum period before the IDH event.

[0014] The method may further include obtaining real-time hemodialysis data associated with the hemodialysis patient and applying the real-time hemodialysis data to a machine learning model to predict whether an IDH event is imminent for the hemodialysis patient. Based on the real-time hemodialysis data, the machine learning model may predict that an IDH event is not imminent. Based on the real-time hemodialysis data, the machine learning model may predict that an IDH event is imminent.

[0015] The method may further include, in response to predicting an impending IDH event, adjusting the hemodialysis patient's treatment without human intervention to prevent the IDH event. Adjusting the hemodialysis patient's treatment without human intervention may include one or more of reducing the ultrafiltration rate, lowering the dialysate temperature, or mechanically repositioning the hemodialysis patient.

[0016] One or more embodiments described and / or claimed herein may not be included in this Summary section.

[0017] Various aspects of at least one embodiment are described below with reference to the accompanying drawings, which are not intended to be drawn to scale. The drawings are included to provide illustration and a further understanding of the various aspects and embodiments, and are incorporated into and constitute a part of this specification, but are not intended to define the limits of the present disclosure. In the drawings, each identical or nearly identical component illustrated in the various drawings is represented by a like numeral. For clarity, some components may not be labeled in all drawings. [Brief explanation of the drawings]

[0018] [Figure 1] FIG. 1 is a block diagram of an example of a system according to one embodiment. [Figure 2] FIG. 1 is a block diagram of an example connected health system according to one embodiment. [Figure 3] FIG. 10 is a flow diagram of an example of operations for real-time intradialytic hypotension prediction according to one embodiment. [Figure 4A] FIG. 1 illustrates an example of a receiver operating curve according to one embodiment. [Figure 4B] FIG. 1 illustrates an example of a receiver operating curve according to one embodiment. [Figure 5] FIG. 1 is a block diagram of an example machine learning training dataset according to one embodiment. [Figure 6] 1 illustrates an example of threshold-based classification according to one embodiment. [Figure 7A] 1 illustrates example experimental results according to one embodiment. [Figure 7B] 1 illustrates example experimental results according to one embodiment. [Figure 7C] 1 illustrates example experimental results according to one embodiment. [Figure 7D] 1 illustrates example experimental results according to one embodiment. [Figure 7E] 1 illustrates example experimental results according to one embodiment. [Figure 7F]1 illustrates example experimental results according to one embodiment. [Figure 8] FIG. 1 is a block diagram of an example computer system according to one embodiment. DETAILED DESCRIPTION OF THE INVENTION

[0019] FIG. 1 is a block diagram of an example of a system 100 according to one embodiment. In one embodiment, the system 100 may include more or fewer components than those illustrated in FIG. 1. The components illustrated in FIG. 1 may be local or remote from one another. The components illustrated in FIG. 1 may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into a single application and / or machine. Operations described with respect to one component may instead be performed by another component.

[0020] In one embodiment, intradialytic hypotension (IDH) prediction service 102 refers to hardware and / or software configured to perform operations for real-time IDH prediction. Examples of operations for real-time IDH prediction are described below. Specifically, IDH prediction service 102 includes machine learning engine 104. Machine learning includes various techniques in the field of artificial intelligence that deal with computer-implemented, user-independent processes for solving problems with variable inputs. For example, one or more embodiments may use machine learning to predict the risk of IDH, predict the outcome of a treatment course, recommend alternative treatment courses, and / or provide other types of predictions, recommendations, and / or other information based on the real-time data described herein. Machine learning engine 104 may be configured to calculate a metric (e.g., a percentage, a decimal value, an integer value, a letter grade, and / or other types of metric, or a combination thereof) corresponding to the risk of an impending IDH event. The metric may be compared (i.e., by machine learning engine 104 and / or by another component of system 100) and compared to one or more thresholds as described herein.

[0021] In one embodiment, the machine learning engine 104 trains the machine learning model 106 to perform one or more operations. Training the machine learning model 106 uses training data to generate a function that, when given one or more inputs, calculates a corresponding output. The output may correspond to a prediction based on previous machine learning. In one embodiment, the output includes a label, classification, and / or categorization assigned to the provided input(s). The machine learning model 106 corresponds to a trained model for performing a desired operation(s) (e.g., labeling, classifying, and / or categorizing an input). The system 100 may use multiple machine learning engines and / or multiple machine learning models for different purposes.

[0022] In one embodiment, the machine learning engine 104 may use supervised learning, semi-supervised learning, unsupervised learning, reinforcement learning, and / or another training method, or a combination thereof. In supervised learning, labeled training data includes input / output pairs, where each input is labeled with a desired output (e.g., a label, classification, and / or categorization), also referred to as a supervisory signal. In semi-supervised learning, some inputs are associated with supervisory signals, while others are not. In unsupervised learning, the training data does not include supervisory signals. Reinforcement learning uses a feedback system in which the machine learning engine 104 receives positive and / or negative reinforcement in the process of attempting to solve a particular problem (e.g., optimize performance in a particular scenario according to one or more predefined performance criteria). In one embodiment, the machine learning engine 104 initially trains the machine learning model 106 using supervised learning and then continuously updates the machine learning model 106 using unsupervised learning.

[0023] In one embodiment, the machine learning engine 104 may use many different techniques to label, classify, and / or categorize inputs. The machine learning engine 104 may convert the inputs into feature vectors that describe one or more characteristics (“features”) of the inputs. The machine learning engine 104 may label, classify, and / or categorize the inputs based on the feature vectors. Alternatively or additionally, the machine learning engine 104 may use clustering (also called cluster analysis) to identify commonalities in the inputs. The machine learning engine 104 may group (i.e., cluster) the inputs based on their commonalities. The machine learning engine 104 may use hierarchical clustering, k-means clustering, and / or another clustering method, or a combination thereof. In one embodiment, the machine learning engine 104 includes an artificial neural network. The artificial neural network includes multiple nodes (also called artificial neurons) and edges between the nodes. The edges may be associated with corresponding weights that represent the strength of the connections between the nodes, which the machine learning engine 104 adjusts as the machine learning progresses. Alternatively or additionally, the machine learning engine 104 may include a support vector machine. A support vector machine represents inputs as vectors. The machine learning engine 104 may label, classify, and / or categorize the inputs based on the vectors. Alternatively or additionally, the machine learning engine 104 may use a naive Bayes classifier to label, classify, and / or categorize the inputs. Alternatively or additionally, given a particular input, the machine learning model 106 may apply a decision tree to predict an output for the given input. Alternatively or additionally, the machine learning engine 104 may apply fuzzy logic in situations where it is impossible or impractical to label, classify, and / or categorize the inputs within a fixed set of mutually exclusive options. The foregoing machine learning models 106 and techniques are described for illustrative purposes only and should not be construed as limiting one or more embodiments.

[0024] In one embodiment, system 100 includes a data repository 108. Data repository 108 is configured to store past hemodialysis treatment data, i.e., data about hemodialysis patients and the treatments provided to those patients. The past hemodialysis treatment data may include demographic data 110. Alternatively or additionally, the past hemodialysis treatment data may include comorbidity data 112. Alternatively or additionally, the past hemodialysis treatment data may include treatment data 114. Alternatively or additionally, the past hemodialysis treatment data may include laboratory data 116. Generally, when combined with the techniques described herein, intradialysis measurements such as systolic blood pressure (SBP), diastolic blood pressure (DBP), and ultrafiltration rate may enable previously unavailable insight into hemodynamics during hemodialysis and particularly around the time of an IDH event.

[0025] The past hemodialysis treatment data may include, for example, the number of days since the first day of dialysis, blood flow rate, diastolic flow rate, diastolic sitting blood pressure, fluid removed, pulse rate, systolic sitting blood pressure, ultrafiltration rate, change in systolic blood pressure (SBP) between measurements (e.g., between the current measurement, the measurement before the current measurement in the same session, and / or the pre-treatment measurement), change in diastolic blood pressure (DBP) between measurements (e.g., between the current measurement, the measurement before the current measurement in the same session, and / or the pre-treatment measurement), change in pulse rate between measurements, label or teacher signal (e.g., positive or negative for IDH), and time of treatment. duration (minutes), patient ethnicity (e.g., whether the patient is Hispanic), patient sex and / or gender, patient height, information about dialysis access point (e.g., whether the access point is an autologous subcutaneous arteriovenous (AV) fistula, a synthetic subcutaneous AV fistula, or a catheter), pre-procedure SBP, pre-procedure DBP, pre-procedure weight, pre-procedure temperature, prescribed dry weight, intradialytic weight gain (e.g., in kilograms), intradialytic weight gain rate, prescribed treatment time, dialysate sodium (Na), difference between serum and dialysate Na, and standardized protein catabolic rate (PCR). , fluid volume, balanced eKt / V delivered, pre-procedure urea, post-procedure urea, urea removal rate (URR), methoxypolyethylene glycol epoetin beta (e.g., Mircera) dose, albumin, alkaline phosphatase (ALP), basophils, bicarbonate, serum calcium, corrected calcium, chloride, creatinine, eosinophils, ferritin, hematocrit (hct), hemoglobin (hgb), lymphocytes, mean corpuscular hemoglobin (MCH), MCH concentration (MCHC), mean corpuscular volume (MCV), monocytes, neutrophils, neutrophil-lymphocyte ratio (NLR), phosphorus, hemoglobin Platelet count, potassium, red blood cell (RBC) count, RBC distribution width, serum Na, total iron-binding capacity (TIBC), transferrin saturation (TSAT), information on comorbidities (e.g., anemia, skin cancer, arrhythmia, cerebrovascular disease, congestive heart failure (CHF), chronic obstructive pulmonary disease (COPD), physical disability, drug and / or alcohol dependence, gastrointestinal bleeding, hepatitis, human immunodeficiency virus (HIV) / acquired immunodeficiency syndrome (AIDS), hyperparathyroidism, infection, ischemic heart disease (IHD), myocardial infarction (MI), peripheral artery disease (PAD) / atheromatous volume fraction (AVE), pneumonia,and / or whether the patient has another comorbidity), age at first day of dialysis, day of week of dialysis treatment, post SBP at last treatment, post DBP at last treatment, blood flow rate (QB) at last treatment, dialysis fluid flow rate (QD) at last treatment, post weight at last treatment, post weight gradient at last treatment, ultrafiltration volume at last treatment, ultrafiltration rate at last treatment, post temperature at last treatment, treatment time (minutes) at last treatment, treatment time gradient at last treatment, saline used at last treatment, online clearance (OLC) measurement, body mass index (BMI) at last treatment, lowest SBP during last treatment, lowest DBP during last treatment, lowest pulse rate during last treatment, whether an IDH event occurred during the last treatment, percentage of IDH events across all previous treatments, percentage of IDH events in the last n treatments (e.g., n=10), average of lowest pulse rate in the last n treatments (e.g., n=10), racial identity of the patient, and / or another type of data, or a combination thereof. ,

[0026] One or more items of the past hemodialysis treatment data may be represented as Boolean data (e.g., true / false, 0 / 1, yes / no, etc.). For example, Boolean data may be used to indicate whether a patient is Hispanic. Alternatively or additionally, one or more items of the past hemodialysis treatment data may be represented as numbers, letters, strings, or other data types. For example, measurements may be represented as numeric values.

[0027] In one embodiment, data repository 108 is any type of storage unit and / or device for storing data (e.g., a file system, a database, a collection of tables, or any other storage mechanism). Data repository 108 may include multiple different storage units and / or devices. The multiple different storage units and / or devices may or may not be of the same type, or may or may not be located at the same physical site. Furthermore, data repository 108 may be implemented or executed on the same computing system as one or more other components of system 100. Alternatively or additionally, data repository 108 may be implemented or executed on a computing system separate from one or more other components of system 100. Data repository 108 may be logically integrated with one or more other components of system 100. Alternatively or additionally, data repository 108 may be communicatively coupled to one or more other components of system 100 via a direct connection or a network. In FIG. 1, data repository 108 is illustrated as storing various types of information. Some or all of this information may be implemented and / or distributed across any of the components of system 100. However, this information is illustrated within data repository 108 for purposes of clarity and explanation.

[0028] In one embodiment, the machine learning engine 104 is configured to train the machine learning model 106 based on data stored in the data repository 108. As described in further detail below, the data may be segmented into sets of training data. The sets of training data may also be referred to as "classes" because they share one or more classification criteria. Each set may be labeled to indicate whether the data should be considered predictive of an IDH event. Specifically, the training data may be segmented into a "positive" class (i.e., treated as predictive of an IDH event) and a "negative" class (i.e., treated as not predictive of an IDH event). As described below, the data may be segmented according to temporal proximity to a recorded IDH event. Alternatively or additionally, the data may be segmented into different sets of training data according to whether the data was acquired during a treatment session that included an IDH event. For example, data acquired during a treatment session in which no IDH event occurred may be placed in the "negative" class (i.e., the same class or a different class). To help ensure that predictions are based on situations that still allow sufficient time for clinical intervention, data that precede the IDH event within a predefined time margin (e.g., 15 minutes) can be ignored. Data recorded after the IDH event can also be ignored.

[0029] In one embodiment, system 100 is configured to obtain real-time hemodialysis treatment data from a hemodialysis patient 126. A treatment device 120 is configured to provide hemodialysis treatment to the patient 126. One or more clinical sensors 122 (e.g., a blood pressure monitor, a heart rate monitor, a thermometer, etc.) may record real-time data associated with the treatment. The real-time data may be stored in data repository 108 and / or transmitted to IDH prediction service 102 to predict whether an IDH event is imminent for the patient 126. Alternatively or additionally, the prediction may be based on other data about the patient 126 and / or the treatment, for example, data obtained from a connected health system described below.

[0030] In one embodiment, the IDH prediction service 102 is configured to predict an IDH event based on a threshold probability. Specifically, given a set of real-time input data, the IDH prediction service 102 can determine a predicted probability of an impending IDH event. The IDH prediction service 102 may store one or more probability thresholds (not shown), which may be hard-coded or user-configurable. If the probability of an IDH event exceeds the probability threshold (or matches the probability threshold if the value is programmed to be inclusive, or is below the threshold if a lower value corresponds to a higher probability), the IDH prediction service 102 indicates that an IDH event is predicted, i.e., that an imminent occurrence is likely. Otherwise, the IDH prediction service 102 takes no action or indicates that an IDH event is not predicted. The IDH prediction service 102 may store multiple thresholds so that different corrective actions can be taken based on the relative severity of the patient's 126 condition (i.e., more extreme actions can be taken as the probability of an impending IDH event increases).

[0031] In one embodiment, a higher threshold may result in more false negatives, and a lower threshold may result in more false positives. Various techniques may be used to determine the threshold. For example, the system 100 may calculate a cost function or Youden's index, which is minimized or maximized depending on the nature of the function. A threshold may be individualized and applied to only one patient 126 based on the particular patient's 126 data (e.g., demographics, biological measurements, etc.). Alternatively, a threshold may be applied to multiple patients who have one or more data characteristics (e.g., demographics, biological measurements, etc.) in common. Alternatively, a threshold may be applied to all patients. Machine learning may be used to calculate one or more thresholds for individual patients and / or one or more groups of patients.

[0032] In one embodiment, when the IDH prediction service 102 predicts that an IDH event is imminent (e.g., when the IDH risk classification of the patient 126 reaches a threshold), the system 100 may generate an alert and / or adjust the treatment of the patient 126 to prevent the IDH event. The clinical management engine 118 refers to hardware and / or software configured to generate an alert and / or perform operations to adjust the treatment of the patient 126. The alert may be visual and / or audible. The clinical management engine 118 may be configured to generate recommendations for adjusting the treatment of the patient 126 and display the recommendations on the user interface 124. As described above, the machine learning engine 104 may be configured to generate the recommended adjustments. Alternatively or additionally, the clinical management engine 118 may be configured to generate recommendations without machine learning, for example, based on codified best practices.

[0033] In one embodiment, in response to the alert (which may or may not include a recommended course of action), the clinician may examine the patient 126, take additional measurements, and / or adjust the treatment course for the patient 126. For example, the clinician may adjust (e.g., decrease or stop) the patient's 126 ultrafiltration rate, modify the dialysate temperature (e.g., lower the temperature, which has been shown to be associated with a lower IDH rate), and / or otherwise adjust the dialysis treatment. Alternatively or additionally, the clinician may reposition the patient 126 (e.g., by raising the footrest of the dialysis chair and / or otherwise adjusting the angle of the bed or chair on which the patient 126 is positioned) to reduce the likelihood that an IDH event will actually occur.

[0034] In one embodiment, when the IDH prediction service 102 predicts that an IDH event is imminent, the system 100 may take action automatically, i.e., without human intervention. The system may take action to examine the patient 126, take additional measurements, and / or adjust the patient's 126 treatment course in response to the alert condition without requiring intervention by a human clinician. The clinical management engine 118 may be configured to send instructions to the treatment device 120 and / or one or more other devices to automatically adjust the patient's 126 treatment. For example, the clinical management engine 118 may send instructions to a hemodialysis machine to adjust the patient's 126 ultrafiltration rate, modify the dialysate temperature, and / or otherwise adjust the dialysis treatment. Alternatively or additionally, the clinical management engine 118 may send instructions to the bed or chair in which the patient 126 is located to reposition the patient 126. Data from the clinical sensor(s) 122 and / or treatment-adjusted outcomes for the patient 126 may be stored in the data repository 108 and / or transmitted to the machine learning engine 104 to update the machine learning model 106 based on the results.

[0035] In one embodiment, user interface 124 refers to hardware and / or software configured to facilitate communication between a user (e.g., a patient 126 and / or a medical professional) and IDH prediction service 102. User interface 124 renders user interface elements and receives input via user interface elements. User interface 124 may be a graphical user interface (GUI), a command line interface (CLI), a tactile interface, a voice command interface, and / or any other type of interface, or a combination thereof. Examples of user interface elements include check boxes, radio buttons, drop-down lists, list boxes, buttons, toggles, text fields, date and time selectors, command lines, sliders, pages, and forms.

[0036] In one embodiment, different components of the user interface 124 are specified in different languages. The behavior of the user interface elements may be specified in a dynamic programming language such as JavaScript. The content of the user interface elements may be specified in a markup language such as HyperText Markup Language (HTML), Extensible Markup Language (XML), or XML User Interface Language (XUL). The layout of the user interface elements may be specified in a style sheet language such as Cascading Style Sheets (CSS). Alternatively or additionally, aspects of the user interface 124 may be specified in one or more other languages, such as Java, Python, Perl, C, C++, and / or any other language, or combinations thereof.

[0037] In one embodiment, one or more components of system 100 are implemented on one or more digital devices. The term "digital device" generally refers to any hardware device that includes a processor. A digital device may refer to a physical device that runs an application or a virtual machine. Examples of digital devices include computers, tablets, laptops, desktops, netbooks, servers, web servers, network policy servers, proxy servers, general-purpose machines, special-function hardware devices, hardware routers, hardware switches, hardware firewalls, hardware network address translators (NATs), hardware load balancers, mainframes, televisions, content receivers, set-top boxes, printers, mobile handsets, smartphones, personal digital assistants ("PDAs"), wireless receivers and / or transmitters, base stations, communication management devices, routers, switches, controllers, access points, and / or client devices.

[0038] FIG. 2 is a block diagram of an example connected health (CH) system 200 according to one embodiment. In one embodiment, the CH system 200 may include more or fewer components than those illustrated in FIG. 2. The components illustrated in FIG. 2 may be local or remote from one another. The components illustrated in FIG. 2 may be implemented in software and / or hardware. Each component may be distributed across multiple applications and / or machines. Multiple components may be combined into one application and / or machine. Operations described with respect to one component may instead be performed by another component.

[0039] CH system 200 may be configured to be part of or communicate with a system such as system 100 of FIG. 1 . CH system 200 may include, among other things, a processing system 205, a CH cloud service 210, and a gateway (CH gateway) 220, which may be used in connection with network aspects of one or more systems described herein. Processing system 205 may include a server and / or cloud-based system that processes, compatibility checks, and / or formats medical information, including prescription information, generated in a clinic or hospital clinical information system (CIS) 204 in connection with the data transmission operations of CH system 200. CH system 200 may include appropriate encryption and data security mechanisms. CH cloud service 210 may include a cloud-based application that serves as a communications pipeline (e.g., facilitates the transfer of data) between components of CH system 200 via a connection to a network such as the Internet. Gateway 220 may serve as a communications device that facilitates communication between components of CH system 200. In various embodiments, gateway 220 may communicate with dialysis machines 202 (e.g., peritoneal dialysis machines or hemodialysis machines) and system 100 via a wireless connection 201, such as Bluetooth, Wi-Fi, and / or other suitable types of local or short-range wireless connections. Gateway 220 may also connect to CH cloud service 210 via a secure network (e.g., Internet) connection. Gateway 220 may be configured to send / receive data to / from CH cloud service 210 and to / from dialysis machines 202 and system 100. Dialysis machines 202 may poll CH cloud service 210 (e.g., via gateway 220) for available files, and dialysis machines 202 and / or system 100 may temporarily store available files for processing.

[0040] 3 is a flow diagram of an example of operations for real-time IDH prediction according to one embodiment. One or more of the operations illustrated in FIG. 3 may be modified, rearranged, or omitted altogether. Thus, the particular sequence of operations illustrated in FIG. 3 should not be construed as limiting the scope of one or more embodiments.

[0041] In one embodiment, a system (e.g., system 100 of FIG. 1 ) acquires historical hemodialysis treatment data (operation 302). The system may acquire treatment data from many different sources. For example, the system may acquire treatment data from a connected health system, as described above. Alternatively or additionally, the system may acquire data from a third-party medical record source, e.g., a source that provides medical data for research, data mining, etc. Embodiments should not be considered limited to any particular data source.

[0042] In one embodiment, the system segments the treatment data into sets or “classes” of machine learning training data based on one or more shared criteria (operation 304). Specifically, the training data may be segmented into a “positive” class (i.e., treated as predictive of an IDH event) and a “negative” class (i.e., treated as not predictive of an IDH event). As described below, the data may be segmented according to temporal proximity to a recorded IDH event. Alternatively or additionally, the data may be segmented into different sets of training data according to whether the data was acquired during a treatment session that included an IDH event. For example, data acquired during a treatment session in which an IDH event did not occur may be placed in a “negative” class (i.e., the same class or a different class). To help ensure that predictions are based on situations that still allow sufficient time for clinical intervention, data that precede the IDH event within a predefined time margin (e.g., 15 minutes) may be ignored. Data recorded after the IDH event may also be ignored. Alternatively or additionally, the system may receive data that has already been segmented into a set of machine learning training data, without the system having to perform the segmentation itself.

[0043] In one embodiment, the system trains a machine learning model to predict IDH events based on the segmented machine learning training data (operation 306). Techniques for training machine learning models are described in further detail above.

[0044] In one embodiment, the system acquires real-time hemodialysis data (operation 308). Specifically, the system acquires data from one or more clinical sensor(s) monitoring the hemodialysis patient's treatment. The system may also acquire other data associated with the patient, such as demographic data, etc. Generally, the system may acquire data that corresponds to data that can be used to train a machine learning model and thus predict an IDH event (alone or in combination with other data).

[0045] In one embodiment, the system applies the real-time hemodialysis data to a machine learning model (operation 310). Based on the real-time hemodialysis data, the machine learning model determines whether an IDH event is predicted, i.e., whether the real-time hemodialysis data indicates that the patient is facing an impending IDH event (decision 312). As described above, the system may predict an IDH event based on a threshold probability. Specifically, given a set of real-time input data, the system may determine a predicted probability of an impending IDH event. If the probability of an IDH event exceeds a probability threshold (or matches the probability threshold if the value is programmed to be inclusive, or is below the threshold if a lower value corresponds to a higher probability), the system indicates that an IDH event is predicted. Otherwise, the system takes no action or indicates that an IDH event is not predicted. The system may store multiple thresholds so that different corrective actions can be taken based on the relative severity of the patient's condition (i.e., more extreme actions can be taken as the probability of an impending IDH event increases).

[0046] In one embodiment, if an IDH event is predicted, the system responds by generating an alert and / or adjusting the hemodialysis patient's treatment (operation 314). The system may use machine learning to determine the adjustment. The system may use the same machine learning model used to predict the IDH event or a different machine learning model. The adjustment may be based on some or all of the same data used to predict the IDH event and / or other data not used to predict the IDH event. Alternatively or additionally, the system may determine the adjustment using organized best practices (e.g., organized decision trees based on a clinical decision process that may be performed by a medical professional). The system may issue a visual and / or audible alert. The alert may present recommended adjustments in a user interface for action by a human operator (e.g., the patient and / or medical professional). Alternatively or additionally, the system may make the adjustment automatically, for example, by sending instructions to the device (e.g., to adjust the ultrafiltration rate, modify the dialysate temperature, change the patient's position, and / or adjust the patient's treatment in some other way).

[0047] In one embodiment, the system determines a predicted outcome (operation 316). The system may determine the predicted outcome regardless of whether an IDH event was predicted and whether the hemodialysis patient's treatment was adjusted. Generally, the predicted outcome may refer to real-time hemodialysis data collected after the time the prediction was made. The system may update the machine learning model based on the predicted outcome (operation 318). In some examples, the system obtains real-time data and continuously updates the machine learning model (e.g., using unsupervised learning) regardless of whether an IDH event was predicted or whether it actually occurred.

[0048] For clarity, some detailed examples are described below. The components and / or operations described below should be understood as examples that may not be applicable to one or more embodiments. Therefore, the components and / or operations described below should not be construed as limiting the scope of one or more embodiments.

[0049] In one example, IDH was defined as an intradialytic systolic blood pressure (SBP) of less than 90 mmHg (additional IDH definitions are found in Flythe, Jennifer E et al. "Association of mortality risk with various definitions of intradialytic hypotension." Journal of the American Society of Nephrology: JASN vol. 26,3 (2015), which is incorporated herein by reference in its entirety). Two data sources were used to predict IDH. 1) Pre-procedure data, including demographic data, routine dialysis-specific measurements, laboratory values, and comorbidities; 2) Intradialytic clinical data documented in the Fresenius Medical Care Chairside Information System, including intradialytic blood pressure, dialytic heart rate, and intradialytic ultrafiltration rate. Static data included demographics and comorbidities, procedural data, and laboratory values. Chairside data during dialysis provided additional dynamic and static data. Multiple features were designed based on the measured information (e.g., through averaging and other mathematical functions based on measurements).

[0050] Historical hemodialysis data spanning 332,591 treatments from 2,628 patients were acquired. Eighty percent of the historical data was used to train a machine learning model. Specifically, in this example, the open-source software XGBoost was used. Other examples may use different machine learning software and / or techniques. The remaining 20% ​​of the historical data was treated as real-time data for research purposes and applied to the machine learning model to evaluate the model's predictive ability. Specifically, IDH predictions were performed every time intradialytic SBP was measured (typically approximately every 20–30 minutes). The minimum time margin before an IDH event (i.e., the time margin before IDH when data were ignored) was set to 15 minutes. This time margin was considered sufficient to implement preventive measures if an IDH event was predicted to be imminent.

[0051] As illustrated in Figure 4A, when the machine learning model was trained using 106 features, the receiver operating curve 400 had an area under the curve (AUC) greater than 0.9 (specifically, 0.91), indicating clinically acceptable sensitivity and specificity for IDH prediction along with a clinically acceptable false positive rate. As illustrated in Figure 4B, even when the machine learning model was trained using only 20 features, the receiver operating curve 402 still had an AUC of 0.9. In Figures 4A and 4B, the charts show, for each model, the relative importance (i.e., experimentally determined predictive value) of each factor shown on the chart.

[0052] 5 is a block diagram of an example machine learning training dataset according to one embodiment. As illustrated in FIG. 5, data may be segmented into training classes or ignored based on where the data lies on a conceptual data timeline 500, i.e., in temporal relation to a recorded IDH event 508. Specifically, pre-IDH data 506 that precedes the IDH event 508 within a certain time interval (e.g., 15 minutes or another time interval) may be ignored for machine learning purposes. Data that is older than the pre-IDH data 506 and still falls within a predetermined time period before the IDH event 508 (e.g., from 75 minutes pre-IDH to 15 minutes pre-IDH) may be segmented into a “positive” class 504. The positive class 504 corresponds to a preferred time period for predicting an IDH event 508, during which there is likely enough data to determine that an IDH event 508 is imminent and still have enough time to intervene to prevent the IDH event. Any older data (e.g., more than 75 minutes before the IDH event 508) may be segmented into the negative class 502. Post-IDH data 510 may be ignored.

[0053] FIG. 6 illustrates an example of threshold-based classification according to one embodiment. As illustrated in FIG. 6, a positive classification 602 occurs when the probability of an IDH event 606 exceeds (or in some examples meets) a classifier threshold 604. In the example of positive classification 602, the higher dashed line illustrates how setting the classifier threshold 604 too high can result in a false negative. A negative classification 608 occurs when an IDH event does not occur (as illustrated in FIG. 6) and / or when the probability of an IDH event does not reach a high enough threshold. In the example of negative classification 608, the lower dashed line illustrates how setting the classifier threshold 604 too low can result in a false positive.

[0054] 7A-7F illustrate example experimental results according to one embodiment. In these examples, "TP" refers to a true positive result (i.e., a positive predictive classification where an IDH event actually occurred), "TN" refers to a true negative result (i.e., a negative predictive classification where an IDH event actually did not occur), "FP" refers to a false positive result (i.e., a positive predictive classification where an IDH event actually did not occur), and "FN" refers to a false negative result (i.e., a negative predictive classification where an IDH event actually did occur).

[0055] In one embodiment, the system includes one or more devices, including one or more hardware processors, configured to perform any of the operations described herein and / or recited in any of the claims.

[0056] In one embodiment, one or more non-transitory computer-readable storage media store instructions that, when executed by one or more hardware processors, cause any of the operations described herein and / or recited in any of the claims.

[0057] Any combination of the features and functions described herein may be used in accordance with an embodiment. In the foregoing specification, embodiments have been described with reference to numerous specific details that may vary from implementation to implementation. Accordingly, the specification and drawings should be considered in an illustrative, rather than a restrictive, sense. The sole and exclusive indication of the scope of the invention, and what the applicant intends to be the scope of the invention, is the literal and equivalent scope of the set of claims issuing from this application, the specific form from which such claims are issued, including any subsequent amendments.

[0058] In one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices (i.e., computing devices specially configured to perform a particular function). The special-purpose computing device(s) may be hardwired to perform the techniques and / or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and / or network processing units (NPUs) permanently programmed to perform the techniques. Alternatively or additionally, the computing device may include one or more general-purpose hardware processors programmed to perform the techniques according to program instructions in firmware, memory, and / or other storage devices. Alternatively or additionally, the special-purpose computing device may combine custom hardwired logic, ASICs, FPGAs, or NPUs with custom programming to achieve the techniques. The special-purpose computing device may include desktop computer systems, portable computer systems, handheld devices, networking devices, and / or any other device(s) incorporating hardwired and / or program logic to implement the techniques.

[0059] 8 is a block diagram of an example computer system 800 according to one embodiment. Computer system 800 includes a bus 802 or other communication mechanism for communicating information, and a hardware processor 804 coupled to bus 802 for processing information. Hardware processor 804 may be a general-purpose microprocessor.

[0060] Computer system 800 also includes a main memory 806, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 802 for storing information and instructions executed by processor 804. Main memory 806 may also be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 804. Such instructions, when stored on one or more non-transitory storage media accessible to processor 804, render computer system 800 into a special-purpose machine customized to perform the operations specified in the instructions.

[0061] Computer system 800 further includes a read-only memory (ROM) 808 or other static storage device coupled to bus 802 for storing static information and instructions for processor 804. A storage device 810, such as a magnetic disk or optical disk, is provided and coupled to bus 802 for storing information and instructions.

[0062] Computer system 800 may be coupled via bus 802 to a display 812, such as a liquid crystal display (LCD), plasma display, electronic ink display, cathode ray tube (CRT) monitor, or any other type of device for displaying information to a computer user. An input device 814, including alphanumeric and other keys, may be coupled to bus 802 for communicating information and command selections to processor 804. Alternatively or additionally, computer system 800 may receive user input via cursor control 816, such as a mouse, trackball, trackpad, or cursor direction keys, for communicating directional information and command selections to processor 804 and controlling cursor movement on display 812. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allow the device to specify a position in a plane. Alternatively or additionally, computer system 800 may include a touchscreen. Display 812 may be configured to receive user input via one or more pressure-sensitive sensors, multi-touch sensors, and / or gesture sensors. Alternatively or additionally, computer system 800 may receive user input via a microphone, a video camera, and / or some other type of user input device (not shown).

[0063] Computer system 800 may implement the techniques described herein using customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with other components of computer system 800, cause computer system 800 to become a special-purpose machine or to be programmed. According to one embodiment, the techniques herein are performed by computer system 800 in response to processor 804 executing one or more sequences of one or more instructions contained in main memory 806. Such instructions may be read into main memory 806 from another storage medium, such as storage device 810. Execution of the sequences of instructions contained in main memory 806 causes processor 804 to perform the process steps described herein. Alternatively, or additionally, hardwired circuitry may be used in place of or in combination with software instructions.

[0064] The term "storage medium" as used herein refers to one or more non-transitory media that store data and / or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 810. Volatile media include dynamic memory, such as main memory 806. Common forms of storage media include, for example, floppy disks, flexible disks, hard disks, solid-state drives, magnetic tape or other magnetic data storage media, CD-ROMs or any other optical data storage media, any physical medium with patterns of holes, RAM, programmable read-only memory (PROM), erasable PROM (EPROM), FLASH-EPROM, non-volatile random access memory (NVRAM), any other memory chip or cartridge, content addressable memory (CAM), and ternary content addressable memory (TCAM).

[0065] Storage media is distinct from but may be used in conjunction with transmission media. Transmission media involves transferring information to and from storage media. Examples of transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise bus 802. Transmission media can also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0066] Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 804 for execution. For example, the instructions may initially be carried on a magnetic disk or solid state drive of a remote computer. The remote computer may load the instructions into its dynamic memory and send the instructions over a network via a network interface controller (NIC), such as an Ethernet controller or Wi-Fi controller. A NIC local to computer system 800 may receive the data from the network and place the data on bus 802. Bus 802 carries the data to main memory 806, from which processor 804 retrieves and executes the instructions. The instructions received by main memory 806 may optionally be stored on storage device 810 either before or after execution by processor 804.

[0067] Computer system 800 also includes a communication interface 818 coupled to bus 802. The communication interface 818 provides a two-way data communication coupling to a network link 820 that is connected to a local network 822. For example, communication interface 818 may be an Integrated Services Digital Network (ISDN) card, cable modem, satellite modem, or a modem that provides a data communication connection to a corresponding type of telephone line. As another example, communication interface 818 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. A wireless link may also be implemented. In any such implementation, communication interface 818 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

[0068] Network link 820 typically provides data communication through one or more networks to other data devices. For example, network link 820 may provide a connection through local network 822 to a host computer 824 or to data equipment operated by an Internet Service Provider (ISP) 826. ISP 826, in turn, provides data communication services through the world-wide packet data communication network now commonly referred to as the “Internet” 828. Both local network 822 and the Internet 828 use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 820 and through communication interface 818, which carry the digital data to and from computer system 800, are exemplary forms of transmission media.

[0069] Computer system 800 can send messages and receive data, including program code, through the network(s), network link 820 and communication interface 818. In the Internet example, a server 830 might transmit a requested code for an application program through Internet 828, ISP 826, local network 822 and communication interface 818.

[0070] The received code may be executed by processor 804 as it is received, and / or stored in storage device 810, or other non-volatile storage for later execution.

[0071] In one embodiment, a computer network provides connectivity between a set of nodes executing software utilizing the techniques described herein. The nodes may be local and / or remote from one another. The nodes are connected by a set of links. Examples of links include coaxial cable, unshielded twisted cable, copper cable, optical fiber, and virtual links.

[0072] A set of nodes implements a computer network. Examples of such nodes include switches, routers, firewalls, and network address translators (NATs). Another set of nodes uses the computer network. Such nodes (also called "hosts") may execute client processes and / or server processes. Client processes make requests for computing services (e.g., requests to run a particular application and / or retrieve a particular data set). Server processes respond by performing the requested service and / or returning corresponding data.

[0073] A computer network may be a physical network including physical nodes connected by physical links. A physical node is any digital device. A physical node may be a specific-function hardware device. Examples of specific-function hardware devices include a hardware switch, a hardware router, a hardware firewall, and a hardware NAT. Alternatively or additionally, a physical node may be any physical resource that provides computing power to perform a task, such as one configured to run various virtual machines and / or applications that perform respective functions. A physical link is a physical medium connecting two or more physical nodes. Examples of links include coaxial cable, unshielded twisted cable, copper cable, and optical fiber.

[0074] A computer network may be an overlay network. An overlay network is a logical network implemented on top of another network (e.g., a physical network). Each node in the overlay network corresponds to a respective node in the underlying network. Thus, each node in the overlay network is associated with both an overlay address (for addressing the overlay node) and an underlay address (for addressing the underlay node that implements the overlay node). An overlay node may be a digital device and / or a software process (e.g., a virtual machine, an application instance, or a thread). Links connecting overlay nodes may be implemented as tunnels through the underlying network. The overlay nodes at both ends of the tunnel may treat the underlying multi-hop path between them as a single logical link. Tunneling is achieved through encapsulation and decapsulation.

[0075] In one embodiment, a client may be local and / or remote to a computer network. A client may access a computer network through a private network or another computer network, such as the Internet. A client may communicate a request to the computer network using a communication protocol, such as the Hypertext Transfer Protocol (HTTP). The request is communicated through an interface, such as a client interface (e.g., a web browser), a program interface, or an application programming interface (API).

[0076] In one embodiment, a computer network provides connectivity between clients and network resources. The network resources include hardware and / or software configured to run server processes. Examples of network resources include processors, data storage, virtual machines, containers, and / or software applications. The network resources may be shared among multiple clients. The clients request computing services from the computer network independently of one another. The network resources are dynamically allocated to requests and / or clients on an on-demand basis. The network resources allocated to each request and / or client may be scaled up or down based on, for example, (a) the computing services requested by a particular client, (b) the aggregated computing services requested by a particular tenant, and / or (c) the aggregated computing services requested of the computer network. Such a computer network may be referred to as a "cloud network."

[0077] In one embodiment, a service provider offers a cloud network to one or more end users. Various service models may be implemented by the cloud network, including, but not limited to, Software-as-a-Service (SaaS), Platform-as-a-Service (PaaS), and Infrastructure-as-a-Service (IaaS). In SaaS, the service provider offers end users the ability to use the service provider's applications running on the network resources. In PaaS, the service provider offers end users the ability to deploy custom applications on the network resources. The custom applications may be created using programming languages, libraries, services, and tools supported by the service provider. In IaaS, the service provider offers end users the ability to provision the processing, storage, network, and other basic computing resources provided by the network resources. Any application, including an operating system, may be deployed on the network resources.

[0078] In one embodiment, various deployment models may be implemented by a computer network, including, but not limited to, private clouds, public clouds, and hybrid clouds. In a private cloud, network resources are provisioned for exclusive use by a specific group of one or more entities (as used herein, the term "entity" refers to a company, organization, person, or other entity). The network resources may be local and / or remote to the premises of the specific group of entities. In a public cloud, cloud resources are provisioned for multiple entities (also called "tenants" or "customers") that are independent of each other. In a hybrid cloud, the computer network includes a private cloud and a public cloud. An interface between the private cloud and the public cloud enables data and application portability. Data stored in the private cloud and data stored in the public cloud may be exchanged via an interface. Applications implemented in the private cloud and applications implemented in the public cloud may have dependencies on each other. Calls from applications in the private cloud to applications in the public cloud (and vice versa) may be made via an interface.

[0079] In one embodiment, the system supports multiple tenants. A tenant is a company, organization, enterprise, business unit, employee, or other entity that accesses shared computing resources (e.g., computing resources shared in a public cloud). One tenant may be isolated from another tenant (through operations, tenant-specific practices, employees, and / or identification to the outside world). The computer network and its network resources are accessed by clients corresponding to different tenants. Such a computer network may be referred to as a "multi-tenant computer network." Several tenants may use the same particular network resource at different times and / or simultaneously. The network resource may be local and / or remote to the tenant's premises. Different tenants may require different network requirements for the computer network. Examples of network requirements include processing speed, amount of data storage, security requirements, performance requirements, throughput requirements, latency requirements, resiliency requirements, quality of service (QoS) requirements, tenant isolation, and / or consistency. The same computer network may need to implement different network requirements required by different tenants.

[0080] In one embodiment, tenant isolation is implemented in a multi-tenant computer network to ensure that applications and / or data of different tenants are not shared with each other. Various tenant isolation techniques may be used. In one embodiment, each tenant is associated with a tenant ID. Applications implemented by the computer network are tagged with a tenant ID. Additionally or alternatively, data structures and / or datasets stored by the computer network are tagged with a tenant ID. A tenant is permitted to access a particular application, data structure, and / or dataset only if the tenant and the particular application, data structure, and / or dataset are associated with the same tenant ID. As an example, each database implemented by the multi-tenant computer network may be tagged with a tenant ID. Only tenants associated with the corresponding tenant ID may access the data in a particular database. As another example, each entry in a database implemented by the multi-tenant computer network may be tagged with a tenant ID. Only tenants associated with the corresponding tenant ID may access the data in a particular entry. However, a database may be shared by multiple tenants. A subscription list may indicate which tenants have permission to access which applications. For each application, a list of tenant IDs of tenants authorized to access the application is stored. A tenant is granted access to a particular application only if the tenant's tenant ID is included in the subscription list corresponding to the particular application.

[0081] In one embodiment, network resources (such as digital devices, virtual machines, application instances, and threads) corresponding to different tenants are separated into tenant-specific overlay networks maintained by a multi-tenant computer network. As an example, packets from any source device in a tenant overlay network can be sent only to other devices in the same tenant overlay network. An encapsulation tunnel can be used to prohibit any transmission from a source device on a tenant overlay network to a device in another tenant overlay network. Specifically, a packet received from a source device is encapsulated in an outer packet. The outer packet is sent from a first encapsulation tunnel endpoint (communicating with a source device in the tenant overlay network) to a second encapsulation tunnel endpoint (communicating with a destination device in the tenant overlay network). The second encapsulation tunnel endpoint decapsulates the outer packet to obtain the original packet sent by the source device. The original packet is sent from the second encapsulation tunnel endpoint to a destination device in the same specific overlay network.

Claims

1. When executed by one or more processors, obtaining historical hemodialysis treatment data that is segmented into a plurality of sets of machine learning training data based on temporal proximity to intradialytic hypotension (IDH) events; training a machine learning model to predict IDH events based on the plurality of sets of machine learning training data; One or more non-transitory computer-readable media having stored thereon instructions to cause the

2. The plurality of sets of machine learning training data include: a first set of machine learning training data labeled as a positive class, the first set comprising medical data recorded within a minimum period before an IDH event and within a maximum period before an IDH event, wherein the minimum period is at least long enough to medically intervene before the IDH event; a second set of machine learning training data labeled as a negative class, the second set comprising medical data recorded beyond the maximum period prior to an IDH event; 10. The one or more non-transitory computer-readable media of claim 1, comprising:

3. When executed by one or more processors, obtaining real-time hemodialysis data associated with a hemodialysis patient; applying the real-time hemodialysis data to the machine learning model to predict whether an IDH event is imminent in the hemodialysis patient; 10. The one or more non-transitory computer-readable media of claim 1, further storing instructions to:

4. 4. The one or more non-transitory computer-readable media of claim 3, wherein to predict an IDH event based on the multiple sets of machine learning training data, the machine learning model is configured to calculate a risk metric indicative of a predicted likelihood of an imminent IDH event.

5. 4. The one or more non-transitory computer-readable media of claim 3, wherein based on the real-time hemodialysis data, the machine learning model predicts that the IDH event is imminent.

6. When executed by one or more processors, and further storing instructions for, in response to predicting that the IDH event is imminent, adjusting treatment of the hemodialysis patient without human intervention to prevent the IDH event.

6. One or more non-transitory computer-readable media as recited in claim 5.

7. 6. The one or more non-transitory computer-readable media of claim 5, wherein adjusting the treatment of the hemodialysis patient without human intervention comprises one or more of: reducing an ultrafiltration rate, lowering a dialysate temperature, or mechanically repositioning the hemodialysis patient.

8. 1. A system comprising at least one device including a hardware processor, the system comprising: obtaining historical hemodialysis treatment data that is segmented into a plurality of sets of machine learning training data based on temporal proximity to intradialytic hypotension (IDH) events; training a machine learning model to predict IDH events based on the plurality of sets of machine learning training data; A system configured to perform operations comprising:

9. The plurality of sets of machine learning training data include: a first set of machine learning training data labeled as a positive class, the first set comprising medical data recorded within a minimum period before an IDH event and within a maximum period before an IDH event, wherein the minimum period is at least long enough to medically intervene before the IDH event; a second set of machine learning training data labeled as a negative class, the second set comprising medical data recorded beyond the maximum period prior to an IDH event; The system of claim 8 , comprising:

10. The operation is obtaining real-time hemodialysis data associated with a hemodialysis patient; applying the real-time hemodialysis data to the machine learning model to predict whether an IDH event is imminent in the hemodialysis patient; The system of claim 8 further comprising:

11. 11. The system of claim 10, wherein to predict an IDH event based on the multiple sets of machine learning training data, the machine learning model is configured to calculate a risk metric indicative of a predicted likelihood of an impending IDH event.

12. 11. The system of claim 10, wherein based on the real-time hemodialysis data, the machine learning model predicts that the IDH event is imminent.

13. The operation is and, in response to predicting that the IDH event is imminent, adjusting treatment of the hemodialysis patient without human intervention to prevent the IDH event. The system of claim 12.

14. 14. The system of claim 13, wherein adjusting the treatment of the hemodialysis patient without human intervention comprises one or more of: reducing ultrafiltration rate, lowering dialysate temperature, or mechanically repositioning the hemodialysis patient.

15. obtaining historical hemodialysis treatment data that is segmented into a plurality of sets of machine learning training data based on temporal proximity to intradialytic hypotension (IDH) events; training a machine learning model to predict IDH events based on the plurality of sets of machine learning training data; A method comprising:

16. The plurality of sets of machine learning training data include: a first set of machine learning training data labeled as a positive class, the first set comprising medical data recorded within a minimum period before an IDH event and within a maximum period before an IDH event, wherein the minimum period is at least long enough to medically intervene before the IDH event; a second set of machine learning training data labeled as a negative class, the second set comprising medical data recorded beyond the maximum period prior to an IDH event; The method of claim 15, comprising:

17. obtaining real-time hemodialysis data associated with a hemodialysis patient; applying the real-time hemodialysis data to the machine learning model to predict whether an IDH event is imminent in the hemodialysis patient; The method of claim 15 further comprising:

18. 18. The method of claim 17, wherein the machine learning model predicts that the IDH event is imminent based on the real-time hemodialysis data.

19. and, in response to predicting that the IDH event is imminent, adjusting treatment of the hemodialysis patient without human intervention to prevent the IDH event.

20. The method of claim 18.

20. 20. The method of claim 19, wherein adjusting the treatment of the hemodialysis patient without human intervention comprises one or more of: reducing ultrafiltration rate, lowering dialysate temperature, or mechanically repositioning the hemodialysis patient.

Images