Medical fluid delivery system including analytics for managing patient engagement and treatment adherence

Abstract

A medical fluid delivery system is disclosed that includes analytics for managing patient engagement and treatment adherence. In one example, an interface device receives treatment data from a dialysis patient undergoing dialysis. An analytics processor determines dialysis treatment parameter values ​​by comparing the treatment data with records of prescribed treatments or procedures. Dialysis treatment parameter values ​​may include lost treatment time parameters, lost stay time parameters, and / or days to treatment completion parameters. The analytics processor causes the dialysis treatment parameter values ​​to be displayed within a user interface on a clinician's device. The dialysis treatment parameter values ​​provide an indication of how well the patient adheres to the prescribed treatments or procedures and can be used by clinicians to help improve patient adherence if needed.

Description

Background Technology

[0001] Currently, getting patients to participate outside of a medical setting for extended periods is virtually impossible. Similar to starting a gym membership or buying a treadmill, many patients typically begin relatively actively. Initially, patients are willing to participate in self-administered medical treatments (e.g., medical fluid delivery treatments). These treatments are usually performed at the patient's home and / or clinic. For medical fluid delivery treatments, patients must connect themselves to the medical fluid delivery machine (or a container containing fluids for kidney failure treatment) to cleanse their blood and combat toxin buildup. Parts of the treatment may include administrative tasks that patients must perform, such as weighing themselves, measuring their blood pressure, and / or recording information related to their treatment. Clinicians frequently review patient records to ensure treatment is being performed as prescribed. Clinicians also review recorded data to determine if adjustments to treatment are needed.

[0002] Over time, patients become less enthusiastic because repetitive treatments lose their novelty and become just another routine duty. It's conceivable that patients would prefer more exciting, relaxing, or stimulating activities compared to self-administering medication or visiting the clinic multiple times a week for the same treatment. As many patients continue treatment, they sometimes begin to omit the additional tasks that accompany it. This omission of additional tasks and decreased enthusiasm for treatment can create gaps in the clinical supervision of ongoing care. As patients become more resistant to treatment, they may begin to skip treatment altogether, only attending for a portion of the prescribed time, or abandoning treatment entirely, risking their health in the process. Summary of the Invention

[0003] This document discloses a medical fluid data transfer system for determining and / or predicting patient compliance. The medical fluid data transfer system is configured to improve patient compliance by tracking how patients use or otherwise interact with medical fluid delivery machines (such as automated peritoneal dialysis (“APD”) machines). In some embodiments, the medical fluid data transfer system analyzes data from the medical fluid delivery machine to determine patient compliance with one or more prescribed treatments or procedures. If patient compliance has fallen below a predetermined threshold or is trending towards falling below a threshold, the medical fluid data transfer system may operate one or more evidence-based algorithmic models. As disclosed herein, the models are configured to provide clinicians with recommendations on how to improve patient compliance with one or more prescribed treatments or procedures by addressing potential problems the patient may be experiencing.

[0004] In some embodiments, the medical fluid data transfer system may alternatively or additionally include one or more artificial intelligence (“AI”) patient prediction models configured to identify patients at risk of discontinuing their care or falling below a prescribed compliance threshold. One or more AI patient prediction models are configured to determine a concern score, which indicates the probability that a given patient may discontinue care or fall below a desired compliance threshold. The AI ​​patient prediction model determines the concern score by considering care data from the medical fluid delivery machine and readily available patient information, as it is relevant to the prescribed treatment. Thus, the AI ​​patient prediction model is configured to accurately determine patient risk using readily available data without having to access third-party data or other medical data stored in the patient's medical records. In addition to providing a concern score, the example AI patient prediction models described herein are configured to provide visibility or insight into how the concern score is calculated. For example, the AI ​​patient prediction model may provide numerous important causes or attributes that contribute to the concern score. In some embodiments, the medical fluid data transfer system may generate compliance recommendations for clinicians based on important attributes identified by the AI ​​patient prediction model.

[0005] In addition to analyzing patient compliance with one or more prescribed treatments or procedures performed by a medical fluid delivery machine, the medical fluid data transfer system disclosed herein can also track alarm fatigue and / or determine if a patient is experiencing catheter problems. In one example, the medical fluid data transfer system can track the number and type of alarms generated by the medical fluid delivery machine for a specific patient. The medical fluid delivery machine can identify problems related to one or more prescribed treatments or procedures based on these alarms. The medical fluid delivery machine can then use one or more evidence-based and / or AI models to provide recommendations to avoid generating alarms for the patient or relevant clinician. The medical fluid data transfer system can also enable clinicians and / or patients to mute or resolve some alarms in an attempt to limit or avoid patient alarm fatigue.

[0006] In another example, the medical fluid data transfer system is configured to receive fill and discharge data from a medical fluid delivery machine to determine catheter status. If the fill or discharge time of one or more prescribed treatments or procedures is less than a specified threshold, the medical fluid delivery machine can determine that the patient's catheter is incorrectly placed or that a leak exists. Furthermore, if the fill or discharge time of one or more prescribed treatments or procedures exceeds a specified threshold, the medical fluid data transfer system can determine that the catheter is partially blocked or has a buildup of fibrin chains.

[0007] The example medical fluid data transfer system accordingly determines the overall situation of patient treatment outcomes, which is provided as compliance information. The medical fluid data transfer system can use the compliance information to provide recommendations and / or guidance to improve patient adherence to one or more prescribed treatments and / or procedures. Furthermore, the medical fluid data transfer system can predict patients at risk of reducing or completely discontinuing their treatment. Therefore, the medical fluid data transfer system disclosed herein improves patient adherence to one or more prescribed treatments or procedures by tracking and encouraging patient interactions with and use of one or more medical fluid delivery devices. In other words, the medical fluid data transfer system provides transparency in patient treatment, enabling clinicians to intervene early when treatment data indicates that a compliance problem is developing or is in its early stages. Therefore, this transparency allows clinicians to intervene before a patient's medical condition deteriorates.

[0008] The medical fluid data transfer system and methodology disclosed herein are applicable to fluid delivery in, for example, the diagnosis and treatment of plasma exchange, hemodialysis (“HD”), hemofiltration (“HF”), hemodiafiltration (“HDF”), and continuous renal replacement therapy (“CRRT”). The medical fluid data transfer system described herein is also applicable to peritoneal dialysis (“PD”), intravenous drug delivery, and nutritional fluid delivery. These therapies may be collectively referred to herein or generally individually as medical fluid delivery or diagnosis and treatment.

[0009] The aforementioned therapy can be provided by a medical fluid delivery machine that houses the components required for delivering medical fluids. This machine may include one or more pumps, valves, heaters (if needed), in-line medical fluid generation devices (if needed), sensors (such as any one or more of pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, etc.), a user interface, and a control unit. The control unit may employ one or more processors and memory to control the aforementioned devices. The medical fluid delivery machine may also include one or more filters, such as dialyzers or blood filters for cleaning blood and / or ultrafilters for purifying water, dialysis fluid, or other fluids.

[0010] The medical fluid delivery machine and medical fluid data transfer system and methodology described herein can be used in home-based machines. For example, the system can be used with home HD, HF, or HDF machines that operate at the patient's convenience. One such home system is described in U.S. Patent No. 8,029,454 (“'454 Patent”), filed November 4, 2004, assigned to the assignee of this application, and issued October 4, 2011, entitled “High Convection Home Hemodialysis / Hemofiltration And Sorbent System”. Other such home systems are described in U.S. Patent No. 8,393,690 (“'690 Patent”), filed August 27, 2008, and issued March 12, 2013, entitled “Enclosure for a Portable Hemodialysis System”. The full content of each of the above references is incorporated into this paper by way of citation, and is used as the basis for this paper.

[0011] As described in detail below, the medical fluid data transfer system and methodology of this disclosure can operate within an encompassing platform or system, which may include numerous machines (including many different types of devices), patients, clinicians, physicians, service personnel, electronic medical record (“EMR”) databases, websites, resource planning systems that process data generated through patient and clinician communications, and business intelligence. The medical fluid data transfer system and methodology of this disclosure operate seamlessly throughout the system without violating its rules and protocols.

[0012] In view of the disclosure herein, and without limiting this disclosure in any way, in a first aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspects listed herein. A system for managing patient compliance with prescribed treatments or procedures administered by an automated peritoneal dialysis (“APD”) machine includes a memory device storing records of the patient’s prescribed treatments or procedures, including the planned date of the treatment to be provided, the duration of the prescribed treatment, and the estimated treatment stay time. The memory device also stores treatment data generated by the APD machine. The treatment data indicates the duration of treatment, fluid stay time, and date of each dialysis treatment performed by the APD machine according to the prescribed treatment or procedure. The system also includes an interface device coupled to the APD machine via network communication. The interface is configured to receive treatment data from the APD machine. The system also includes an analysis processor communicatively coupled to the interface device and the memory device. The analysis processor is configured to store treatment data received by the interface device into a memory device, determine the lost treatment time parameter value as the difference or ratio between the prescribed treatment duration and the dialysis treatment duration, determine the lost residence time parameter value as the difference or ratio between the estimated prescribed treatment residence time and the fluid residence time of the dialysis treatment, and determine the treatment completion date parameter value as the difference or ratio between the planned date of treatment and the dialysis treatment date. The analysis processor is also configured to display the lost treatment time parameter value, the lost residence time parameter value, and the treatment completion date parameter value within the user interface on the clinician's device.

[0013] According to the second aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, otherwise the memory device includes a data structure that associates medical fluid delivery recommendations with at least one of a range of values ​​for a lost treatment time parameter, a range of values ​​for a lost residence time parameter, or a range of values ​​for days to complete treatment parameter.

[0014] According to a third aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspects listed herein, and the system also includes a guide processor communicatively coupled to a memory device. The guide processor is configured to compare at least one of a patient's lost treatment time parameter value, lost stay time parameter value, or treatment completion day parameter value with at least one corresponding range of lost treatment time parameter value, lost stay time parameter value range, or treatment completion day parameter value range, select at least one recommendation based on the comparison, and cause at least one recommendation to be displayed within a user interface on the clinician's device.

[0015] According to the fourth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, wherein the analysis processor is configured to store lost treatment time parameter values, lost stay time parameter values, and treatment completion date parameter values ​​in association with previous lost treatment time parameter values, previous lost stay time parameter values, and previous treatment completion date parameter values ​​from the patient's previous treatments to a memory device; to create a first graph using the current and previous lost treatment time parameter values ​​to show the patient's actual treatment time compared to the prescribed treatment duration, and to display the first graph in a first user interface of the clinician's device.

[0016] According to the fifth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, wherein the analysis processor is configured to create a second graph using current and previous lost stay time parameter values ​​to show the patient’s actual stay time compared to the estimated prescription treatment stay time, and to display the second graph in a second user interface of the clinician’s device.

[0017] According to the sixth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, wherein a patient's prescription treatment or procedure record includes at least one of a fill threshold or a drain threshold, and treatment data includes at least one of a fluid fill time or a fluid drain time. The analysis processor is configured to generate an alert if at least one of the fluid fill time, average weekly fluid fill times, fluid drain time, or average weekly fluid drain times exceeds at least one of the corresponding fill thresholds or drain thresholds.

[0018] According to the seventh aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein to alert or indicate problems with a patient's catheter.

[0019] According to the eighth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, wherein the patient's prescription treatment or procedure record includes at least one of a fill threshold or a discharge threshold, and the treatment data includes at least one of a fluid fill time or a fluid discharge time. The analysis processor is configured to generate an alert if at least one of the fluid fill time or the fluid discharge time exceeds the corresponding at least one of the fill threshold or the discharge threshold.

[0020] According to the ninth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, the fluid filling time including the average fluid filling time of a treatment cycle, and the fluid discharge time including the average fluid discharge time of a treatment cycle.

[0021] According to the tenth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein. A system for predicting a patient's cessation of prescribed treatment administered by an automated peritoneal dialysis (“APD”) machine includes a memory device storing a training dataset comprising diagnostic and treatment data for a patient group and patient data. The training data also includes indications regarding whether a patient has ceased prescribed treatment or a procedure. The memory device further stores at least one patient prediction model formed using the training dataset. The at least one patient prediction model includes at least the following inputs: (i) a count or frequency of alerts generated by the APD machine, (ii) information related to peritoneal dialysis cycles, (iii) patient blood pressure values, and (iv) patient weight values. The memory device also stores patient data and previous diagnostic and treatment data of a target patient undergoing prescribed treatment or a procedure. The system also includes an interface device coupled to the APD machine via network communication. The interface is configured to receive diagnostic and treatment data of the target patient from the APD machine. The system also includes a prediction processor communicatively coupled to the interface device and the memory device. The prediction processor is configured to store diagnostic and treatment data received by the interface device into a memory device, determine the attention score of the target patient by applying patient data, diagnostic and treatment data and previous diagnostic and treatment data of the target patient to at least one patient prediction model, and display the attention score in the user interface on the clinician's device.

[0022] According to the eleventh aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, with the focus score indicating the probability that the target patient will terminate treatment or reduce the frequency of at least one of the prescribed treatments or procedures.

[0023] According to the twelfth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, wherein the prediction processor is configured to identify the most important attention parameter that contributes to the attention score and to display an indication of the most important attention parameter within the user interface of the clinician device.

[0024] According to aspect thirteen of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, the memory device includes a data structure that correlates medical fluid delivery recommendations with a range of concern scores.

[0025] According to the fourteenth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, and the system also includes a guide processor communicatively coupled to a memory device. The guide processor is configured to compare the target patient's attention score with a range of attention scores, select at least one recommendation based on the comparison, and display at least one recommendation within a user interface on the clinician's device.

[0026] According to the fifteenth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, a method for managing patient compliance with a prescribed treatment or procedure administered by a dialysis machine, comprising receiving treatment data from the dialysis machine at an interface device. The treatment data indicates treatment duration, fluid residence time, and the date of dialysis treatment performed by the dialysis machine according to the prescribed treatment or procedure. The method further includes determining dialysis treatment parameter values ​​by comparing the treatment data with records of the prescribed treatment or procedure via an analysis processor communicatively coupled to the interface device. The records include the planned date for treatment to be delivered, the prescribed treatment duration, and the estimated prescribed treatment residence time. The dialysis treatment parameter values ​​include at least two of the following: a lost treatment time parameter value as the difference or ratio between the prescribed treatment duration and the dialysis treatment duration; a lost residence time parameter value as the difference or ratio between the estimated prescribed treatment residence time and the fluid residence time of the dialysis treatment; or a completed treatment date parameter value as the difference or ratio between the planned date for treatment to be delivered and the dialysis treatment date. The method also includes displaying at least two of the following parameters via an analysis processor: lost treatment time parameter, lost stay time parameter, or treatment completion day parameter, within the user interface on the clinician's device.

[0027] According to the sixteenth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, and the method further includes storing the received diagnostic and treatment data and records to a memory device via an analysis processor.

[0028] According to the seventeenth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, and the dialysis machine includes an automated peritoneal dialysis (“APD”) machine or a hemodialysis machine.

[0029] According to the eighteenth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, otherwise the patient's prescription treatment or procedure record includes at least one of a fill threshold or a discharge threshold, and the treatment data includes at least one of a fluid fill time or a fluid discharge time.

[0030] According to the nineteenth aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, and the method further includes at least one of the following: generating an alert via an analysis processor if at least one of the fluid filling time, the average number of fluid fillings per week, the fluid discharge time, or the average number of fluid discharges per week exceeds a corresponding at least one of a filling threshold or a discharge threshold, or generating an alert via an analysis processor if the fluid filling time or the fluid discharge time exceeds a corresponding at least one of a filling threshold or a discharge threshold.

[0031] According to aspect 20 of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein to alert or indicate to a patient that there is a problem with the catheter.

[0032] According to the twenty-first aspect of this disclosure, unless otherwise stated, this aspect may be used in combination with any other aspect listed herein, the method further comprising: accessing a data structure via an analysis processor, the data structure relating a medical fluid delivery recommendation to at least one of a range of lost treatment time parameter values, a range of lost residence time parameter values, or a range of days to complete treatment parameter values; comparing, via the analysis processor, at least one of a patient's lost treatment time parameter value, lost residence time parameter value, or day to complete treatment parameter value with at least one corresponding range of lost treatment time parameter value, lost residence time parameter value, or day to complete treatment parameter value; selecting at least one recommendation via the analysis processor based on the comparison; and displaying at least one recommendation within a user interface on a clinician's device via the analysis processor.

[0033] In the twenty-second aspect of this disclosure, Figures 1 to 20 Any one or more of the disclosed structures, functions, and alternatives may be related to Figures 1 to 20 It can be combined with any other structure, function, and alternative disclosed herein.

[0034] In view of this disclosure and the foregoing aspects, the advantage of this disclosure is that it provides an improved medical fluid delivery system.

[0035] Another advantage of this disclosure is that it helps determine patient compliance with prescribed treatments or procedures, preventing patients from prematurely ending treatment administered by a medical fluid delivery machine.

[0036] Another advantage of this disclosure is that it can predict patient adherence to prescription treatments or plans using a training dataset of patients who have undergone similar prescription treatments or procedures.

[0037] Another advantage of this disclosure is that it provides improved guidance and efficiency for clinicians or nurses.

[0038] Another advantage of this disclosure is that it provides improved patient outcomes for dialysis treatment.

[0039] Another advantage of this disclosure is that it provides a medical fluid data transfer system and methodology that can be applied to different types of medical fluid delivery machines.

[0040] Additional features and advantages are described in the following detailed description and accompanying drawings, and will be apparent from them. The features and advantages described herein are not exhaustive; in particular, many additional features and advantages will be apparent to those skilled in the art in light of the drawings and description. Furthermore, no particular embodiment need have all the advantages listed herein, and it is clearly contemplated that individual advantageous embodiments may claim their own. Moreover, it should be noted that the language used in the specification has been chosen primarily for readability and instructional purposes, and not for limiting the scope of the subject matter of the invention. Attached Figure Description

[0041] Figure 1 This is a schematic diagram illustrating a medical fluid data transfer system according to an embodiment of the present disclosure, the medical fluid data transfer system including at least one medical fluid delivery machine.

[0042] Figure 2 This is a schematic diagram of a medical fluid delivery device according to an embodiment of the present disclosure.

[0043] Figure 3 It is a clinical physician server according to embodiments of this disclosure. Figure 1 A schematic diagram of a medical fluid data transfer system.

[0044] Figure 4 Based on exemplary embodiments of this disclosure, Figure 3 The illustration shows a clinician server configured for the analysis and processing of diagnostic and treatment data from a medical fluid delivery system.

[0045] Figure 5 It is based on an exemplary embodiment of this disclosure, by Figure 3 and Figure 4 A diagram illustrating at least some of the calculations performed by the clinician server.

[0046] Figure 6 It is based on an exemplary embodiment of this disclosure, by Figure 3 and Figure 4 A diagram illustrating the sample dashboard user interface provided by the clinician server.

[0047] Figures 7 to 9 It is based on an exemplary embodiment of this disclosure, by Figure 3 and Figure 4 A diagram illustrating the example patient compliance analysis user interface provided by the clinician server.

[0048] Figure 10 and Figure 11 It is based on an exemplary embodiment of this disclosure, by Figure 3 and Figure 4A diagram illustrating the sample catheter analysis user interface provided by the clinician server.

[0049] Figure 12 and Figure 13 It is based on an exemplary embodiment of this disclosure, by Figure 3 and Figure 4 A diagram of the example alert analysis user interface provided by the clinician server.

[0050] Figure 14 It is an example embodiment of the present disclosure, having by Figure 3 and Figure 4 A diagram illustrating an example of a patient compliance user interface provided by a clinician server.

[0051] Figure 15 This is a flowchart of an example process for determining patient compliance, catheter, and alarm analysis data based on diagnostic data from a medical fluid delivery machine, according to an example embodiment of this disclosure.

[0052] Figure 16 Based on exemplary embodiments of this disclosure, Figure 3 The illustration shows a clinician server configured for predictive processing of diagnostic and treatment data from a medical fluid delivery machine.

[0053] Figure 17 It is based on an exemplary embodiment of this disclosure, by Figure 16 A diagram of the attention score user interface provided by the clinician server.

[0054] Figure 18 This is another illustration of a user interface for focusing on scores, based on an example embodiment of this disclosure.

[0055] Figure 19 It is an example embodiment of the present disclosure, having by Figure 16 A diagram illustrating the example patient attention score user interface provided by the clinician server.

[0056] Figure 20 This is a flowchart of an example process for predicting patient compliance using diagnostic data from a medical fluid delivery machine, according to an example embodiment of this disclosure. Detailed Implementation

[0057] This document discloses a medical fluid delivery system. An example medical fluid delivery system is configured to use diagnostic and treatment data from a medical fluid delivery machine to improve patient adherence to one or more prescribed treatments and / or procedures. The example medical fluid delivery system determines, for example, adherence analysis, which is provided to a clinician's device by a clinician treating a patient. Adherence information includes information indicating the extent to which a patient adheres to prescribed treatment over time. Adherence information may include the number of days the patient has completed prescribed treatment. Adherence information may also include lost treatment time and / or low fluid dwell time, which may be due to the patient prematurely ending prescribed treatment during treatment. Clinicians can use adherence information to determine whether changes to prescribed treatment are needed and / or whether patient intervention / education is required.

[0058] In some embodiments, compliance information may also include catheter analysis information, which compares the ejection and filling times of the administered treatment to the prescribed and / or threshold ejection and filling times of the prescribed treatment. Deviations in ejection and filling times from the prescribed and / or threshold times may indicate that the patient's catheter is not properly positioned or aligned. Such deviations may also indicate constipation or partial blockage of the catheter by fibrin chains. Clinicians can use catheter analysis information to determine whether patient compliance is affected by catheter performance and to take corrective measures for the catheter (e.g., replacement or repositioning).

[0059] In some embodiments, compliance information may further include alarm analysis information, which provides a summary of alarm types and alarm generation frequency. Clinicians can use alarm information to identify problems that patients may be experiencing. Alarm analysis information can also be used to enhance catheter analysis information and / or treatment compliance information. For example, an alarm may instruct a patient to skip filling and / or drainage time during treatment, thereby prematurely ending treatment.

[0060] In some embodiments, the medical fluid delivery system may use one or more evidence-based models to determine recommendations and / or guidelines for improving patient compliance. These recommendations and / or guidelines may be based on official guidelines provided by, for example, the International Society for Peritoneal Dialysis (ISPD), the National Kidney Foundation (NKF), and / or the NKF Disease Outcome Quality Initiative (DOQI). The medical fluid delivery system compares each patient's compliance analysis against a data structure that correlates compliance analysis values ​​with certain recommendations and / or guidelines. The medical fluid delivery system uses these comparisons to automatically deliver recommendations to clinicians and / or patients.

[0061] In some embodiments, the medical fluid delivery system may use one or more patient prediction models configured to identify patients deemed high-risk for reduced or discontinued care one week to one month in advance. These patient prediction models may include AI and / or machine learning models trained using prior care data from substantially all patients associated with the medical fluid delivery system. In addition to identifying patients at risk, the patient prediction models determine at least three to five contributing factors or attributes that influence the analysis. Clinicians can use this knowledge of contributing factors to determine interventions or risk mitigation steps to improve patient adherence to prescribed treatments or procedures. In some cases, the medical fluid delivery system uses one or more evidence-based models to automatically determine recommendations or guidelines for clinicians and / or patients based on identified contributing factors and / or risk scores.

[0062] This document refers to prescription treatments or procedures and corresponding treatments. A prescription treatment or procedure corresponds to one or more parameters that define how a medical fluid delivery machine operates to administer treatment to a patient. For peritoneal dialysis treatment, the parameters may specify the amount (or rate) of fresh dialysis fluid to be pumped into the patient's peritoneal cavity, the amount of time the fluid will remain in the patient's peritoneal cavity (i.e., residence time), and the amount (or rate) of used dialysis fluid and ultrafiltration (“UF”) to be pumped or discharged from the patient after the residence time has elapsed. For treatments with multiple cycles, the parameters may specify the fill volume, residence volume, and discharge volume for each cycle, as well as the total number of cycles to be performed during the treatment (where treatment is provided once a day, or separately during the day and night). In addition, the parameters (or device procedures) may specify the date / time / day on which the medical fluid delivery machine will administer treatment (e.g., scheduled). Furthermore, in addition to the concentration level of the dialysis fluid (such as dextran glucose level), the parameters of a prescription treatment may also specify the total volume of dialysis fluid to be administered for each treatment.

[0063] Although prescription treatments may specify parameters for each treatment provided by a medical fluid delivery machine, the treatment data reported by the machine may differ. As discussed herein, treatment data refers to data generated by the medical fluid delivery machine that indicates measured, detected, or determined parameter values. For example, while a prescription treatment may specify a treatment consisting of five separate cycles, each with a 45-minute residence time, the medical fluid delivery machine may administer treatments that provide fewer cycles, each with a 30-minute residence time. Discrepancies from prescription parameters may be due to the patient exceeding the treatment schedule or prematurely discontinuing treatment. The medical fluid delivery machine monitors how treatments are administered and provides parameters instructing operation accordingly. Parameters for treatment data may include, for example, the total amount of dialysis fluid administered to the patient, the number of cycles performed, the fill volume per cycle, the residence time per cycle, the discharge time / volume per cycle, the estimated amount of UF removed, the treatment start time / date, and / or the treatment end time / date. Treatment data may also include calculated parameters, such as the fill rate and discharge rate, determined by dividing the volume of fluid pumped by the time taken to pump. Treatment data may further include the identifier of alarms that occurred during treatment, the duration of the alarm, the time of the alarm, the event associated with the alarm, and / or indications of whether the problem that caused the alarm was resolved or whether the alarm was silenced.

[0064] In addition to treatment data, medical fluid delivery systems may use patient data. As disclosed herein, patient data can be determined from treatment data. For example, a medical fluid delivery system may determine a patient's level of experience with the medical fluid delivery machine based on the date of the treatment data. Additionally or alternatively, patient data may include demographic data that may be provided by a clinician / patient, prescribed in a treatment or procedure, and / or provided via a patient register. Demographic data may include patient age, sex, patient mobility level, patient renal condition, prescription history, etc. In some embodiments, patient data and / or treatment data may include identifiers that enable the medical fluid delivery system to store the received data in the appropriate patient record located in a database. Identifiers may include a patient identifier, patient name, and / or an identifier of the medical fluid delivery system.

[0065] This article also references analytical data. As discussed in more detail below, analytical data refers to diagnostic and treatment data that has been compared to one or more parameters of a prescribed treatment or procedure and / or to prescribed thresholds. Analytical data can represent the difference between parameter values ​​in the diagnostic and treatment data and their corresponding values ​​prescribed in the prescribed treatment. Analytical data can also represent the ratio between certain parameters of the diagnostic and treatment data and their corresponding parameters from the prescribed treatment and / or procedure (or prescribed limits / thresholds). Analytical data can represent comparisons of single treatments or trends over multiple treatments. Analytical data can also represent the output from one or more patient prediction models that use AI or machine learning to determine factors that may indicate a patient is likely to discontinue treatment or significantly reduce their application of the prescribed treatment or procedure.

[0066] As discussed herein, medical fluid delivery machines are located within a patient's residence. However, in some embodiments, medical fluid delivery machines may be located at full-service healthcare facilities and / or self-service healthcare facilities. In some embodiments, a patient may use a first medical fluid delivery machine located at their residence and a second medical fluid delivery machine located at a self-service healthcare facility. In these embodiments, the medical fluid delivery system is configured to combine treatment data from the first and second medical fluid delivery machines for at least one of compliance analysis, catheter analysis, alert analysis, and / or patient predictive analysis. In some cases, the medical fluid delivery system is configured to provide a detailed classification of report data comparing medical fluid delivery machine-based and / or home-based treatment with institution-based treatment.

[0067] I. Medical fluid delivery system examples

[0068] The example medical fluid delivery systems disclosed herein include one or more medical fluid delivery machines. One example of a medical fluid delivery machine is a kidney failure treatment machine. Regarding kidney failure treatment machines, a patient's kidney system may fail for various reasons. Kidney failure leads to several physiological disorders. For example, patients experiencing kidney failure are no longer able to balance water and minerals or excrete daily metabolic loads. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, etc.) accumulate in the patient's blood and tissues.

[0069] Kidney failure and declining kidney function are treated with dialysis. Dialysis removes waste, toxins, and excess water from the body, which normally functioning kidneys would otherwise remove. For many, dialysis is crucial as it is a life-saving treatment.

[0070] One type of treatment for kidney failure is hemodialysis (“HD”), which typically uses diffusion to remove waste products from a patient’s blood. A diffusion gradient exists across the semi-osmotic dialyzer between the patient’s blood and an electrolyte solution (called dialysate or dialysate fluid) to induce diffusion.

[0071] Hemofiltration (“HF”) is an alternative renal replacement therapy that relies on the convective transport of toxins in the patient’s blood. HF is achieved by adding a replacement or alternative fluid (typically 10 to 90 liters) to the extracorporeal circuit during treatment. During HF treatment, the replacement fluid and the fluid that accumulates in the patient between treatments are ultrafiltered, which provides a convective transport mechanism that is particularly beneficial for removing medium and large molecules (in hemodialysis, small amounts of waste are removed along with the fluid obtained between dialysis sessions; however, the solute drag generated by removing this ultrafiltrate is insufficient to provide convective clearance).

[0072] Hemodiafiltration (“HDF”) is a diagnostic and therapeutic procedure that combines convective and diffusion clearance. Similar to standard hemodialysis, HDF uses dialysate flowing through the dialyzer to provide diffusion clearance. Additionally, a replacement solution is supplied directly to the extracorporeal circuit to provide convective clearance.

[0073] Most hemodialysis (HF, HDF) treatments are performed at a center. There is a growing trend towards home hemodialysis (“HHD”) today, partly because HHD can be performed daily, offering superior treatment benefits compared to center hemodialysis treatments that are typically performed twice or three times a week. Studies have shown that more frequent treatments remove more toxins and waste products than patients receiving less frequent but potentially longer treatments. Patients receiving more frequent treatments do not experience as many downcycles as those at a center, where toxins have accumulated for two or three days before treatment. In some areas, the nearest dialysis center may be many miles from a patient's home, causing home visits to consume a large portion of the day. Conversely, HHD can occur at night or during the day when the patient is resting, working, or engaged in other production activities.

[0074] Another type of treatment for kidney failure is peritoneal dialysis, which involves infusing a dialysis solution (also called dialysis fluid) into the patient's peritoneal cavity via a catheter. The dialysis fluid comes into contact with the peritoneum of the peritoneal cavity. Due to diffusion and osmosis—that is, an osmotic gradient across the membrane—waste, toxins, and excess water enter the dialysis fluid from the patient's bloodstream through the peritoneum. The osmotic agent in dialysis provides this osmotic gradient. Used or spent dialysis fluid is drained from the patient, removing waste, toxins, and excess water from the body. This cycle is repeated, for example, multiple times.

[0075] There are various types of peritoneal dialysis treatments, including continuous ambulatory peritoneal dialysis (“CAPD”), automated peritoneal dialysis (“APD”), and tidal flow dialysis and continuous flow peritoneal dialysis (“CFPD”). CAPD is a manual dialysis treatment. Here, the patient manually connects the implanted catheter to the drain line so that used or spent dialysate fluid can be drained from the patient's peritoneal cavity. The patient then connects the catheter to a fresh dialysate bag to infuse fresh dialysate fluid into the patient's body through the catheter. The patient disconnects the catheter from the fresh dialysate bag, leaving the dialysate fluid in the peritoneal cavity, where waste, toxins, and excess water are removed. After the residence period, the patient repeats the manual dialysis process, for example, four times a day, with each treatment lasting between 1 and 6 hours. Manual peritoneal dialysis requires a significant investment of time and effort from the patient, leaving considerable room for improvement.

[0076] Automated peritoneal dialysis (“APD”) is similar to CAPD in that dialysis treatment involves drainage, filling, and retention cycles. However, APD machines perform cycles automatically, typically while the patient is asleep. APD machines free patients from having to manually perform treatment cycles and transport supplies during the day. An APD machine connects to an implanted catheter, a fresh dialysis fluid source or bag, and a fluid drainage tube. The APD machine pumps fresh dialysis fluid from the dialysis fluid source through the catheter and into the patient's peritoneal cavity. The APD machine also allows dialysis fluid to remain in the cavity and allows the transfer of waste, toxins, and excess water to occur. This source may include multiple sterile dialysis fluid bags.

[0077] An APD machine pumps used or discarded dialysate from the patient's peritoneal cavity into a drain line via a catheter. Similar to manual handling, several drain, fill, and retention cycles occur during dialysis. The "final fill" occurs at the end of APD and remains in the patient's peritoneal cavity until the next treatment.

[0078] Any of the above-mentioned machine-based therapies can be performed on a planned basis and may require initiation of a process. For example, dialysis patients are typically treated on a schedule prescribed by a medication or procedure, such as every other day, daily, etc. Blood therapy machines usually require a certain amount of time for setup before treatment, such as running a sterilization process. Patients undergoing these therapies may lead busy lives, with projects or errands to run on their scheduled treatment days.

[0079] The appeal of home healthcare to patients lies primarily in its lifestyle flexibility, allowing them to conduct treatment at home according to their own schedules. However, home medical fluid delivery devices may include software timers that give commands and constraints to patients. For example, a home hemodialysis system might require the patient to be physically present at the machine to initiate pre-treatment, during-treatment, and post-treatment sequences.

[0080] In one particular example, the treatment machine can reuse certain components by sterilizing them between treatments. The machine may employ one or more sterilization timers that require the patient or caregiver to begin treatment using the machine before the sterilization timer expires. Otherwise, the patient must wait until another sterilization process is complete before treatment can begin. In one embodiment, the treatment machine communicates the treatment start time deadline via the machine's graphical user interface.

[0081] The software of the system and methodology disclosed herein is designed to prevent communication between patients and / or caregivers and the machine when the machine is in a "patient-connected" software state. For example, if a clinician attempts to send a command to the machine currently treating a patient, the command might be intercepted by the middleware application, preventing it from being routed to the machine. The middleware application could then send a message back to the clinician informing them that the machine is busy and not accepting communication.

[0082] The examples described herein apply to any medical fluid delivery system that delivers medical fluids such as blood, dialysis fluids, replacement fluids, or intravenous medications (“IV”). These examples are particularly applicable to treatments for kidney failure, such as all forms of hemodialysis (“HD”), hemofiltration (“HF”), hemodiafiltration (“HDF”), continuous renal replacement therapy (“CRRT”), and peritoneal dialysis (“PD”), collectively or generally individually referred to herein as prescription treatments or procedures. Alternatively, the medical fluid delivery machine may be a drug delivery or nutrient fluid delivery device, such as a high-volume peristaltic pump or infusion pump. The machines described herein can be used in a home environment. For example, a machine operating with a data transfer component can be used with a home HD machine, which may, for example, operate while the patient is asleep at night. The medical fluid data transfer systems and methodologies disclosed herein may alternatively be used to assist clinicians or nurses in hospitals and / or clinics.

[0083] Please refer to the attached diagram, especially Figure 1 The illustration shows a medical fluid data transfer system 10. The example system 10 includes a number of medical fluid delivery machines 90 (one type of which will be discussed in detail below). The machines 90 of the medical fluid data transfer system 10 can be of the same type (e.g., all PD machines) or of different types (e.g., a mixture of HD, PD, CRRT, and medical or nutritional fluid delivery).

[0084] Although a single medical fluid delivery device 90 is illustrated as communicating with a connection server 118, system 10 manages the operation of multiple medical fluid delivery systems and machines of the same or different types as listed above. For example, there could be M hemodialysis machines 90, N hemofiltration machines 90, O CRRT machines 90, P peritoneal dialysis machines 90, Q home medication delivery machines 90, and R nutrition or medication delivery machines 90 connected to server 118 and operating with system 10. The numbers M to R can be the same or different numbers, and can be zero, one, or more than one. Figure 1 In the image, the medical fluid delivery machine 90 is shown as a treatment machine 90 (dashed line indicates the home).

[0085] The treatment unit 90 can receive purified water from the water treatment device 60 at its front end. In one embodiment, the water treatment device 60 is connected to the treatment unit 90 via an Ethernet cable. The treatment unit 90 in the illustrated embodiment operates in conjunction with other devices besides the water treatment device 60, such as a blood pressure monitor 104, a weighing scale (e.g., a wireless weighing scale 106), and a user interface (e.g., a wireless tablet user interface 122). In one embodiment, the treatment unit 90 is wirelessly connected to a server 118 via a modem 102. Each of these components can (but is not required to) be located in the patient's home, such as... Figure 1 As indicated by the dashed line. Any one, more, or all of components 60, 104, 106, and 122 can communicate with the treatment unit 90 via wired or wireless communication. Wireless communication can be via Bluetooth. TM WiFi TM , Wireless Universal Serial Bus (“USB”), infrared, or any other suitable wireless communication technology may be used. Alternatively, any one, more, or all of components 60, 104, 106, and 122 may communicate with the treatment unit 90 via wired communication.

[0086] Example connection server 118 communicates with medical fluid delivery machine 90 via medical device system hub 120. Example system hub 120 enables data and information about each treatment machine 90 and its peripherals to be propagated back and forth between machine 90 and other devices connected to server 118 via connection server 118. In the illustrated embodiment, system hub 120 is connected to service portal 130, enterprise resource planning system 140, web portal 150, business intelligence portal 160, HIPAA-compliant database 124, product development team 128, and electronic medical record databases 126a to 126n, such as those maintained in clinics or hospitals. Connection server 118 and / or portals 130, 150, and 160 may include gateway devices.

[0087] The illustrated electronic medical record (“EMR”) database may be located in clinics or hospitals 126a to 126n and stores electronic information about patients. System hub 120 may transmit data (e.g., treatment data) collected from log files of machine 90 to hospital or clinic databases 126a to 126n to merge or supplement the patient’s medical records. Databases 126a to 126n at clinics or hospitals may contain patient-specific treatment and prescription data (e.g., prescribed treatments or procedures), where access to such databases may be highly restricted. Example enterprise resource planning system 140 is configured to acquire and compile data generated via patient and clinician website access, such as complaints, accounting information, and lifecycle management information. Web portal 150 enables patients and clinics 152a to 152n that treat patients to access a publicly available website. Business intelligence portal 160 collects data from system hub 120 and provides the data to marketing 162, R&D 164, and quality / pharmacovigilance 166.

[0088] It should be understood that the systems, methods, and processes described herein can be implemented using one or more computer programs or components. The program of a component can be provided as a series of computer instructions on any computer-readable medium, including random access memory (“RAM”), read-only memory (“ROM”), flash memory, magnetic disk or optical disk, optical storage, or other storage media. The instructions can be configured to be executed by a processor, which, when executed, implements or facilitates the execution of all or part of the methods and processes disclosed herein.

[0089] In one embodiment, the treatment device 90 performs home-based treatment (such as home peritoneal dialysis) on a patient at home and then reports the treatment results (as treatment data) to a system hub 120, which can communicate with one or more servers. As described in more detail below, the one or more servers analyze the treatment data to report to the clinician, physician, and / or nurse responsible for managing the patient's health and comfort.

[0090] The treatment machine 90 in one embodiment uses, for example, Linux. TMThe operating system writes to a log file. The log file records relevant data from the treatment device 90, including peripheral device data. The log file may include any one or more of Extensible Markup Language (“XML”), comma-separated values ​​(“CSV”), or text files. The log file is placed in a file server repository managed by the software of the treatment device 90. It is also conceivable to store data on peripheral devices, such as the water diagnostic device 60, which is not sent to the machine 90. Such data can be obtained via wired or wireless connections to the peripheral devices, or downloaded via other data connections or storage media. For example, service technicians can access additional data via a laptop connected (e.g., via Ethernet) to the water diagnostic device 60 or the wireless weighing scale 106. Alternatively, additional data can be retrieved remotely from peripheral devices, where the treatment device 90 acts as a data transfer liaison between the peripheral devices and authorized clients of the medical fluid data transfer system.

[0091] In one embodiment, the treatment device 90 (e.g., via the Internet) uses a connectivity service to transfer diagnostic and treatment data between the modem 102 and the system hub 120. Here, a dedicated line can be provided in each patient's home for connecting the treatment device 90 to the connectivity server 118 via the modem 102. In one embodiment, the treatment device 90 uses a separate, for example, 3G, 4G, or 5G modem 102 to access the Internet. The modem 102 can use an Internet Service Provider (“ISP”), such as Vodafone. TM In one implementation, a connection agent 114, developed by a connection service provider (e.g., the provider of connection server 118), is installed on the treatment machine 90 and runs on the machine's main control processor (“ACPU”) 50. Axeda TM Axeda provides a suitable connection service. TM A secure management connection 116 is provided between the medical device and the connection server 118.

[0092] Figure 1 Example connection agent 114 is configured to enable treatment machine 90 to connect to connection server 118, and to transfer treatment data to and from connection server 118. The connection service operating via agent 114 and server 118 ensures that the connection to machine 90 is secure, ensures that data passes correctly through machine 90's firewall, detects data corruption or system crashes, and ensures that connection server 118 communicates with the correct treatment machine 90.

[0093] In one embodiment, the treatment machine 90 may connect to the connection server 118 only when the connection agent 114 is on or activated. During treatment and post-treatment sterilization, while the machine 90 and its peripherals are operating, in one embodiment, the connection agent 114 is automatically shut down. This prevents the treatment machine 90 from communicating with any entity and sending or receiving data during treatment and sterilization, or while the machine 90 is in use or running. In one embodiment, the ACPU 50 activates the connection agent 114 when the treatment machine 90 is idle, for example, after treatment and post-treatment sterilization are complete. In one embodiment, the connection agent 114 is shut down during treatment and may be shut down before treatment. After treatment, the connection agent 114 retrieves log files from the treatment machine 90 and uses the connection service to transfer treatment data to the connection server 118. The connection service routes data packets to their correct destinations, but in one embodiment, does not modify, access, or encrypt the data.

[0094] exist Figure 1 In the medical fluid data transfer system 10, a connection service via connection server 118 can transmit data to various locations, such as service portal 130, clinics or hospitals 126a to 126n, and web portal 150, via system hub 120. Connection server 118 enables service personnel 132a to 132n and / or clinicians to track and retrieve various assets on the network, such as appropriate treatment machines 90 and 3G, 4G, or 5G modems 102, and their associated information, including machine or modem serial numbers. Connection server 118 can also be used to receive and provide firmware upgrades, which are approved by the service personnel's supervisor 134 and obtained remotely via service portal 130, and provided to authorized treatment machines 90 and associated peripheral devices, such as water diagnostic equipment 60.

[0095] A. Example medical fluid delivery machine

[0096] For reference Figure 2 The diagram shows a schematic of the HD process for a medical fluid delivery machine 90. Because... Figure 2 HD systems are relatively complex, so Figure 2 The discussion also supports the treatments for renal failure discussed above, as well as any of the IV, drug delivery, or nutrient fluid delivery machines. Typically, the medical fluid delivery machine 90 is shown as a simplified version with a dialysis fluid or processing fluid delivery circuit. The blood circuit is also simplified, but not to the extent that the dialysis fluid circuit is simplified. It should be understood that the circuit has been simplified to make the description of this disclosure easier, and if implemented, the system will have additional structures and functions, as seen, for example, in the publications cited above.

[0097] Figure 2The medical fluid delivery device 90 includes a blood circuit 20. Example: Blood circuit 20 draws blood from and returns blood to patient 12. Blood is drawn from patient 12 via an arterial line 14 and returned to patient 12 via a venous line 16. Arterial line 14 includes an arterial line connector 14a connected to an arterial needle 14b, which is in blood draw communication with patient 12. Venous line 16 includes a venous line connector 16a connected to a venous needle 16b, which is in blood return communication with patient 12. Arterial line 14 and venous line 16 also include line clamps 18a and 18v, which may be spring-loaded, fail-safe mechanical throttling clamps. In one embodiment, line clamps 18a and 18v automatically close in an emergency.

[0098] Arterial line 14 and venous line 16 also include air or bubble detectors 22a and 22v, respectively, which may include ultrasound air detectors. Air or bubble detectors 22a and 22v are configured to detect air in arterial line 14 and venous line 16, respectively. If one of the air detectors 22a and 22v detects air, medical fluid delivery machine 90 closes line clamps 18a and 18v, pauses the blood and dialysis fluid pumps, and instructs the patient to purge the air, thereby allowing treatment to resume.

[0099] In the illustrated embodiment, blood pump 30 is located in arterial line 14. Blood pump 30 includes a first blood pump pod 30a and a second blood pump pod 30b. Blood pump pod 30a is operated using an inlet valve 32i and an outlet valve 32o. Blood pump pod 30b is operated using an inlet valve 34i and an outlet valve 34o. In one embodiment, each of blood pump pods 30a and 30b is a blood receiver comprising, for example, a rigid, spherical shell, with a flexible diaphragm located within the shell, forming a diaphragm pump. One side of each diaphragm receives blood, while the other side of each diaphragm is operated by negative and positive pressure. Alternatively, blood pump 30 may be a peristaltic pump operating with arterial line 14, or a plurality of peristaltic pumps operating with arterial line 14 and venous line 16.

[0100] like Figure 2 As shown, heparin bottle 24 and heparin pump 26 are located between blood pump 30 and blood filter 40 (such as a dialyzer). Heparin pump 26 can be a pneumatic pump or an injection pump (e.g., a stepper motor driven injection pump). Supplying heparin upstream of blood filter 40 helps prevent membrane clogging of the filter.

[0101] The main control processor (“ACPU”) or control unit 50 includes one or more processors and memory. The control unit 50 receives air detection signals from air detectors 22a and 22v (and other sensors of the medical fluid delivery machine 90, such as temperature sensors, blood leak detectors, conductivity sensors, pressure sensors, and access disconnect transducers 86, 88), and controls components such as line clamps 18a and 18v, blood pump 30, heparin pump 26, dialysis fluid pumps 64 and 96, and valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98o. Blood leaving the blood filter 40 via the intravenous line 16 flows through an airtrap 28. The airtrap 28 removes air from the blood before it is returned to the patient 12 via the intravenous line 16 after dialysis.

[0102] for Figure 2 The hemodialysis version of the medical fluid delivery machine 90 pumps dialysate fluid along the outer side of the membrane of the blood filter 40, while blood is pumped through the inner side of the blood filter membrane. Dialysis fluid preparation begins with water purification via a water purification unit 60. A suitable water purification unit is described in U.S. Patent Publication No. 2011 / 0197971, filed April 25, 2011, entitled “Water Purification System and Method,” the entire contents of which are incorporated herein by reference. In one embodiment, the water purification unit 60 includes a filter and other structures to purify tap water (e.g., remove pathogens and ions such as chlorine) such that, in one embodiment, the water concentration is below 0.03 endotoxin units / ml (“EU / ml”) and below 0.1 colony-forming units / ml (“CFU / ml”). The water purification unit 60 may be housed in a separate housing from the housing or chassis of the hemodialysis machine 90, which includes a blood circuit 20 and a dialysate fluid circuit 70.

[0103] For ease of explanation, Figure 2 The dialysis fluid circuit 70 in this paper is again highly simplified. The dialysis fluid circuit 70 can actually include all the relevant structures and functions described above in the publications incorporated herein by reference. Certain features of the dialysis fluid circuit 70 are... Figure 2 As shown in the illustration. In the illustrated embodiment, the dialysis fluid circuit 70 includes a dialysis fluid pump 64 leading to a blood filter. In one embodiment, the example pump 64 is configured identically to the blood pump 30. Similar to pump 30, pump 64 includes a pair of pump pods 66, each having an inlet valve 68i and an outlet valve 68o, which may also be in a ball configuration. Similar to blood pump 30, the two pump pods operate alternately, such that one pump pod is filled with HD dialysis fluid while the other pump pod is discharged from HD dialysis fluid.

[0104] Pump 64 is a dialysis fluid pump leading to a blood filter. Another dual-pod pump chamber 96 operates in conjunction with valves 98i and 98o located in the discharge line 82 to expel used dialysis fluid. A third pod pump (not shown) is present for pumping purified water through the bicarbonate tank 72. A fourth pod pump (not shown) is present for pumping acid from the acid container 74 into the mixing line 62. The third and fourth pumps can be single-pod pumps because, in one embodiment, continuous pumping in the mixing line 62 is less critical due to the buffer dialysis fluid tank (not shown) between the mixing line 62 and the dialysis fluid pump 64 leading to the blood filter.

[0105] A fifth pod pump (not shown) may be installed in the discharge line 82 to remove a known amount of ultrafiltrate (“UF”) during HD treatment. The medical fluid delivery system 90 tracks the UF pump to control and understand how much ultrafiltrate has been removed from the patient. The medical fluid delivery system 90 ensures that the necessary amount of ultrafiltrate is removed from the patient at the end of treatment.

[0106] Each of the pumps described above can also alternatively be a peristaltic pump operated using a pump tube. If so, according to the features of this disclosure, the system valves can still be pneumatically actuated.

[0107] In one embodiment, purified water from water purification unit 60 is pumped along mixing line 62 through bicarbonate cylinder 72. Acid from container 74 is pumped along mixing line 62 into the bicarbonate water flowing out of bicarbonate cylinder 72 to form an electrolytically and physiologically compatible dialysis fluid solution. The pumps and temperature-compensated conductivity sensors used for properly mixing the purified water with bicarbonate and acid are not shown, but are disclosed in detail in the publications described above and incorporated herein by reference.

[0108] Figure 2 The diagram also shows dialysis fluid being pumped along a fresh dialysis fluid line 76, through a heater 78 and an ultrafilter 80, and then to a blood filter 40. Used dialysis fluid is then pumped out via a drain line 82. The heater 78 heats the dialysis fluid to body temperature or approximately 37°C. Before reaching the blood filter 40, the ultrafilter 80 further cleans and purifies the dialysis fluid, filtering out foreign substances and / or contaminants introduced, for example, via a bicarbonate container 72 or an acid container 74.

[0109] The example dialysis fluid circuit 70 also includes a sampling port 84. The dialysis fluid circuit 70 may also include a blood leak detector (not shown, but used to detect whether the fibers of the blood filter 40 are torn) and other components not shown, such as a balancing chamber, multiple dialysis fluid valves, and a dialysis fluid holding tank, all of which are shown and described in detail in the publications cited above.

[0110] In the illustrated embodiment, the medical fluid delivery machine 90 is an in-line straight-through system that pumps dialysis fluid through a blood filter once and then pumps the used dialysis fluid to a discharge line. Both the blood circuit 20 and the dialysis fluid circuit 70 can be sterilized with hot water after each treatment, allowing them to be reused. In one embodiment, the blood circuit 20, including the blood filter 40, can be sterilized with hot water and reused daily for approximately one month, while the dialysis fluid circuit 70 can be sterilized with hot water and reused for approximately six months.

[0111] In an alternative embodiment, for example, for CRRT, multiple bags of sterile dialysis fluid or infusion solution are collected together and used sequentially. In this case, the emptied supply bag can be used as a drain bag or a used fluid bag.

[0112] Medical fluid delivery machine 90 includes Figure 2 The seal is shown by the dashed line. The seal of machine 90 varies depending on the type of treatment, whether the treatment is central or home-based, and whether the dialysis fluid / infusion solution supply is batch (e.g., bagged) or online.

[0113] In some embodiments, Figure 2 The medical fluid delivery machine 90 is configured to perform one or more prescription PD treatments or procedures. In these embodiments, the fresh dialysis fluid includes peritoneal dialysis dialysate, which comprises a solution or mixture having between 0.5% and 10%, preferably between 1.5% and 4.25% dextran (or more generally glucose). The peritoneal dialysis dialysate may include, for example, products sold by the assignee of this disclosure. and / or Dialysis fluid. Dialysis fluid may additionally or alternatively include a certain percentage of icodextrin.

[0114] In the PD embodiment, the blood circuit 20, including the blood filter, is removed. Instead, a fresh dialysis fluid line 76 is connected to a catheter placed near the peritoneal cavity of the patient 12. The catheter is also connected to a drain line 82, which removes used dialysis fluid, including accumulated UF. In some embodiments, the drain line 82 may be connected to a recirculation device, such as an adsorbent cartridge, configured to clean the used dialysis fluid before returning it to the patient's peritoneal cavity. In some cases, the recirculation device may remove uremic toxins from waste dialysis fluid and re-inject therapeutic agents (e.g., iontophoresis and / or glucose). A commonly used adsorbent is made of zirconium phosphate, used to remove ammonia generated from the hydrolysis of urea.

[0115] B. Example Connection Embodiment of a Medical Fluid Delivery System

[0116] Figure 3 Example embodiments according to this disclosure are shown. Figure 1 A schematic diagram of a medical fluid data transfer system 10. The example medical fluid data transfer system 10 includes, for example, a personal mobile communication device 122 operated by a patient and a clinician device 152 operated by a clinician. The medical fluid data transfer system 10 also includes a blood pressure monitor 104, a scale 106, and a treatment device 90 (e.g., a medical fluid delivery device), which are similar to the combination described above. Figure 1 and Figure 2 The corresponding equipment discussed. Personal mobile communication device 122, treatment machine 90, blood pressure monitor 104 and scale 106 can be located, for example, in the patient's home, self-service clinic and / or service medical clinic.

[0117] The treatment machine 90 may include any type of hemodialysis machine, peritoneal dialysis machine, CRRT machine, drug and / or nutrient fluid delivery machine, or combination thereof. The treatment machine 90 may provide, for example, continuous circulatory peritoneal dialysis (“CCPD”), tidal flow automated peritoneal dialysis (“APD”), and continuous flow peritoneal dialysis (“CFPD”). The treatment machine 90 may automatically perform discharge, filling, and residence cycles, typically while the patient is asleep.

[0118] The example therapeutic device 90 may also include one or more control interfaces 301 for displaying instructions and receiving control input from a user. The control interface 301 may include buttons, control panels, and / or a touchscreen. The control interface 301 may also be configured to allow the user to navigate to specific windows or user interfaces on the screen of the therapeutic device 90. The control interface 301 may also provide instructions for operating or controlling the therapeutic device 90.

[0119] Example treatment machine 90 can remotely receive one or more prescribed treatments or procedures from clinician server 304 and / or clinician database 306. Additionally or alternatively, treatment machine 90 can be locally programmed with prescribed treatments or procedures via control interface 301. As discussed herein, prescribed treatments include specifying how treatment machine 90 should treat a patient (e.g., Figure 1 Patient 12) Administers parameters for one or more planned treatments. In addition to the duration of each phase, treatment parameters may include the number of fill-stay-drain cycles of peritoneal dialysis treatment. Treatment parameters may also include the total volume of dialysis fluid to be administered (and / or the volume of fluid to be administered each week), dextran glucose concentration, and / or target UF removal level. Treatment parameters may also include the scheduled treatment date and total treatment duration. In some embodiments, the clinician server 304 may remotely update any of the prescribed treatment parameters.

[0120] Example blood pressure monitor 104 includes any device configured to measure a patient's blood pressure and / or pulse. For example, blood pressure monitor 104 can measure a patient's blood pressure before, during, and / or after treatment for renal failure. Blood pressure monitor 104 can display a numerical value indicating the patient's blood pressure. Alternatively, blood pressure monitor 104 can display a physical scale with a dial aligned with the numerical value to indicate the measured blood pressure. In some embodiments, blood pressure monitor 104 can store blood pressure values ​​before, during, and / or after treatment in a separate window, requiring patient input to view all values ​​when recording medical information. Blood pressure monitor 104 can be integrated with treatment device 90. In another embodiment, blood pressure monitor 104 can include wearable sensors, such as a smartwatch or fitness tracker. Blood pressure monitor 104 can transmit measured blood pressure values ​​(e.g., treatment data) to treatment device 90 and / or personal mobile communication device 122 via a wired or wireless connection, and then the measured blood pressure values ​​are routed to system hub 120 for processing.

[0121] Example scale 106 includes any device configured to measure the mass of a patient or treatment component. For example, scale 106 can measure a patient's weight before, during, and / or after treatment for renal failure. Additionally or alternatively, scale 106 can measure supply or discharge bags for tracking renal failure treatment. Specifically, scale 106 can be used to measure the amount of UF removed or the amount of fluid supplied to the patient. Scale 106 can display a digital value indicating the weight. Alternatively, scale 106 can transmit the measured weight value (e.g., treatment data) via a wired or wireless connection to treatment machine 90 and / or personal mobile communication device 122, and then route it to system hub 120 for processing.

[0122] Blood pressure monitor 104 and scale 106 are collectively referred to as medical devices. It should be understood that the medical fluid data transfer system 10 may include additional medical devices such as infusion pumps (e.g., syringe pumps, linear peristaltic pumps, high-volume pumps (“LVP”), portable pumps, multichannel pumps), oxygen sensors, respiratory monitors, blood glucose meters, blood pressure monitors, electrocardiogram (“ECG”) monitors, and / or heart rate monitors. In other examples, the medical fluid data transfer system 90 may include fewer medical devices and / or integrated medical devices (e.g., blood pressure monitor 104 integrated with the therapy machine 90).

[0123] like Figure 3 As shown, the treatment machine 90 communicates with the connection server 118 via network 302. (As described above...) Figure 1 and Figure 2As discussed, connection server 118 provides bidirectional communication between diagnostic machine 90 and system hub 120. Network 302 may include any wired or wireless network, including the Internet and / or cellular networks.

[0124] The example system hub 120 also communicates with a clinician server 304 and a clinician database 306. As described in more detail below, the clinician server 304 is configured to execute one or more instructions, routines, algorithms, applications, or programs 310 for analyzing diagnostic and treatment data. The clinician database 306 is configured to store prescribed treatments or procedures for each patient associated with system 10. The clinician database 306 is also configured to store one or more records for each patient, including diagnostic and treatment data and / or patient data from the corresponding treatment unit 90. The clinician database 306 may also store the results of analyses performed by the clinician server 304 on the diagnostic and treatment data and / or patient data. Furthermore, the clinician database 306 may store data structures that correlate diagnostic and treatment recommendations and / or guidelines specified by ISPD, NKF, and / or NKF DOQI with ranges of analytical values ​​corresponding to patient treatment compliance, catheter manipulation, and / or alarms.

[0125] like Figure 3 As shown, the example medical fluid data transfer system 10 includes a web portal 150 to facilitate data transfer via network 308 to clinician device 152 and / or personal mobile communication device 122. Example network 308 may include any wired and / or wireless network, such as the Internet and / or cellular networks. Web portal 150 may include one or more application programming interfaces (“APIs”) or other network interfaces that provide communication of diagnostic and treatment data, patient data, analytical data, and / or recommendations / guidelines. In some cases, web portal 150 may be configured as a gateway device and / or firewall, allowing only authorized users and / or devices to communicate with clinician server 304 and / or clinician database 306. Furthermore, web portal 150 may create separate sessions for each connected device 122 and 152.

[0126] Clinician device 152 and / or personal mobile communication device 122 may include application 320, configured to interface with web portal 150 for communication with clinician server 304 and / or clinician database 306. For example, application 320 may include one or more user interfaces having data fields (discussed further below) that display diagnostic data, patient data, and / or analytical data. These data fields are mapped to one or more APIs at web portal 150, which are linked to one or more data structures at clinician database 306 and / or clinician server 304. Selecting a user interface via application 320 causes a request message to be transmitted from application 320 to web portal 150, which identifies the data field associated with the requested user interface. The request message may also identify a patient. In response, web portal 150 transmits one or more request messages to clinician database 306 and / or clinician server 304 to retrieve diagnostic, patient, and / or analytical data associated with the identified patient and the identified data field.

[0127] In other cases, application 320 is a web browser configured to access one or more web pages hosted or managed by clinician server 304 via web portal 150. In these other instances, clinician server 304 provides a user interface and corresponding data fields in one or more web pages. Users can interact with the web browser to view or enter desired data. Application 320 may also include local controls or other installed applications on devices 122 and 152.

[0128] In some cases, web portal 150 is configured to convert diagnostic and / or analytical data from text-based standards or Health Level 7 (“HL7”) standards (e.g., medical standards) into web-based messages (e.g., HTTP messages, HyperText Markup Language (“HTML”) messages, Extensible Markup Language (“XML”) messages, JavaScript Object Notation (“JSON”) payloads, etc.). In other embodiments, connection server 118 is configured to convert HL7 diagnostic and therapeutic data from treatment device 90 into text-based or web-based formats (e.g., JSON format) for processing by clinician server 304 and storage in clinician database 306.

[0129] exist Figure 3In the illustrated example, the example personal mobile communication device 122 and clinician device 152 include a processor 322 that communicates with a memory 324 storing instructions. At least some of the instructions define or specify an application 320 that, when executed by the processor 322, causes the processor 322 to provide an interface for displaying and interacting with diagnostic data, patient data, and / or analytical data stored in a clinician database 306. The processor 322 may include digital and / or analog circuit systems structured as microprocessors, application-specific integrated circuits (“ASICs”), controllers, etc. The memory 324 includes volatile or non-volatile storage media. Furthermore, the memory 324 may include any solid-state or disk storage media.

[0130] II. Diagnosis and Treatment Analysis Examples

[0131] Figure 3 Example clinician server 304 is configured to analyze patient care data from treatment machine 90 (e.g., medical fluid delivery machine) to determine patient compliance with prescribed treatments or procedures. Figure 4 An illustration of a clinician server 304 according to an example embodiment of the present disclosure is shown. In the illustrated example, the clinician server 304 includes an application 310 configured as an analysis processor or engine 312a and an interface 310b. In some embodiments, the application 310 may also include a guide processor or engine 310c. Processors 310a to 310c are defined by one or more machine-readable instructions that specify how to process, store, and access diagnostic data for display on a clinician device 152 (and / or a personal mobile communication device 122).

[0132] A. Data Analysis Example

[0133] like Figure 4 As shown, the analysis processor 310a receives treatment data 402 from the self-treatment device 90. The treatment data 402 includes data 402a for determining compliance, data 402b for determining catheter operability, and data 402c for determining alarm fatigue. The self-treatment device 90 receives data 402 from one or more treatment log files. The analysis processor 310a is configured to parse or otherwise extract desired data from the log files using data tags, metadata, or pre-programmed knowledge about the placement of data in the files. In some embodiments, the self-treatment device 90 receives data 402 in a clinician database 306, and it is subsequently accessed by the analysis processor 310a.

[0134] In some embodiments, treatment data 402 may include identifiers for storing or organizing data in a clinician database 306. For example, treatment device 90 may include a device identifier and / or a patient identifier having data 402. Analysis processor 310a is configured to use the identifiers to store treatment data 402 and corresponding analysis data into the appropriate patient record in database 306. In some cases, analysis processor 310a may use the identifiers to distinguish whether treatment data 402 originates from treatment device 90 at a treatment site or from machine 90 located in a clinic. Analysis processor 310a may distinguish the location of treatment administration to determine whether the patient is more compliant at home or in a clinical setting.

[0135] In addition to treatment data 402, the example clinician database 306 may also store patient data 412. Patient data 412 includes patient-related information. Patient data 412 may include patient identifier, patient name, patient age, gender, (multiple) medical conditions, renal status information, and / or estimated experience level of the treatment device 90. Patient data 412 can be transferred from personal mobile communication device 122 and / or clinician device 152 to clinician database 306. In some embodiments, patient data 412 is provided when a patient registers with the medical fluid data transfer system 10 disclosed herein.

[0136] Treatment data 402a related to compliance includes indications of the date and / or time of treatment administered by the treatment machine 90. Treatment data 402a also includes the duration of treatment, and the measured dwell time for each treatment cycle (and / or the cumulative dwell time for all cycles). In some embodiments, treatment data 402a may also include the total volume of dialysis solution provided to the patient, the dextroglycerin level of the peritoneal dialysis fluid, an estimated amount of UF removed, and / or indications of treatment-related events occurring during treatment (e.g., treatment interruption).

[0137] Treatment data 402b related to catheter operability includes the filling time or rate for each cycle (and / or the cumulative filling time for all cycles). Treatment data 402b also includes the discharge time or rate for each cycle (and / or the cumulative discharge time for all cycles). In some cases, the analysis processor 310a is configured to calculate the average filling time and discharge time for all treatment cycles. In some embodiments, treatment data 402c may include indications of any alarms activated during treatment due to tubing blockage during the filling or discharge phase of a cycle, which may indicate a catheter that is at least partially blocked. Treatment data 402c may also include indications of any alarms activated during treatment due to fluid leakage during the filling or discharge phase of a cycle, which may indicate an misaligned catheter.

[0138] Treatment data 402c related to alarm fatigue includes alarm indications generated by the treatment machine 90 during treatment. Treatment data 402c may also include alarm type, alarm duration, and / or indications regarding whether the condition triggering the alarm was corrected or whether the patient silenced or ignored the alarm. Treatment data 402c may further include indications regarding whether the alarm escalated or whether treatment was terminated due to the alarm.

[0139] Figure 5 This describes an example embodiment based on the present disclosure, by Figure 4 The illustration shows at least some of the calculations performed by the analysis processor 310a. In an example embodiment, the analysis processor 310a is configured to compare diagnostic data 402 with one or more parameters 404 specified in a prescribed treatment or procedure. At least some of the parameters 404 may include general or patient-specific thresholds or limits. In the illustrated embodiment, the analysis processor 310a is configured to identify certain parameters from prescription treatments or procedures for a patient stored in a database 306. The analysis processor 310a may identify parameters 404 using data tags, field names, metadata, and / or text placement. Furthermore, in some embodiments, patient-specific or general thresholds or limits may be stored as parameters 404 in the clinician database 306.

[0140] like Figure 5 As shown, treatment data 402a may include a treatment duration parameter 402aa, which indicates the duration of treatment during which the treatment machine 90 administers the prescribed treatment. Analysis processor 310a is configured to compare or determine the difference between the treatment duration parameter 402aa and the prescribed treatment duration parameter 404a, indicating how long the treatment machine 90 should administer the treatment. The result of the comparison is stored as compliance analysis data 406a (i.e., lost treatment time parameter 406aa). The lost treatment time parameter 406aa indicates how much treatment time was lost due to premature termination of the analyzed treatment.

[0141] like Figure 4 As shown, the analysis processor 310a is configured to store the lost treatment time parameter 406aa into patient-related records in the clinician database 306. The value in the lost treatment time parameter 406aa can be added to a value from previous treatments to determine a cumulative lost treatment time parameter value. In some embodiments, the analysis processor 310a can determine the ratio of cumulative lost treatment time to total prescribed treatment time (for treatments already administered) to determine the percentage of treatment time lost due to early termination of treatment.

[0142] Back Figure 5Treatment data 402a may include a residence time parameter 402ab, which indicates how long the treatment machine 90 allows dialysis fluid to remain in the patient's peritoneal cavity before discharge. The residence time parameter 402ab may be an average of all treatment cycles or may include residence time values ​​for each cycle. Analysis processor 310a is configured to compare or determine the difference between the residence time parameter 402ab and an estimated residence time parameter 404b, which indicates the estimated residence time (e.g., based on expected or prescribed filling and discharge times). The result of the comparison is stored as compliance analysis data 406a (i.e., the lost residence time parameter 406ab). The lost residence time parameter 406ab indicates how much time of UF absorption was lost due to premature termination of the analyzed treatment (or a specific residence time).

[0143] like Figure 4 As shown, the analysis processor 310a is configured to store the stay time parameter 406ab in patient-related records in the clinician database 306. Multiple values ​​in the stay time parameter 406ab can be added to or combined with values ​​from previous treatments to determine a cumulative lost stay time parameter value. In some embodiments, the analysis processor 310a can determine the ratio of cumulative lost stay time to total estimated stay time (for treatments already administered) to determine the percentage of stay time lost due to the early termination of treatment (or individual stays).

[0144] Back Figure 5 Treatment data 402b may include a discharge time parameter 402ba, which indicates the length of time it takes for the treatment machine 90 to discharge UF and dialysis fluid from the patient's peritoneal cavity. Discharge time parameter 402ba may include a value for each cycle during treatment or an average of all cycles. Analysis processor 310a is configured to compare or determine the difference between discharge time parameter 402ba and one or more thresholds 404c. A discharge time value greater than a first threshold indicates that it takes longer than expected to discharge dialysis fluid and UF from the patient, which may be due to partial blockage in the catheter. A discharge time value less than a second threshold may indicate that it takes less than expected to discharge dialysis fluid and UF from the patient, which in some cases may be due to fluid leakage caused by catheter misplacement. The results of the comparison are stored as catheter analysis data 406b (i.e., difference parameter 406ba). If an alert is to be generated, analysis processor 310a is configured to transmit the alert to clinician device 152.

[0145] like Figure 4As shown, the analysis processor 310a is configured to store catheter analysis data 406b in patient-related records within the clinician database 306. Multiple values ​​and / or alarm indications in the catheter analysis data 406b can be combined with values ​​and / or alarm indications from previous treatments to determine a cumulative discharge time trend. In some embodiments, the analysis processor 310a can determine an average discharge time over 7, 30, 50, 90, and / or 180 days, or an average of the most recent discharge time, for display in the user interface.

[0146] Back Figure 5 Treatment data 402b may include a filling time parameter 402bb, which indicates the length of time elapsed for the treatment machine 90 to fill the patient's peritoneal cavity with dialysis fluid. The filling time parameter 402bb may include a value for each cycle during treatment or an average of all cycles. Analysis processor 310a is configured to compare or determine the difference between the filling time parameter 402bb and one or more thresholds 404d. In some embodiments, a filling time value less than a first threshold indicates that the time spent filling the patient's peritoneal cavity with fluid is less than expected, possibly due to catheter misplacement. A filling time value greater than a second threshold indicates that the time required to fill the patient's peritoneal cavity with fluid is longer than expected, possibly due to partial blockage in the catheter. The results of the comparison are stored as catheter analysis data 406b (i.e., difference parameter 406bb). If an alert is to be generated, analysis processor 310a is configured to transmit the alert to clinician device 152.

[0147] like Figure 4 As shown, the analysis processor 310a is configured to store catheter analysis data 406b in patient-related records within the clinician database 306. Multiple values ​​and / or alarm indications in the catheter analysis data 406b can be combined with values ​​and / or alarm indications from previous treatments to determine a cumulative filling time trend. In some embodiments, the analysis processor 310a can determine an average filling time over one to two weeks or an average of the most recent filling time for display in the user interface.

[0148] return Figure 5 The treatment data 402c may include alarm parameters 402c, which indicate alarms generated during treatment. Alarm parameters 402c may specify the type of alarm generated, the time of alarm generation, the duration of the alarm, whether the conditions triggering the alarm have been restored, or whether the alarm has been ignored, silenced, or escalated. Alarm parameters 402c are compared to one or more thresholds 404e. If the number of alarms generated during treatment exceeds the threshold, the patient may be experiencing alarm fatigue. Therefore, the analysis processor 310a is configured to create alarm parameters 406, which are transmitted to the clinician device 152, indicating possible alarm fatigue.

[0149] like Figure 4 As shown, the analysis processor 310a is configured to store alarm analysis data 406c in patient-related records within the clinician database 306. Multiple values ​​and / or alarm indications in the alarm analysis data 406c can be combined with values ​​and / or alarm indications from previous treatments to determine the total number of alarms or the average number of alarms generated per treatment session. In some embodiments, the analysis processor 310a can determine the average number of alarms generated when a patient uses a machine 90 at home relative to a machine 90 located in a clinic.

[0150] It should be understood that the analysis processor 310a can analyze and / or compare other diagnostic and treatment data parameters. For example, the analysis processor 310a can compare the estimated UF removed during treatment with the prescribed amount of UF to be removed to determine the patient's closeness to treatment goals. The analysis processor 310a can compare the actual dialysis fluid administered to the patient during treatment with the prescribed amount. The analysis processor 310a can also compare dextroglucose levels with the prescribed dextroglucose levels to ensure the patient is using the prescribed dialysis fluid. Furthermore, the analysis processor 310a can track how the patient's blood pressure and / or weight changes over time to detect potential fluid accumulation. In these cases, the analysis processor 310a can compare blood pressure and / or weight with baseline patient blood pressure or weight and / or rate of change thresholds.

[0151] Figure 4 In some embodiments, application 310 of clinician server 304 includes interface 310b, which is communicatively coupled to analytics processor 310a and clinician database 306. In other embodiments, interface 310b may be included with web portal 150. Example interface 310b is configured to read or otherwise obtain diagnostic data 402, analytics data 406, and / or patient data 412. Interface 310b may include one or more APIs for retrieving data 402, 404, 406, and / or 412 from clinician database 306.

[0152] Example interface 310b is configured to receive request messages from application 320 on personal mobile communication device 122 and / or clinician device 152. The request message may identify, for example, a user interface, data fields, and / or web pages for display. The request message may also identify a session and / or patient. In response to the request message, interface 310b creates a response document 420 including the requested data. To create document 420, interface 310b accesses the requested patient record in clinician database 306 and identifies the requested data 402, 404, 406, and / or 412. The data may include singular values ​​or trends over time corresponding to charts displayed by the user interface. Interface 310b organizes the retrieved data into response document 420 via data fields for addition to the appropriate user interface by application 320. Interface 310b may also tag or provide metadata identifiers for the data, enabling application 320 to store the data in appropriate data fields or variables. The response document 320 may also include web page code (e.g., HTTP code or JavaScript code) that defines how the requested data will be displayed in the web browser application 320. Interface 310b transmits the response document 420 to the personal mobile communication device 122 and / or the clinician device 152 via web portal 150.

[0153] In some embodiments, the analysis processor 310a may transmit newly processed analysis data 406 to the interface 310b. In response, the interface 310b may update the user interface at the personal mobile communication device 122 and / or the clinician device 152 in near real-time. In alternative embodiments, instead of the interface 310b, the analysis processor 310a transmits all analysis data 406 to the clinician database 306. In these alternative embodiments, the interface 310b accesses the analysis data 406 from the clinician database 306 at periodic intervals (e.g., 2 seconds, 5 seconds, 10 seconds, 30 seconds, 1 minute, 5 minutes, 10 minutes, etc.) to update the user interface on the personal mobile communication device 122 and / or the clinician device 152.

[0154] Figures 6 to 13 An example user interface is shown, created, presented, or otherwise provided by an application 320 on a personal mobile communication device 122 and / or a clinician device 152 using at least some data 402, 404, 406, and / or 412 from a clinician database 306, according to an example embodiment of the present disclosure. Figure 6An illustration of an example dashboard user interface 600 according to an exemplary embodiment of this disclosure is shown. The dashboard user interface 600 provides an overview of a specific patient's compliance with one or more prescribed treatments or procedures administered by one or more treatment devices 90 (e.g., medical fluid delivery devices). The user interface 600 may be displayed by an application 320 on a clinician device 152 after selecting a patient's name from, for example, a list of patients being treated or otherwise supervised by the clinician. The user interface 600 may be displayed as a homepage or loading page by an application 320 on a personal mobile communication device 122, since patients are not allowed to see information about other patients.

[0155] User interface 600 includes a trigger section 602. In the illustrated example, trigger section 602 displays the current values ​​of compliance analysis data and the triggers or thresholds used to generate alerts. In addition to the trigger values ​​or thresholds, trigger section 602 also displays the current weekly average values ​​of discharge time and fill time treatment data. User interface 600 also includes a summary section 604, which shows patient compliance analysis data compared to clinic averages (or averages of multiple patients across multiple clinics). In the illustrated example, patients have lower compliance compared to the patient population receiving treatment at clinics (receiving treatment data from clinics). Summary section 604 also shows catheter treatment data defined by average fill and discharge times. Summary section 604 also shows the average number of alerts per patient treatment compared to clinic averages. Summary section 604 allows users to view data for the past 30, 60, 90, and / or 180 days.

[0156] In some cases, application 320 is configured to enable clinicians to specify trigger values ​​or thresholds for compliance, catheter health, and / or alerts. For example, selecting a link or field in user interface 600 can cause application 600 to load another user interface that allows the trigger values ​​and / or thresholds to be modified by the clinician. Thresholds may include discrete numbers or percentage increases over a period of time or between treatments. Setting a trigger value or threshold causes that value to be transmitted to interface 310b of clinician server 304 and stored as a threshold parameter 404 in clinician database 306. Setting a trigger value causes, for example, interface 310b or analytics processor 310a to display an icon, notification, or other alert (or via push notification message) on the patient or treatment dashboard user interface indicating that treatment or analytics data has exceeded the threshold or trigger value.

[0157] Figure 7A compliance user interface 700, displaying compliance analysis data according to an example embodiment of this disclosure, is illustrated. The compliance user interface 700 indicates the number of days of treatment, total treatment time, and / or estimated length of stay for a particular patient to meet their prescription. This information provides clinicians with early intervention by offering early detection of declining treatment administration. Typically, compliance rates below 90% are associated with a significant increase in technical failures, peritonitis rates, hospitalizations, and / or mortality. Application 320 may display the user interface 700 when a user selects compliance analysis data in the user interface 600.

[0158] User interface 700 includes a digital section 702 and a graphical section 704, with the graphical section 704 displaying compliance analysis data for 30-day, 60-day, 90-day, or 180-day periods. Interface 700 includes summaries of compliance for different time periods to provide patient compliance trends. Sections 702 and 704 show patient compliance compared to the average compliance of multiple patients in the same clinic or one or more clinics (from which data is received). Furthermore, sections 702 and 704 show the percentage or ratio of lost treatment days for unplanned treatments, the percentage or ratio of completed treatment days for planned treatments, the percentage or ratio of lost treatment time for completed treatments (indicating patients prematurely ending treatment), and the percentage or ratio of lost stay time for completed treatments (indicating patients ignoring the entire stay phase of a cycle). The lost stay time information is particularly important because it conveys how much opportunity or prescription time used to absorb a patient's UF for removal has been lost.

[0159] Figure 8 The illustrated user interface 800 shows the treatment time that can be displayed by application 320 when treatment data is selected in user interfaces 600 or 700. User interface 800 displays a scatter plot of patient treatment time, which correlates the prescribed treatment time with the actual treatment time. In the illustrated example, Figure 4 Interface 310b is configured to transmit individual treatment times and prescription treatment times for each day of the planned treatment within document 420. Application 320 writes treatment data from document 420 into data fields associated with user interface 800 to generate a scatter plot. As shown in the plot, prescription treatment times increase slightly from approximately 450 minutes to 480 minutes over time. In contrast, actual treatment times vary and are generally shorter than prescription treatment times. Users can hover the cursor over each data point on the scatter plot of user interface 800 to have application 320 display the time, date, and / or prescription / actual treatment time values. User interface 800 also displays the average actual treatment time for 30-day, 60-day, 90-day, or 180-day periods.

[0160] Figure 9User interface 900 illustrates the dwell time displayed when dwell data is selected in user interface 600 or 700 by application 320. User interface 900 displays a scatter plot of patient dwell time, which correlates estimated dwell time (calculated based on prescription or prescribed fill and drain times) with actual dwell time. As shown, in a single treatment session, the estimated dwell time remains constant at approximately 87 minutes per cycle. In contrast, actual dwell time varies and is typically shorter than the estimated dwell time. The user can hover the cursor over each data point on the scatter plot to have the application display the time, date, and / or estimated / actual dwell time value. User interface 900 also displays the average actual dwell time over 30, 60, 90, or 180 days.

[0161] Figure 10 and Figure 11 The corresponding discharge and fill time user interfaces 1000 and 1100, which can be displayed when the discharge or fill time analysis data is selected in user interface 600 or 700 by application 320, are shown. Discharge and fill time user interfaces 1000 and 1100 show scatter plots of the average discharge and fill time per visit. The information displayed provides an early indication of a problem with the patient's catheter, where a slow decrease or increase in fill or discharge time may not be noticeable when observed on a routine basis. The data may indicate catheter flow restriction, misalignment, constipation, and / or fibrin chain buildup.

[0162] The discharge time user interface 1000 displays the individual average discharge time for each visit in relation to a trend line, which in this embodiment shows the average discharge time increasing from 17 minutes to 19 minutes. User interface 1000 also displays the average actual discharge time for 7-day, 30-day, 60-day, 90-day, or 180-day periods, indicating that a recent increase in discharge time may indicate a catheter problem. The fill time user interface 1100 displays the individual average fill time for each visit in relation to a trend line, which shows that the average fill time in this embodiment has decreased from 8 minutes to 7.5 minutes. The difference between the change in fill time and the change in discharge time can provide information indicating flow restriction, where a faster fill rate may not be affected by partial catheter blockage. Users can hover the cursor over any of the data points in user interfaces 1000 and 1100 to view the date, time, and minute values / values.

[0163] Figure 12 and 13 Alarm user interfaces 1200 and 1300 for displaying alarm analysis data are shown according to example embodiments of the present disclosure. Figure 12The alarm user interface 1200 includes a scatter plot of the average number of alarms generated by the treatment machine 90 during treatment. The plot also includes a trend line for the alarms. Clinicians can use this plot for early intervention to address patients' alarm problems, thereby providing better rest periods and better adherence to their prescribed treatments or procedures. An increase in alarms per treatment may indicate adherence problems, catheter problems, and / or technical malfunctions. An increase in alarms can lead to patient sleep disturbances and alarm fatigue. In some cases, the user interface may show the date / time the alarm was generated, as well as the type of alarm and / or indications of whether the alarm was silenced, escalated, or resolved. The user interface 1200 also displays the average number of alarms over 30, 60, 90, or 180-day periods.

[0164] Figure 13 User interface 1300 is illustrated, which includes the average alarm type per treatment over different time periods. Alarm types include, for example, manual ignore for filling, manual ignore for discharge, smart discharge alert, and manual ignore for dwell time. The illustrated alarms indicate that the patient finishes the filling, dwell, and discharge phases earlier than prescribed. In other embodiments, user interface 1300 may display alarms indicating access disconnection detection, line congestion, etc. In some embodiments, alarms may also indicate whether measured treatment data exceeds one or more thresholds for pre- / post-treatment blood pressure, blood glucose, pre- / post-treatment patient weight, heart rate, discharge UF, kt / V, CCI, filling volume, discharge volume, transporter type, number of manual exchanges, etc. Clinicians can use the alarm counts and alarm types shown in user interface 1300 for treatment interventions to help reduce the number of recurring alarms or identify patient treatment compliance issues.

[0165] B. Treatment Recommendation Examples

[0166] return Figure 4 Example application 310 on clinician server 304 may include guideline processor 310c, which is configured to provide evidence-based analysis or apply evidence-based models. Guideline processor 310c is configured to analyze data 402, 404, 406, and / or 412 to provide recommendations and / or guidance regarding the clinical benefits and risks of prescribed treatments and / or procedures. These recommendations and / or guidance can be adopted by clinicians to proactively work with patients to improve compliance, catheter problems, and / or alerts.

[0167] In some embodiments, the clinician database 306 stores a data structure 428 that associates recommendations and / or guidelines with portions or ranges of at least some of the data 402, 404, 406, and / or 412. The recommendations and / or guidelines may be provided by nationally recognized authorities such as ISPD, NKF, NKF DOQI, and / or peer-reviewed publications. Recommendations or guidelines may include suggested treatment or procedural settings or parameters for modifying prescribed treatments or procedures. Recommendations or guidelines may also include suggested settings or ranges for notification thresholds. Recommendations or guidelines may also include definitions of analyses / measures, links to websites with additional information, typical clinician values ​​for similar patients, potential patient-related risks, and / or actions taken by clinicians, such as contacting the patient, scheduling maintenance for the catheter or treatment machine 90, or silencing some alarms on the treatment machine 90.

[0168] Figure 4 Example guide processor 310c is configured to compare data 402, 404, 406, and / or 412 with one or more thresholds or ranges for suggestions and / or guidelines provided in data structure 428. If at least some of the data 402, 404, 406, and / or 412 correspond to suggestions or guidelines, guide processor 310c creates a suggestion document 430 including the identified suggestions or guidelines. Guide processor 310c causes interface 310b to transmit suggestion document 430 to application 320 for display.

[0169] To create guide document 430, guide processor 310c may include text of relevant suggestions and / or guidelines. Additionally or alternatively, guide processor 310c may access a predefined list of guidelines or suggestions stored in data structure 428. Guide processor 310c identifies the predefined guide or suggestion corresponding to the comparison. After identification, guide processor 310c writes the predefined guide or suggestion into suggestion document 430. In some embodiments, guide processor 310c may access web pages or other web-based content via one or more links in the relevant guidelines or suggestions to obtain text or multimedia content for addition to guide document 430.

[0170] Figure 14 It shows Figure 7 The compliance user interface 700 has an icon 1402 that allows the user to view recommendations or guidelines determined by the guide processor 310c. After receiving a recommendation document 430, the application 320 can display icon 1402. Alternatively, selecting icon 1402 can cause instructions to be transmitted to the guide processor 310c to create the recommendation document 430.

[0171] In some embodiments, selecting icon 1402 causes application 320 to display the suggestion user interface 1404. In the illustrated example, the guideline processor 310c simultaneously or previously determines that there are suggestions for patients with a compliance analysis value of less than 90%. The guideline processor 310c extracts the associated suggestions and guidelines, which are shown in the user interface 1404. In addition to measures that clinicians can take to help patients improve compliance, the guidelines include a brief explanation of the possible reasons for low compliance. The suggestions in the user interface 1404 include links to websites or web pages with additional information or content to assist clinicians. In some cases, the links may lead to the opening of an email program, a text messaging program, or the initiation of a call to the patient, enabling clinicians to quickly contact the patient. In other cases, the links may open the user interface with editable fields for prescribing treatments or procedures. Clinicians can use the interface to modify or create new prescribing treatments or procedures (if approved), which are then transmitted to the clinician server 304 for processing / verification before being transmitted to the treatment machine 90.

[0172] C. Example Process of Diagnosis and Treatment Analysis

[0173] Figure 15 This is a flowchart of an example program 1500, based on an example embodiment of this disclosure, that creates analysis data 406 using diagnostic data 402 and / or thresholds / parameters 406 from prescription treatment or procedures. Although referenced... Figure 15 The flowchart shown describes process 1500, but it should be understood that many other methods can be used to perform the steps associated with process 1500. For example, the order of many boxes in the block may be changed, some boxes may be combined with other boxes, and many boxes in the described block may be optional. In one embodiment, the number of boxes may be varied, and the analysis data is determined based on the number of boxes. Furthermore, the step of determining recommendations and / or guidelines may be omitted. The measures described in process 1500 are specified by one or more instructions and may be performed in multiple devices, including, for example, a clinician server 304 and / or a clinician database 306.

[0174] When the clinician server 304 receives patient diagnosis and treatment data 402 from one or more treatment machines 90 (e.g., medical fluid delivery machines), in Figure 15In the example, process 1500 begins (box 1502). Clinician server 304 receives treatment data 402 after treatment is completed. In other cases, clinician server 304 receives treatment data periodically, such as every 5 seconds, 10 seconds, 30 seconds, 1 minute, 5 minutes, 15 minutes, 1 hour, 24 hours, etc. In some embodiments, clinician server 304 may convert the received treatment data 402 from HL7 format to JSON format or a text-based format. Clinician server 304 identifies parameters or prescribed thresholds 404 corresponding to the prescribed treatments in the received data. For example, clinician server 304 may access patient records in clinician database 306 to determine the parameters of the prescribed treatments. Clinician server 304 may also access clinician database 306 to determine any default or clinician-prescribed thresholds or trigger values ​​used to generate alerts.

[0175] Then, the example clinician server 304 determines analysis parameters by comparing or identifying differences between at least some of the treatment data 402 and the parameters of the prescribed treatment and / or the prescribed threshold 404. This may include identifying lost treatment time analysis data 406aa (box 1506), average stay time analysis data 406ab (box 1508), average fill time analysis data 406bb (box 1510), and average discharge time analysis data 406ba (box 1512), as described above. Figure 5 As described. Example clinician server 304 also processes diagnosis and treatment data 402 to determine alarm analysis data 406c (box 1514) by determining the number of alarms generated, the type of alarms and / or whether the alarms were ignored, silenced, resolved or escalated.

[0176] The clinician server 304 then determines whether any analytical data in the analytical data 406 exceeds one or more thresholds (box 1516). If a threshold is exceeded, the clinician server 304 generates an alert, which is transmitted via document 420 to application 320 on clinician device 152 (box 1518). In other cases, the clinician server 304 provides an alert after detecting that application 320 is active and / or connected to receive document 420. The alert indicates that thresholds specified or defaulted by the clinician have been exceeded, such as compliance rate, average dwell time, average discharge time, average fill time, number of alerts generated, etc. The clinician server 304 also stores the analytical data 406 in one or more patient records in the clinician database 306 (box 1520). The clinician server 304 or web portal 150 may later retrieve the stored data 406 upon request for presentation and display on application 320 at personal mobile communication device 122 or clinician device 152.

[0177] In some embodiments, the clinician server 304 may determine whether to provide advice or guidelines based on, for example, whether an alert is generated or based on analysis data 406. If advice is to be generated, the clinician server 304 determines appropriate or corresponding advice and creates a advice document 430 for transmission and display via application 320 (box 1522). Figure 15 Example procedure 1500 can then end. Procedure 1500 can start again when additional diagnostic and treatment data is received.

[0178] III. Diagnosis and Treatment Prediction Examples

[0179] In some embodiments, the example clinician server 304 includes an application 310 configured to use one or more AI models, machine learning models, engines, and / or predictive analytics to determine the likelihood that a patient may stop or reduce treatment provided by the treatment machine 90. Figure 16 This is a diagram of an application 310 including a predictive processor 310d in a clinician server 304 according to an example embodiment of the present disclosure.

[0180] The example predictive processor 310d may include one or more AI models, such as the LightGBM model and / or a feedforward neural network model, configured or trained to predict patient discontinuation at least 5 to 7 days in advance and up to 21 to 30 days in advance. The predictive processor 310d is trained using a training dataset 1602, which includes patient treatment data 402 and / or logs over a rolling six to twelve-month period. Treatment data 402 is analyzed during this period to identify patients who have experienced a treatment gap of at least 5 to 14 days. The predictive processor 310d correlates treatment data 402, patient data 412, and / or any thresholds stored in the clinician database 306 with the identified patients. Thus, the predictive processor 310d possesses a dataset identifying patients who have discontinued treatment, as well as the treatment and personal characteristics of those who discontinued treatment relative to those who did not discontinue treatment.

[0181] The example prediction processor 310d is configured to determine model output 1604 by comparing treatment data 402 and / or patient data 412 with the modeled patient. Model output 1604 includes the average predicted probability that the considered patient will discontinue or reduce their prescribed treatment or procedure. The predicted probability is determined by comparing treatment data 402 (including the history of patient treatment data 402) and patient data 412 with training or modeling data to determine the closeness of the match or correlation between the patient data and the training or modeling data using at least three to five (or more) parameters. For example, treatment data 402 of a patient whose treatment data is nearly identical to that of other patients who have discontinued treatment is determined by prediction processor 310d to have a predicted probability of discontinuing treatment between 95% and 100%. However, if the treatment data of the considered patient deviates from that of other patients who have discontinued treatment (meaning the data begins to resemble that of patients who continue treatment), the predicted probability determined by prediction processor 310d is lower.

[0182] In some embodiments, the training dataset 1602 includes a table of treatment data 402 and / or patient data 412, with each row specifying the patient day for which treatment was prescribed. Columns may include treatment data 402 and / or patient data 412 for that patient day (e.g., input features). Columns may also include indications regarding whether treatment was subsequently discontinued for the patient (e.g., target variables). Furthermore, at least some of the data in the training dataset 1602 may be excluded from the modeling process and used as holdout or validation data to ensure that the training data has been properly used to train the predictive model.

[0183] In some embodiments, after training, the predictive model is configured to use recursive feature elimination to remove parameters that do not substantially contribute to the determination of the attention score. Additionally or alternatively, the parameters of the predictive model can be optimized using a Bayesian search over the parameter space. Furthermore, the stability of the predictive model can be tested before use to ensure that one or more predictions made on the trained model using diagnostic and / or patient data from longer time intervals do not become unstable.

[0184] Using a trained predictive model, the predictive processor 310d can classify predicted probabilities into “concern scores” and report the concern score to the relevant clinician when it exceeds a threshold (e.g., a greater than 50% probability of ending treatment). In addition to reporting concern scores, the predictive processor 310d can include or identify key parameters or contributing factors that lead to relatively high scores, thereby providing transparency to the AI ​​or machine learning model or engine. In some embodiments, key parameters may be weighted based on importance or relevance to the concern score. Furthermore, in some embodiments, the predictive processor 310d can determine a first concern score regarding the probability that a patient will end prescribing treatment (for at least two weeks), and a second concern score regarding the probability that a patient will reduce the frequency or duration of treatment.

[0185] In some cases, the predictive processor 310d is configured with a supervised learning scheme that compares current and historical treatment / patient data with the actual outcome (e.g., the target variable) of a patient continuing or discontinuing treatment. The predictive processor 310d determines patient discontinuation of treatment by identifying when machine 90 has not uploaded treatment data for at least a two-week period (the time frame of the prediction, such as the week following the date of interest, starting at a point in the prediction window). In other words, the predictive processor 310d determines that the absence of treatment for at least two weeks indicates that the patient (in the training set) has discontinued treatment. To determine the attention score for the target patient using patients from the training set, the AI ​​or machine learning system of the predictive processor 310d uses parameter inputs to determine the best-fit model for the modeling data. The predictive processor 310d can be configured to use techniques such as cross-validation and testing against a "holdout set" not used for training to avoid overfitting the model.

[0186] In some cases, the predictive processor 310d uses a model that receives patient / treatment data input and provides the amount of change (delta) between the current value and previous values ​​to indicate a trend, as well as a cumulative count of values ​​(such as alerts) over a certain time period (e.g., 28 days). Additionally, the predictive processor 310d may include other derived data elements, such as pulse pressure (the difference between systolic and diastolic blood pressure in a single measurement). For each day, in addition to the trend / cumulative count, the predictive processor 310d may also generate a target variable attention score. The predictive processor 310d provides the predictive model with patient treatment data input (the set of inputs for each patient per day) to compare against that patient's target variable (e.g., 1 or 0 indicating whether the patient stopped (or did not stop) using treatment machine 90 during the prediction window). The predictive processor 310d can then use one or more machine learning models (such as LGBM, neural networks, and logistic regression) to generate a probability (a decimal between 0 and 1) that the target variable is "1" (e.g., the patient will begin to stop using treatment machine 90 at some point during the prediction window).

[0187] In some embodiments, only a small subset of the patient's treatment data may be used in the analysis. For example, the prediction processor 310d may exclude recent treatment data 402 (e.g., data from the last five to seven days) for the patient under consideration. Furthermore, the prediction processor 310d may analyze only treatment data received within the last 5 to 30 days, preferably between 7 and 21 days. Therefore, a patient's past long-term adherence does not bias future predicted treatment adherence; instead, short-term trends are considered, which are more indicative of near-term treatment cessation.

[0188] Key parameters used by one or more patient prediction models and / or engines in Prediction Processor 310d include:

[0189] - Emission time (weighted average, maximum, average, minimum, variation, and / or cumulative emission time for each treatment),

[0190] - Emission volume (initial or cumulative, which may include at least one of the weighted average, maximum, average, minimum, and / or variation of emission values),

[0191] - Estimated day / night UF removal for each treatment session (including at least one of the weighted average, maximum, average, minimum, and / or variation of estimated UF removal).

[0192] - Residence time (weighted average, maximum, average, minimum, change or cumulative emission time for each treatment),

[0193] - Filling time (average or cumulative filling time per treatment session),

[0194] - Escalation messages / alerts / warnings generated by Machine 90 between treatments (may include weighted averages, maximum values, average values, minimum values, and / or changes between monthly / weekly / per-treatment alerts, messages, or warnings).

[0195] - Cumulative alarms / warnings,

[0196] - 90 days of experience using the treatment machine (including previous prescription treatments),

[0197] -Number of days spent receiving treatment at the clinic

[0198] - The number of days the patient received the prescribed treatment.

[0199] - The number of times the prescription treatment has been revised.

[0200] - The average number of hours between individual treatments (e.g., between daytime and nighttime treatments).

[0201] -Number of cycles in each treatment session

[0202] -Patient age,

[0203] -Patient gender,

[0204] -Prescription therapy identifier,

[0205] - Total treatment volume (which may include the weighted average, maximum, average, minimum, and / or variation of treatment fluid volume),

[0206] - Duration of diagnosis and treatment (which may include the weighted average, maximum, average, minimum and / or variation of the duration of diagnosis and treatment),

[0207] - Patient weight before / after treatment (may include the weighted average, maximum, average, minimum and / or change in patient weight),

[0208] - Patient's blood pressure (including at least one of the weighted average, maximum, average, minimum, or variation of diastolic and / or systolic blood pressure),

[0209] -Patient's heart rate, and

[0210] - The patient's kidney condition.

[0211] It should be understood that the predictive model uses at least three of the parameters mentioned above, and up to twenty to thirty parameters. If the attention score exceeds a threshold, interface 310b is configured to create document 1606 including the attention score and the top few contributing key parameters. Interface 310b may also include patient values ​​for each key parameter used in the patient prediction model / engine of the predictive processor 310d. In other embodiments, the attention score and top key parameters can be provided by interface 310b when requested by a clinician via application 320.

[0212] Figure 17 A user interface 1700 for a concern score according to an example embodiment of this disclosure is shown. User interface 1700 displays a concern score and several key parameters (the top five in this example). The key parameters include the patient's value. In this example, there is a 62% probability that the patient will discontinue treatment in the future (e.g., within the next one to four weeks). Indicators that may lead to patient discontinuation of treatment include the number of escalating alerts, the cumulative count of alerts, the average amount of UF removed, the patient's blood pressure, and the duration of prolonged discharge.

[0213] Clinicians reviewing this information have the opportunity to intervene before a patient's treatment ends. Patients may report frustration while using the machine (as indicated by warnings and blood pressure), a diminishing sense of benefit (lower UF removal rate), and longer treatment times (longer discharge time). In response, clinicians can contact the patient to determine if a different dextran level is needed to help remove UF more quickly. Clinicians can also help patients avoid triggering alarms and / or warnings. Overall, by being able to anticipate and act before a patient discontinues treatment, clinicians have a high probability of retaining the patient.

[0214] Figure 18 Another embodiment of a attention score user interface 1800 according to an example embodiment of this disclosure is shown. User interface 1800 includes reports of patients treated by a clinician. User interface 1800 includes the patient's name, identifier, and attention score. User interface 1800 also includes key parameters for each patient. It should be recognized that key factors differ between patients. This patient-specific analysis enables clinicians to narrow down and address specific reasons for the risk of patients discontinuing treatment. User interface 1800 also includes a list of previous attention scores to illustrate patient trends.

[0215] In some embodiments, application 310 of clinician server 304 may include guideline processor 310c to provide recommendations that take into account key parameters. Guideline processor 310c is configured to associate key patient parameters with data structure 428 ( Figure 16The values ​​or ranges of values ​​for the different recommendations and / or guidelines provided (as shown) can be compared. Recommendations or guidelines can be determined for each key parameter, the key parameters identified first, or generally based on attention scores.

[0216] If at least some of the key parameters and / or attention scores correspond to a specific recommendation or guideline, then the guideline processor 310c creates a recommendation document 430, which includes the identified recommendation or guideline. The guideline processor 310c causes the interface 310b to transmit the recommendation document 430 to the application 320 for display. Figure 19 Icon 1902 is shown Figure 17 The compliance user interface 1700, with icon 1902, allows the user to view suggestions or guidelines determined by the guide processor 310c. Selecting icon 1902 causes the application 320 to display the suggestion user interface 1900.

[0217] In the illustrated example, the guideline processor 310c identifies a recommendation for a patient with a concern score of 62%. The guideline processor 310c extracts the associated recommendations and guidelines shown in the user interface 1900. In addition to measures clinicians can take to help patients improve prescription adherence, the guidelines include a brief explanation of the possible reasons for the concern score. The user interface 1900 accordingly instructs clinicians to improve patient adherence to prescriptions based on predictive analytics of patients undergoing similar treatment.

[0218] Figure 20 This is a flowchart of an example process 2000 for predicting and reporting whether a patient is likely to discontinue or reduce prescribing treatment, according to an exemplary embodiment of this disclosure. Although referenced... Figure 20 The flowchart shown describes process 2000, but it should be understood that many other methods can be used to perform the steps associated with process 2000. For example, the order of many boxes in the block may be changed, some boxes may be combined with other boxes, and many boxes in the described block may be optional. In one embodiment, the step of determining recommendations and / or guidelines may be omitted. The measures described in process 2000 are specified by one or more instructions and may be performed in multiple devices, including, for example, a clinician server 304 and / or a clinician database 306.

[0219] When the clinician server 304 receives the training and treatment data 1602 from the patient group, Figure 20Example process 2000 begins (box 2002). The clinician server 304 can identify and select patients with similar prescribed treatments or procedures, patients who have been prescribed the same type of dialysis treatment (e.g., HD or PD treatment), patients who have received treatment from the same type of medical fluid delivery machine, and / or patients who have received prescribed treatments and / or procedures within the past year. In some cases, training data includes the diagnosis and treatment data of all patients analyzed by the clinician server 304 over the past 6 to 18 months.

[0220] Example clinician server 304 uses training treatment data 1602 to create one or more patient prediction models or engines, including, for example, LightGBM models and / or neural network models (box 2004). Clinician server 304 then accesses the treatment data 402 and / or patient data 412 of the analyzed patients (box 2006). Clinician server 304 applies treatment data 402 and / or patient data 412 to one or more patient prediction models to determine a concern score 1604 (box 2008). As discussed above, the concern score includes the probability that a patient will prematurely terminate (and / or significantly reduce) their prescribed treatment. Clinician server 304 may also determine several key parameters or attributes that primarily contribute to the concern score (box 2010). This may include at least one key parameter or up to ten key parameters.

[0221] Example clinician server 304 can compare the attention score to a threshold (box 2012). If the threshold is exceeded, clinician server 304 generates an alert, which is transmitted to application 320 on clinician device 152 via document or message 1606 (box 2014). The alert indicates that the threshold for the attention score, as defined or defaulted by the clinician, has been exceeded and warns the clinician that the patient is at risk of termination or reduction of their care. Example clinician server 304 also stores the attention score and key parameters 1604 (and / or all parameters contributing to the calculation of the attention score) to... Figure 16 The stored data 1604 can be retrieved later by the clinician server 304 or web portal 150 when a request is made to render and display it on the application 320 at the personal mobile communication device 122 or clinician device 152.

[0222] In some embodiments, the clinician server 304 may determine whether to provide advice or guidelines based on, for example, whether an alert is generated or based on an attention score 1604. If advice is to be generated, the clinician server 304 determines appropriate or corresponding advice and creates a advice document 430 for transmission and display via application 320 (box 2018). Figure 20 Example procedure 2000 can then end. Procedure 200 starts again when additional diagnostic and treatment data is received.

[0223] IV. Conclusion

[0224] It should be understood that various changes and modifications to the presently preferred embodiments described herein will be apparent to those skilled in the art. Such changes and modifications can be made without departing from the spirit and scope of the subject matter and without diminishing its intended advantages. Therefore, such changes and modifications are intended to be covered by the appended claims.

Claims

1. A system for managing patient compliance with a prescribed treatment or procedure administered by an automated peritoneal dialysis (APD) machine, the system comprising: a memory device storing: a record of the prescribed treatment or procedure for a patient, the record including a planned treatment day on which treatment is to be provided, a prescribed treatment duration, and an estimated prescribed treatment dwell time, and treatment data generated by the APD machine, the treatment data indicating a treatment duration, a fluid dwell time, and a date for each dialysis treatment by the APD machine in accordance with the prescribed treatment or procedure; an interface device communicatively coupled to the APD machine via a network, the interface device configured to receive the treatment data from the APD machine; and an analytics processor communicatively coupled to the interface device and the memory device, the analytics processor configured to: store the treatment data received by the interface device into the memory device, determine a lost treatment time parameter value as a difference or ratio between the treatment duration of the dialysis treatment and the prescribed treatment duration, the lost treatment time parameter value indicating how much treatment time is lost due to one or more treatments being terminated prematurely, determine a lost dwell time parameter value as a difference or ratio between the fluid dwell time of the dialysis treatment and the estimated prescribed treatment dwell time, the lost dwell time parameter value indicating how much time for ultrafiltration absorption is lost due to one or more treatments being terminated prematurely, determine a completed treatment day parameter value as a difference or ratio between the planned treatment day on which the treatment is to be provided and the date of the dialysis treatment, and cause the lost treatment time parameter value, the lost dwell time parameter value, and the completed treatment day parameter value to be displayed within a user interface on a clinician device.

2. The system of claim 1, wherein: the memory device includes a data structure relating a medical fluid delivery recommendation to at least one of a range of lost treatment time parameter values, a range of lost dwell time parameter values, or a range of completed treatment day parameter values.

3. The system of claim 2, further comprising a guideline processor communicatively coupled to the memory device and configured to: compare at least one of the lost treatment time parameter value, the lost dwell time parameter value, or the completed treatment day parameter value for the patient to a respective at least one of the range of lost treatment time parameter values, the range of lost dwell time parameter values, or the range of completed treatment day parameter values; select at least one recommendation based on the comparison; and cause the at least one recommendation to be displayed within a user interface on the clinician device. the analytics processor is configured to:

4. The system of claim 1 or 3, wherein, ​ storing the loss diagnosis time parameter value, the loss dwell time parameter value, and the completed diagnosis day parameter value to the memory device in association with a previous loss diagnosis time parameter value, a previous loss dwell time parameter value, and a previous completed diagnosis day parameter value from a previous treatment of the patient; creating a first chart using the current and the previous loss diagnosis time parameter values to show actual diagnosis time for the patient compared to the prescribed diagnosis duration of the diagnosis; and causing the first chart to be displayed in a first user interface of the clinician device.

5. The system of claim 4, wherein, the analysis processor is configured to: create a second chart using the current and the previous loss dwell time parameter values to show actual dwell time for the patient compared to the estimated prescribed diagnosis dwell time; and cause the second chart to be displayed in a second user interface of the clinician device.

6. The system of claim 1, 3, or 5, wherein: the record of the prescribed treatment or procedure for the patient includes at least one of a fill threshold or a drain threshold, and the diagnosis data includes at least one of a fluid fill time or a fluid drain time for the diagnosis, and wherein the analysis processor is configured to generate an alert if at least one of the fluid fill time, a weekly average fluid fill number, the fluid drain time, or a weekly average fluid drain number exceeds a respective at least one of the fill threshold or the drain threshold.

7. The system of claim 6, wherein: the alert indicates a problem with a catheter of the patient.

8. The system of claim 6, wherein: the record of the prescribed treatment or procedure for the patient includes at least one of a fill threshold or a drain threshold, and the diagnosis data includes at least one of a fluid fill time or a fluid drain time for the diagnosis, and wherein the analysis processor is configured to generate an alert if at least one of the fluid fill time or fluid drain time exceeds a respective at least one of the fill threshold or the drain threshold.

9. The system of claim 6, wherein: the fluid fill time includes an average fluid fill time for a cycle of the diagnosis, and the fluid drain time includes an average fluid drain time for a cycle of the diagnosis.

10. A method for managing adherence of a patient to a prescribed treatment or procedure administered by a dialysis machine, the method comprising: receiving, in an interface device, diagnosis data from the dialysis machine, the diagnosis data indicating a diagnosis duration, a fluid dwell time, and a date of a dialysis diagnosis by the dialysis machine according to a prescribed treatment or procedure; determining, via an analysis processor communicatively coupled to the interface device, dialysis diagnosis parameter values by comparing the diagnosis data to a record of the prescribed treatment or procedure, the record including a planned day to provide a diagnosis, a prescribed diagnosis duration, and an estimated prescribed diagnosis dwell time, the dialysis diagnosis parameter values including at least two of: a loss treatment time parameter value as a difference or ratio between the treatment duration of the dialysis treatment and the prescribed treatment duration, the loss treatment time parameter value indicating how much treatment time is lost due to one or more treatments being prematurely terminated, a loss dwell time parameter value as a difference or ratio between the fluid dwell time of the dialysis treatment and the estimated prescribed treatment dwell time, the loss dwell time parameter value indicating how much time for ultrafiltration absorption is lost due to one or more treatments being prematurely terminated, or a completed treatment days parameter value as a difference or ratio between the scheduled days on which the treatment is to be provided and the dates of the dialysis treatment, via the analytics processor, causing at least two of the loss treatment time parameter value, the loss dwell time parameter value, or the completed treatment days parameter value to be displayed within a user interface on a clinician device.

11. The method of claim 10, further comprising: via the analytics processor, storing the received treatment data and the record to a memory device.

12. The method of claim 10 or 11, wherein: the dialysis machine comprises an automated peritoneal dialysis machine or a hemodialysis machine.

13. The method of claim 10 or 12, wherein: the record of the prescribed treatment or procedure for the patient comprises at least one of a fill threshold or a drain threshold, and the treatment data comprises at least one of a fluid fill time or a fluid drain time for the treatment.

14. The method of claim 13, further comprising at least one of: generating an alert via the analytics processor if at least one of the fluid fill time, an average number of fluid fills per week, the fluid drain time, or an average number of fluid drains per week exceeds a respective at least one of the fill threshold or the drain threshold; or generating an alert via the analytics processor if at least one of the fluid fill time or the fluid drain time exceeds a respective at least one of the fill threshold or the drain threshold.

15. The method of claim 14, wherein: the alert indicates a problem with a catheter of the patient.

16. The method of claim 10 or 14, further comprising: via the analytics processor, accessing a data structure that correlates a medical fluid delivery recommendation to at least one of a range of loss treatment time parameter values, a range of loss dwell time parameter values, or a range of completed treatment days parameter values; via the analytics processor, comparing at least one of the loss treatment time parameter value, the loss dwell time parameter value, or the completed treatment days parameter value for the patient to a respective at least one of the range of loss treatment time parameter values, the range of loss dwell time parameter values, or the range of completed treatment days parameter values; via the analytics processor, selecting at least one recommendation based on the comparison; and via the analysis processor, causing the at least one suggestion to be displayed within the user interface on the clinician device.

Images