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

Abstract

To provide a medical fluid delivery system including analysis for managing patient involvement and treatment compliance.SOLUTION: In one implementation, the interface device receives therapy data from a dialysis machine regarding a patient undergoing dialysis. The analysis processor determines dialysis treatment parameter values by comparing the treatment data to records of a prescribed therapy or program. The dialysis treatment parameter values can include a missed treatment time parameter value, a missed dwell time parameter value, and / or a completed treatment day parameter value. The analysis processor causes the dialysis treatment parameter values to be displayed in a user interface on a clinician device. The dialysis treatment parameter values provide an indication as to the extent to which the patient is complying with the prescribed therapy or program, and can be used by a clinician to help the patient improve compliance if needed.SELECTED DRAWING: Figure 4

Description

[Background technology]

[0001] Engaging patients outside of a medical setting for extended periods of time is currently a virtually impossible task. Similar to signing up for a gym membership or purchasing a treadmill, many patients typically rush into the process. From the outset, patients are likely to readily adopt self-administered medical treatments (e.g., medical fluid delivery treatments). Often, these medical treatments are administered in the patient's home and / or at a clinic. With medical fluid delivery treatments, patients need to connect themselves to a medical fluid delivery machine (or a container containing renal failure treatment fluid) to cleanse their blood to combat toxin buildup. Part of the treatment may include administrative tasks that the patient needs to perform, such as weighing themselves, taking their blood pressure, and / or recording information related to their treatment. The information recorded by the patient is often reviewed by a clinician to ensure that the treatment is progressing as prescribed. The clinician also reviews the recorded data to determine whether adjustments to the treatment are needed.

[0002] Over time, patients become disengaged as repeated treatments lose their novelty and become a mundane, everyday obligation. As can be imagined, patients would rather engage in more exciting, relaxing, or stimulating activities compared to self-administered medical treatments or attending a clinic multiple times a week for the same treatment. While many patients continue with treatment, they sometimes begin to skip performing the additional tasks associated with treatment. Omitting additional tasks and becoming disengaged has the potential to create gaps in clinical oversight regarding ongoing treatment. As patients become more disengaged with treatment, they may begin to skip treatments, perform treatments for only a portion of the prescribed time, or abandon them entirely, endangering their health in the process. Summary of the Invention [Means for solving the problem]

[0003] Disclosed herein is a medical fluid data transfer system for determining and / or predicting patient adherence. The medical fluid data transfer system is configured to improve patient treatment compliance by tracking how a patient uses or otherwise interacts with a medical fluid delivery machine, such as an automated peritoneal dialysis ("APD") machine. In some embodiments, the medical fluid data transfer system analyzes data from the medical fluid delivery machine to determine the patient's adherence to one or more prescribed therapies or programs. If patient adherence is below or trending below a defined 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 a clinician with recommendations on how the patient's adherence to the one or more prescribed therapies or programs may be improved 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 treatment or falling below a defined adherence threshold. The one or more AI patient prediction models are configured to determine a concern score, which indicates the probability that a given patient will terminate treatment or fall below a desired adherence threshold. The AI ​​patient prediction model determines the concern score by considering treatment data from the medical fluid delivery machine and readily available patient information as it relates to the prescribed therapy. Thus, the AI ​​patient prediction model is configured to accurately determine patient risk using readily available data, without the need to access third-party data or other medical data recorded within the patient's medical record. 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 several significant reasons or attributes that contributed to the concern score. In some embodiments, the medical fluid data transfer system may generate adherence recommendations for clinicians based on the significant attributes identified by the AI ​​patient prediction model.

[0005] In addition to analyzing patient adherence to one or more prescribed therapies or programs implemented by the medical fluid delivery machine, the medical fluid data transfer system disclosed herein may also track alarm fatigue and / or determine whether a patient's catheter is experiencing problems. In certain examples, the medical fluid data transfer system may track the number and type of alarms generated by the medical fluid delivery machine for a particular patient. The medical fluid delivery machine may identify problems associated with one or more prescribed therapies or programs based on the alarms. The medical fluid delivery machine may then use one or more evidence-based and / or AI models to provide recommendations for the patient or associated clinician to avoid generating alarms. The medical fluid data transfer system may also allow the clinician and / or patient to silence or address 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 drain data from a medical fluid delivery machine and determine catheter status. The medical fluid delivery machine may determine that a patient's catheter placement is incorrect or that a leak exists if fill or drain times for one or more prescribed therapies or programs are below a specified threshold. Additionally, the medical fluid data transfer system may determine that a catheter is partially blocked or has fibrin strand buildup if fill or drain times for one or more prescribed therapies or programs are above a specified threshold.

[0007] The exemplary medical fluid data transfer system accordingly determines a complete picture of the patient's treatment outcomes, which is provided as adherence information. The medical fluid data transfer system may use the adherence information to provide recommendations and / or guidance for improving patient adherence to one or more prescribed therapies and / or programs. Furthermore, the medical fluid data transfer system may predict patients at risk of reducing or completely discontinuing their treatment. The medical fluid data transfer system disclosed herein accordingly improves patient adherence to one or more prescribed therapies or programs by tracking and prompting their interaction and use of one or more medical fluid delivery machines. In other words, the medical fluid data transfer system provides transparency into the patient's treatment, which allows clinicians to intervene early when treatment data indicates that an adherence issue is occurring or is in the early stages of developing. This transparency accordingly allows clinicians to intervene before the patient's medical condition worsens.

[0008] The medical fluid data transfer systems and methodologies of the present disclosure are applicable to fluid delivery for, for example, plasma exchange, hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), and continuous renal replacement therapy ("CRRT") therapies. The medical fluid data transfer systems described herein are also applicable to peritoneal dialysis ("PD"), intravenous drug delivery, and nutritional fluid delivery. These modalities may be referred to herein collectively, generally, or individually as medical fluid delivery or therapy.

[0009] The above modalities may be provided by a medical fluid delivery machine that houses the components needed to deliver medical fluids, such as one or more pumps, valves, heaters (if needed), online medical fluid generation equipment (if needed), sensors such as any one or more or all of pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, and the like, a user interface, and a control unit that may employ one or more processors and memory for controlling the above-described equipment. The medical fluid delivery machine may also include one or more filters, such as a dialyzer or hemofilter for cleansing the blood and / or an ultrafilter for purifying water, dialysis fluid, or other fluids.

[0010] The medical fluid delivery machines and medical fluid data transfer systems and methodologies described herein may be used in conjunction with home-based machines. For example, the systems may be used in conjunction with home HD, HF, or HDF machines operated at the patient's convenience. One such home system is described in U.S. Pat. No. 8,029,454 (the "'454 Patent"), issued October 4, 2011, entitled "High Convection Home Hemodialysis / Hemofiltration And Sorbent System," filed November 4, 2004, and assigned to the assignee of the present application. Another such home system is described in U.S. Pat. No. 8,393,690 (the "'690 Patent"), issued March 12, 2013, entitled "Enclosure for a Portable Hemodialysis System," and filed August 27, 2008. The entire contents of each of the above references are incorporated herein by reference.

[0011] As described in detail below, the medical fluid data transfer system and methodology of the present disclosure may operate within a comprehensive platform or system that may include many machines, patients, clinicians, physicians, maintenance personnel, electronic medical record ("EMR") databases, websites, resource planning systems that handle data generated through patient and clinician communications, and business intelligence, with many different types of devices. The medical fluid data transfer system and methodology of the present disclosure operates seamlessly within the entire system without violating its rules and protocols.

[0012] In a first aspect of the present disclosure, which may be combined with any other aspect recited herein unless otherwise specified in light of the disclosure herein and without limiting the disclosure in any way, a system for managing patient compliance with a prescribed therapy or program administered by an automated peritoneal dialysis ("APD") machine includes a memory device that stores a record of the prescribed therapy or program for the patient, including a schedule of days when therapy is to be provided, a prescribed therapy duration, and an estimated prescribed therapy dwell time. The memory device also stores therapy data generated by the APD machine. The therapy data indicates the therapy duration, fluid dwell time, and date for each dialysis therapy administered by the APD machine according to the prescribed therapy or program. The system also includes an interface device communicatively coupled to the APD machine via a network. The interface is configured to receive the therapy data from the APD machine. The system further includes an analysis processor communicatively coupled to the interface device and the memory device. The analysis processor is configured to store the treatment data received by the interface device in a memory device, determine a lost treatment time parameter value as the difference or ratio between the prescribed treatment duration and the treatment duration of the dialysis treatment, determine a lost dwell time parameter value as the difference or ratio between the estimated prescribed treatment dwell time and the fluid dwell time of the dialysis treatment, and determine a completed treatment day parameter value as the difference or ratio between the schedule of days the treatment is to be delivered and the date of the dialysis treatment. The analysis processor is also configured to cause the lost treatment time parameter value, the lost dwell time parameter value, and the completed treatment day parameter value to be displayed in a user interface on the clinician device.

[0013] According to a second aspect of the present disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise stated, a memory device includes a data structure that associates medical fluid delivery recommendations with 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.

[0014] According to a third aspect of the present disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise stated, the system further includes a guideline processor communicatively coupled to the memory device, wherein the guideline processor is configured to compare at least one of a lost treatment time parameter value, a lost dwell time parameter value, or a completed treatment day parameter value for the patient with 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, respectively, select at least one recommendation based on the comparison, and cause the at least one recommendation to be displayed in a user interface on the clinician device.

[0015] According to a fourth aspect of the present disclosure, which may be used in combination with any other aspects recited herein unless otherwise stated, the analysis processor is configured to store in a memory device the lost treatment time parameter value, the lost dwell time parameter value, and the completed treatment day parameter value in association with previous lost treatment time parameter values, previous lost dwell time parameter values, and previous completed treatment day parameter values ​​from a previous treatment of the patient, create a first graph using the current and previous lost treatment time parameter values ​​to show the actual treatment time for the patient compared to the prescribed treatment duration of the treatment, and cause the first graph to be displayed within a first user interface of the clinician device.

[0016] According to a fifth aspect of the present disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise stated, the analysis processor is configured to create a second graph using the current and previous lost dwell time parameter values ​​to show the actual dwell time for the patient compared to the estimated prescribed treatment dwell time, and cause the second graph to be displayed within a second user interface of the clinician device.

[0017] According to a sixth aspect of the present disclosure, which may be used in combination with any other aspects recited herein unless otherwise stated, the record of a prescribed therapy or program for a patient includes at least one of a fill threshold or a drain threshold, and the treatment data includes at least one of a fluid fill time or a fluid drain time for the treatment. The analysis processor is configured to generate an alert if at least one of the fluid fill time, the weekly average of the fluid fill time, the fluid drain time, or the weekly average of the fluid drain time exceeds the respective at least one of the fill threshold or the drain threshold.

[0018] According to a seventh aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the alert indicates a problem with the patient's catheter.

[0019] According to an eighth aspect of the present disclosure, which may be used in combination with any other aspects recited herein unless otherwise stated, the record of a prescribed therapy or program for a patient includes at least one of a fill threshold or a drain threshold, and the treatment data includes at least one of a fluid fill time or a fluid drain time for the treatment, and the analysis processor is configured to generate an alert if at least one of the fluid fill time or the fluid drain time exceeds the respective at least one of the fill threshold or the drain threshold.

[0020] According to a ninth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the fluid fill time comprises an average fluid fill time over a cycle of treatment, and the fluid drain time comprises an average fluid drain time over a cycle of treatment.

[0021] According to a tenth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, a system for predicting patient discontinuation of a prescribed therapy administered by an automated peritoneal dialysis ("APD") machine includes a memory device that stores a training dataset including treatment data and patient data for a group of patients. The training data also includes an indication of whether the patient has discontinued treatment of a prescribed therapy or program. The memory device also stores at least one patient prediction model formed using the training dataset. The at least one patient prediction model includes inputs of at least (i) a count or frequency of alerts generated by the APD machine, (ii) information related to peritoneal dialysis cycles, (iii) a patient's blood pressure value, and (iv) a patient's weight value. The memory device further stores patient data and previous treatment data for a target patient receiving the prescribed therapy or program. The system also includes an interface device communicatively coupled to the APD machine via a network. The interface is configured to receive treatment data from the APD machine regarding the target patient. The system further includes a prediction processor communicatively coupled to the interface device and the memory device. The prediction processor is configured to store the treatment data received by the interface device in the memory device, determine a concern score for the target patient by applying the patient data, treatment data, and previous treatment data of the target patient to at least one patient prediction model, and cause the concern score to be displayed within a user interface on the clinician device.

[0022] According to an eleventh aspect of the present disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise stated, the concern score indicates the probability that the target patient will at least one of terminate treatment of a prescribed therapy or program or reduce the frequency of that treatment.

[0023] According to a twelfth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the prediction processor is configured to identify the most significant concern parameters that contributed to the concern score and cause an indication of the most significant concern parameters to be displayed within a user interface on the clinician device.

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

[0025] According to a fourteenth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the system further includes a guideline processor communicatively coupled to the memory device, the guideline processor configured to compare the target patient's concern score with the range of concern scores, select at least one recommendation based on the comparison, and cause the at least one recommendation to be displayed in a user interface on the clinician device.

[0026] According to a fifteenth aspect of the present disclosure, which may be used in combination with any other aspects recited herein unless otherwise stated, a method for managing patient adherence to a prescribed therapy or program administered by a dialysis machine includes receiving, at an interface device, therapy data from the dialysis machine. The therapy data indicates therapy duration, fluid dwell time, and dates for dialysis therapy administered by the dialysis machine according to the prescribed therapy or program. The method also includes determining dialysis therapy parameter values ​​by comparing the therapy data with a record of the prescribed therapy or program via an analysis processor communicably coupled to the interface device. The record includes a schedule of days for which therapy is to be delivered, a prescribed therapy duration, and an estimated prescribed therapy dwell time. The dialysis therapy parameter values ​​include at least two of a lost therapy time parameter value as the difference or ratio between the prescribed therapy duration and the therapy duration of the dialysis therapy, a lost dwell time parameter value as the difference or ratio between the estimated prescribed therapy dwell time and the fluid dwell time of the dialysis therapy, or a completed therapy day parameter value as the difference or ratio between the schedule of days for which therapy is to be delivered and the date of the dialysis therapy. The method further includes causing, via the analysis processor, at least two of the lost treatment time parameter value, the lost dwell time parameter value, or the completed treatment day parameter value to be displayed in a user interface on the clinician device.

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

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

[0029] According to an eighteenth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the record of a prescribed therapy or program for a patient includes at least one of a fill threshold or a drain threshold, and the treatment data includes at least one of a fluid fill time or a fluid drain time for the treatment.

[0030] According to a nineteenth aspect of the present disclosure, which may be used in combination with any other aspect recited herein unless otherwise stated, the method further includes at least one of generating, via the analysis processor, an alert if at least one of the fluid fill time, the weekly average of the fluid fill time, the fluid drain time, or the weekly average of the fluid drain time exceeds at least one of the fill threshold or the drain threshold, respectively; or generating, via the analysis processor, an alert if at least one of the fluid fill time or the fluid drain time exceeds at least one of the fill threshold or the drain threshold, respectively.

[0031] According to a twentieth aspect of the present disclosure, which may be used in combination with any other aspect enumerated herein unless otherwise stated, the alert indicates a problem with the patient's catheter.

[0032] According to a twenty-first aspect of the present disclosure, which may be used in combination with any other aspects enumerated herein unless otherwise stated, the method further includes accessing, via the analysis processor, a data structure associating medical fluid delivery recommendations with 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; comparing, via the analysis processor, the at least one of the lost treatment time parameter values, the lost dwell time parameter values, or the completed treatment day parameter values ​​for the patient with 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, respectively; selecting, via the analysis processor, at least one recommendation based on the comparison; and displaying, via the analysis processor, the at least one recommendation in a user interface on the clinician device.

[0033] In a twenty-second aspect of the present disclosure, any of the structures, functionality, and alternatives disclosed in connection with any one or more of Figures 1-20 may be combined with any other structure, functionality, and alternatives disclosed in connection with any other one or more of Figures 1-20.

[0034] In light of the present disclosure and the above aspects, it is therefore an advantage of the present disclosure to provide an improved medical fluid delivery system.

[0035] It is another advantage of the present disclosure to determine patient compliance with a prescribed therapy or program and prevent patients from prematurely terminating treatment administered by a medical fluid delivery machine.

[0036] It is a further advantage of the present disclosure to predict patient adherence to a prescribed therapy or program using a training dataset of patients undergoing a similar prescribed therapy or program.

[0037] It is a further advantage of the present disclosure that it provides improved clinician or caregiver guidance and efficiency.

[0038] It is yet a further advantage of the present disclosure to provide improved patient outcomes from dialysis treatment.

[0039] It is yet another advantage of the present disclosure to provide 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 will be described in, and will be apparent from, the following detailed description and figures. The features and advantages described herein are not all-inclusive; in particular, many additional features and advantages will become apparent to those skilled in the art in view of the figures and description. Moreover, it is not necessary for any particular embodiment to have all of the advantages enumerated herein; it is expressly contemplated that each advantageous embodiment may be separately claimed. It should also be noted that the language used herein has been chosen primarily for purposes of readability and instruction, and not to limit the scope of the inventive subject matter. The present invention provides, for example, the following. (Item 1) 1. A system for managing patient adherence to a prescribed therapy or program administered by an automated peritoneal dialysis ("APD") machine, the system comprising: 1. A memory device comprising: a record of the prescribed therapy or program for the patient, including a schedule of days when therapy is to be provided, prescribed therapy duration, and estimated prescribed therapy dwell time; treatment data generated by the APD machine, the treatment data indicating treatment duration, fluid dwell time, and date for each dialysis treatment administered by the APD machine in accordance with the prescribed treatment or program; a memory device for storing the an interface device communicatively coupled to the APD machine via a network, the interface configured to receive the therapy data from the APD machine; an analysis processor communicatively coupled to the interface device and the memory device, the analysis processor comprising: storing the treatment data received by the interface device in the memory device; determining a lost treatment time parameter value as a difference or ratio between the prescribed treatment duration and the treatment duration of the dialysis treatment; determining a lost residence time parameter value as a difference or ratio between the estimated prescribed treatment residence time and the fluid residence time of the dialysis treatment; determining a completed treatment day parameter value as a difference or ratio between a schedule of days when said treatment is to be provided and the date of said dialysis treatment; displaying the lost treatment time parameter value, the lost dwell time parameter value, and the completed treatment day parameter value in a user interface on a clinician device; an analysis processor configured to: A system comprising: (Item 2) Item 10. The system of item 1, wherein the memory device includes a data structure that associates medical fluid delivery recommendations with 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 days parameter values. (Item 3) a guideline processor communicatively coupled to the memory device, comparing 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 with 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, respectively; selecting at least one recommendation based on said comparison; and displaying the at least one recommendation within the user interface on the clinician device; and a guideline processor configured to: Item 3. The system of item 2, further comprising: (Item 4) The analysis processor storing the lost treatment time parameter value, the lost dwell time parameter value, and the completed treatment day parameter value in the memory device in association with previous lost treatment time parameter values, previous lost dwell time parameter values, and previous completed treatment day parameter values ​​from a previous treatment of the patient; generating a first graph using current and previous lost treatment time parameter values ​​to show actual treatment time for said patient compared to a prescribed treatment duration of said treatment; displaying the first graph in a first user interface of the clinician device; 4. The system according to item 1 or 3, configured to perform the following: (Item 5) The analysis processor generating a second graph using current and previous lost dwell time parameter values ​​to show actual dwell time for said patient compared to said estimated prescribed treatment dwell time; displaying the second graph in a second user interface of the clinician device; and Item 5. The system of item 4, configured to perform the following: (Item 6) the record of the prescribed therapy or program for the patient includes at least one of a fill threshold or a drain threshold, and the treatment data includes at least one of a fluid fill time or a fluid drain time for the treatment; the analysis processor is configured to generate an alert if at least one of the fluid fill time, the weekly average of fluid fill time, the fluid drain time, or the weekly average of fluid drain time exceeds at least one of the fill threshold or the drain threshold, respectively. Item 1, 3, or 5. The system of item 1, 3, or 5. (Item 7) 7. The system of claim 6, wherein the alert indicates a problem with the patient's catheter. (Item 8) the record of the prescribed therapy or program for the patient includes at least one of a fill threshold or a drain threshold, and the treatment data includes at least one of a fluid fill time or a fluid drain time for the treatment; the analysis processor is configured to generate an alert if at least one of the fluid fill time or the fluid drain time exceeds at least one of the fill threshold or the drain threshold, respectively. Item 6. The system according to item 6. (Item 9) 7. The system of claim 6, wherein the fluid fill time comprises an average fluid fill time over a cycle of the treatment, and the fluid drain time comprises an average fluid drain time over a cycle of the treatment. (Item 10) 1. A system for predicting patient discontinuation of a prescribed treatment administered by an automated peritoneal dialysis ("APD") machine, the system comprising: 1. A memory device comprising: a training data set including treatment data and patient data for a group of patients, said training data also including an indication as to whether said patients have discontinued treatment from a prescribed therapy or program; at least one patient prediction model formed using the training data set, the at least one patient prediction model including inputs of at least (i) a count or frequency of alerts generated by an APD machine, (ii) information related to peritoneal dialysis cycles, (iii) a patient's blood pressure value, and (iv) a patient's weight value; Patient data and prior treatment data regarding target patients receiving prescribed therapies or programs; a memory device for storing the an interface device communicatively coupled to the APD machine via a network, the interface configured to receive the therapy data from the APD machine regarding a target patient; a prediction processor communicatively coupled to the interface device and the memory device, the prediction processor comprising: storing the treatment data received by the interface device in the memory device; determining a concern score for the target patient by applying patient data, treatment data, and prior treatment data of the target patient to the at least one patient prediction model; displaying said concern score within a user interface on a clinician device; a prediction processor configured to: A system comprising: (Item 11) Item 11. The system of item 10, wherein the concern score indicates a probability that the target patient will at least one of terminate treatment of the prescribed therapy or program or reduce the frequency of that treatment. (Item 12) The prediction processor Identifying the most significant concern parameters that contributed to said concern score; displaying an indication of the most significant parameter of concern within the user interface on the clinician device; and 12. The system according to item 10 or 11, configured to: (Item 13) 13. The system of claim 10 or 12, wherein the memory device includes a data structure that associates medical fluid delivery recommendations with a range of concern scores. (Item 14) a guideline processor communicatively coupled to the memory device, comparing the target patient's concern score to the range of concern scores; selecting at least one recommendation based on said comparison; and displaying the at least one recommendation within the user interface on the clinician device; and a guideline processor configured to: Item 14. The system of item 13, further comprising: (Item 15) 1. A method for managing patient compliance with a prescribed therapy or program administered by a dialysis machine, the method comprising: receiving, at an interface device, treatment data from the dialysis machine, the treatment data indicating treatment duration, fluid dwell time, and date for a dialysis treatment administered by the dialysis machine in accordance with a prescribed treatment or program; determining dialysis treatment parameter values ​​by comparing the treatment data with a record of the prescribed therapy or program via an analysis processor communicatively coupled to the interface device, the record including a schedule of days when treatment is to be provided, a prescribed treatment duration, and an estimated prescribed treatment dwell time, the dialysis treatment parameter values ​​being: a lost treatment time parameter value as a difference or ratio between the prescribed treatment duration and the treatment duration of the dialysis treatment; 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 day parameter value as a difference or ratio between the schedule of days when said treatment should be provided and the date of said dialysis treatment. and displaying, via the analysis processor, at least two of the lost treatment time parameter value, the lost dwell time parameter value, or the completed treatment day parameter value in a user interface on a clinician device; A method comprising: (Item 16) 16. The method of claim 15, further comprising storing the received treatment data and the record in a memory device via the analysis processor. (Item 17) 17. The method of claim 15 or 16, wherein the dialysis machine comprises an automated peritoneal dialysis ("APD") machine or a hemodialysis machine. (Item 18) 18. The method of claim 15 or 17, wherein the record of the prescribed therapy or program for the patient includes at least one of a fill threshold or a drain threshold, and the treatment data includes at least one of a fluid fill time or a fluid drain time for the treatment. (Item 19) generating an alert via the analysis processor if at least one of the fluid fill time, the weekly average fluid fill time, the fluid drain time, or the weekly average fluid drain time exceeds at least one of the fill threshold or the drain threshold, respectively; or generating an alert via the analysis processor if at least one of the fluid fill time or the fluid drain time exceeds at least one of the fill threshold or the drain threshold, respectively. Item 19. The method of item 18, further comprising at least one of: (Item 20) 20. The method of claim 19, wherein the alert indicates a problem with the patient's catheter. (Item 21) accessing, via the analysis processor, a data structure associating medical fluid delivery recommendations with 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 days parameter values; comparing, via the analysis processor, 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 with 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, respectively; selecting, via said analytical processor, at least one recommendation based on said comparison; and displaying the at least one recommendation within the user interface on the clinician device via the analysis processor; and 20. The method of claim 15 or 19, further comprising: [Brief explanation of the drawings]

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

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

[0043] [Figure 3] FIG. 3 is a schematic diagram of the medical fluid data transfer system of FIG. 1 including a clinician server, according to an embodiment of the present disclosure.

[0044] [Figure 4] FIG. 4 is a schematic diagram of the clinician server of FIG. 3 configured for analytical processing of treatment data from a medical fluid delivery machine, according to an exemplary embodiment of the present disclosure.

[0045] [Figure 5] FIG. 5 is a diagram illustrating at least some calculations performed by the clinician server of FIGS. 3 and 4, according to certain exemplary embodiments of the present disclosure.

[0046] [Figure 6] FIG. 6 is a diagram of an exemplary dashboard user interface provided by the clinician server of FIGS. 3 and 4, according to certain exemplary embodiments of the present disclosure.

[0047] [Figure 7] 7-9 are diagrams of exemplary patient adherence analysis user interfaces provided by the clinician server of FIGS. 3 and 4, according to exemplary embodiments of the present disclosure. [Figure 8] 7-9 are diagrams of exemplary patient adherence analysis user interfaces provided by the clinician server of FIGS. 3 and 4, according to exemplary embodiments of the present disclosure. [Figure 9] 7-9 are diagrams of exemplary patient adherence analysis user interfaces provided by the clinician server of FIGS. 3 and 4, according to exemplary embodiments of the present disclosure.

[0048] [Figure 10] 10 and 11 are diagrams of exemplary catheter analysis user interfaces provided by the clinician server of FIGS. 3 and 4, according to exemplary embodiments of the present disclosure. [Figure 11] 10 and 11 are diagrams of exemplary catheter analysis user interfaces provided by the clinician server of FIGS. 3 and 4, according to exemplary embodiments of the present disclosure.

[0049] [Figure 12] 12 and 13 are diagrams of exemplary alarm analysis user interfaces provided by the clinician server of FIGS. 3 and 4 according to exemplary embodiments of the present disclosure. [Figure 13]12 and 13 are diagrams of exemplary alarm analysis user interfaces provided by the clinician server of FIGS. 3 and 4 according to exemplary embodiments of the present disclosure.

[0050] [Figure 14] FIG. 14 is a diagram of an exemplary patient adherence user interface with recommendations provided by the clinician server of FIGS. 3 and 4 according to certain exemplary embodiments of the present disclosure.

[0051] [Figure 15] FIG. 15 is a flow diagram of an exemplary procedure for determining patient compliance, catheter, and alarm analysis data based on treatment data from a medical fluid delivery machine, according to an exemplary embodiment of the present disclosure.

[0052] [Figure 16] FIG. 16 is a schematic diagram of the clinician server of FIG. 3 configured for predictive processing of treatment data from a medical fluid delivery machine, according to an exemplary embodiment of the present disclosure.

[0053] [Figure 17] FIG. 17 is a diagram of a concern score user interface provided by the clinician server of FIG. 16, according to an exemplary embodiment of the present disclosure.

[0054] [Figure 18] FIG. 18 is another diagram of a concern score user interface according to an example embodiment of the present disclosure.

[0055] [Figure 19] FIG. 19 is a diagram of an exemplary patient concern score user interface with recommendations provided by the clinician server of FIG. 16, according to certain exemplary embodiments of the present disclosure.

[0056] [Figure 20]FIG. 20 is a flow diagram of an exemplary procedure for predicting patient adherence using treatment data from a medical fluid delivery machine, according to an exemplary embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0057] Detailed Description A medical fluid delivery system is disclosed herein. The exemplary medical fluid delivery system is configured to use treatment data from a medical fluid delivery machine to improve patient adherence to one or more prescribed therapies and / or programs. The exemplary medical fluid delivery system determines an adherence analysis that is provided, for example, to a clinician device of a clinician treating the patient. The adherence information includes information indicative of the degree to which a patient adheres to a prescribed therapy over time. The adherence information may include the number of days a prescribed therapy has been completed by the patient. The adherence information may also include lost treatment time and / or low fluid retention time, which may result from a patient prematurely terminating a prescribed therapy during treatment. The clinician may use the adherence information to determine whether a change in prescribed therapy is needed and / or whether patient intervention / education is needed.

[0058] In some embodiments, the compliance information may also include catheter analysis information that compares drain and fill times from an administered therapy to defined and / or threshold drain and fill times for a prescribed therapy. Deviations in drain and fill times from defined and / or threshold times may indicate that a patient's catheter is improperly positioned or aligned. Deviations may also indicate a patient's clogged or partially blocked catheter from fibrin strands. Clinicians may use the catheter analysis information to determine if a patient's therapy compliance is being affected by catheter performance and take corrective action on the catheter (such as replacement or repositioning).

[0059] In some embodiments, the adherence information may further include alarm analysis information, which provides a summary of alarm types and alarm frequency. Clinicians may use the alarm information to identify problems the patient may be experiencing. The alarm analysis information may also be used to enhance the catheter analysis information and / or therapy adherence information. For example, an alarm may indicate that a patient is bypassing fill and / or drain times midway through a therapy and terminating the therapy early.

[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 adherence. The 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 Outcomes Quality Initiative ("DOQI"). The medical fluid delivery system compares the patient-specific adherence analysis to a data structure that associates the adherence analysis values ​​with certain recommendations and / or guidelines. The medical fluid delivery system uses the comparison to automatically transmit recommendations to the clinician and / or patient.

[0061] In some embodiments, the medical fluid delivery system may use one or more patient prediction models configured to identify patients deemed at high risk for reducing or discontinuing treatment within the next week to one month. The patient prediction model may include an AI model and / or a machine learning model trained using previous treatment data for substantially all patients associated with the medical fluid delivery system. In addition to identifying at-risk patients, the patient prediction model determines at least three to five top contributing factors or attributes that influenced the analysis. Clinicians may use knowledge of the contributing factors to determine intervention actions or risk mitigation steps to improve patient adherence to prescribed therapies or programs. 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 the identified contributing factors and / or risk scores.

[0062] A prescribed therapy or program and corresponding therapy are referred to herein. A prescribed therapy or program corresponds to one or more parameters that define how a medical fluid delivery machine should operate to administer therapy to a patient. For peritoneal dialysis therapy, 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 should remain in the patient's peritoneal cavity (i.e., dwell time), and the amount (or rate) of spent dialysis fluid and ultrafiltration ("UF") to be pumped or drained from the patient after the dwell period ends. For therapy involving multiple cycles, the parameters may specify the fill, dwell, and drain per cycle and the total number of cycles to be performed during the course of therapy (one therapy provided per day, or separate therapy provided during the day and night). Additionally, the parameters (or device program) may specify the date / time / day (e.g., schedule) on which the therapy should be administered by the medical fluid delivery machine. Additionally, the parameters of the prescribed therapy may define the total volume of dialysis fluid to be administered per treatment, as well as concentration levels of the dialysis fluid, such as glucose levels.

[0063] A prescribed therapy may specify parameters for each therapy provided by a medical fluid delivery machine, but the therapy data reported by the machine may vary. As discussed herein, therapy data refers to data generated by a medical fluid delivery machine that indicates measured, detected, or determined parameter values. For example, a prescribed therapy may specify that a therapy should include five separate cycles with a 45-minute dwell time each, but the medical fluid delivery machine may administer a therapy in which fewer cycles are provided with a 30-minute dwell time each. Deviations from prescribed parameters may result from the patient overriding the therapy program or prematurely discontinuing the therapy. The medical fluid delivery machine monitors how the therapy is administered and provides parameters indicative of operation accordingly. Parameters related to therapy data may include, for example, the total amount of dialysis fluid administered to the patient, the number of cycles administered, the fill volume per cycle, the dwell time per cycle, the drain time / volume per cycle, the estimated amount of UF removed, the start time / date of therapy, and / or the end time / date of therapy. The therapy data may also include calculated parameters such as fill and drain rates, which are determined by dividing the amount of fluid pumped by the time spent pumping. The therapy data may further include an identification of any alarms that occurred during therapy, the duration of the alarm, the time of the alarm, the event associated with the alarm, and / or an indication as to whether the problem that caused the alarm has been resolved or whether the alarm has been turned off.

[0064] In addition to treatment data, the medical fluid delivery system may use patient data. As disclosed herein, patient data may be determined from the treatment data. For example, the medical fluid delivery system may determine the 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 provided by the clinician / patient, defined within a prescribed therapy or program, and / or provided via patient registration. Demographic data may include patient age, gender, patient mobility level, patient renal condition, prescription history, etc. In some embodiments, the patient data and / or treatment data may include an identifier that enables the medical fluid delivery system to store the received data in an appropriate patient record located in a database. The identifier may include a patient identifier, a patient name, and / or a medical fluid delivery system identifier.

[0065] Analytical data is also referred to herein. As discussed in more detail below, analytical data refers to treatment data compared to one or more parameters of a prescribed therapy or program and / or compared to a defined threshold. Analytical data may represent the difference between a parameter value of the treatment data and a corresponding parameter value defined in the prescribed therapy. Analytical data may also represent the ratio between a parameter of the treatment data and a corresponding parameter (or defined limit / threshold) from the prescribed therapy and / or program. Analytical data may represent a comparison for a single treatment or a trend over time for multiple treatments. Analytical data may 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 may discontinue treatment for a prescribed therapy or program or significantly reduce their administration of treatment.

[0066] As discussed herein, the medical fluid delivery machine is located at the patient's residence. However, in some embodiments, the medical fluid delivery machine may be located at a full-service medical facility and / or a self-service medical facility. 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 medical 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 adherence analysis, catheter analysis, alarm analysis, and / or patient predictive analysis. In some instances, the medical fluid delivery system is configured to provide a breakdown of reported data by medical fluid delivery machine and / or by home-based treatment compared to facility-based treatment. I. Medical Fluid Delivery System Embodiments

[0067] Exemplary medical fluid delivery systems disclosed herein include one or more medical fluid delivery machines. One example of a medical fluid delivery machine is a renal failure therapy machine. With respect to a renal failure therapy machine, due to various causes, a patient's renal system may fail. Renal failure results in several physiological disturbances. For example, a patient suffering from renal failure can no longer maintain water and mineral balance or excrete daily metabolic loads. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, and others) may accumulate in the patient's blood and tissues.

[0068] Kidney failure and reduced kidney function are treated using dialysis. Dialysis removes waste products, toxins, and excess water from the body that normally functioning kidneys would otherwise remove. Dialysis treatment for kidney function replacement is important for many people because the treatment is lifesaving.

[0069] One type of kidney failure treatment is hemodialysis ("HD"), which generally uses diffusion to remove waste products from a patient's blood. A diffusion gradient occurs across a semi-permeable dialyzer between the patient's blood and an electrolyte solution called dialysate or dialysis fluid to cause diffusion.

[0070] Hemofiltration ("HF") is an alternative renal replacement therapy that relies on convective transport of toxins from the patient's blood. HF is accomplished by adding replacement or replacement fluid (typically 10–90 liters of such fluid) to the extracorporeal circuit during treatment. The replacement fluid and the fluid accumulated by the patient during treatment are ultrafiltered over the course of HF treatment, providing a convective transport mechanism that is particularly beneficial in removing medium and large molecules. (In hemodialysis, small amounts of waste products are removed with the fluid obtained during the dialysis session; however, the solute drag from the removal of the ultrafiltrate is not sufficient to provide convective clearance.)

[0071] Hemodiafiltration ("HDF") is a treatment modality that combines convective and diffusive clearance. HDF uses dialysis fluid flowing through a dialyzer, similar to standard hemodialysis, to provide diffusive clearance. In addition, replacement fluid is provided directly to the extracorporeal circuit to provide convective clearance.

[0072] Most HD (HF, HDF) treatments are performed in centers. There is a trend toward home hemodialysis ("HHD") today, in part because HHD can be performed daily, offering therapeutic benefits over in-center hemodialysis treatments, which are typically performed two or three times a week. Studies have shown that frequent treatments remove more toxins and waste products than patients who receive less frequent, but perhaps longer, treatments. Patients who receive more frequent treatments do not experience as many downcycles compared to in-center patients who accumulate two or three days' worth of toxins prior to treatment. In some areas, the nearest dialysis center may be many miles from the patient's home, and treatment time, including the entire procedure, may take up most of the day. In contrast, HHD can be performed overnight or during the day while the patient is relaxing, working, or otherwise productive.

[0073] Another type of kidney failure therapy is peritoneal dialysis, in which a dialysate, also called dialysis fluid, is infused into a patient's peritoneal cavity via a catheter. The dialysis fluid contacts the peritoneal membrane of the cavity. Waste, toxins, and excess water pass from the patient's bloodstream, through the peritoneal membrane, and into the dialysis fluid due to diffusion and osmosis; an osmotic gradient occurs across the membrane. An osmotic agent in dialysis provides the osmotic gradient. Spent or depleted dialysis fluid is pumped out of the patient, removing the waste, toxins, and excess water from the patient. This cycle may be repeated, for example, multiple times.

[0074] There are various types of peritoneal dialysis therapies, 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 an implanted catheter to a drain to allow spent or spent dialysate fluid to drain from the patient's peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysis fluid to infuse fresh dialysis fluid into the patient through the catheter. The patient disconnects the catheter from the fresh dialysis fluid bag, allowing the dialysis fluid to dwell in the peritoneal cavity, where transfer of waste products, toxins, and excess water occurs. After a dwell period, the patient repeats the manual dialysis procedure, for example, four times per day, with each treatment lasting one to six hours. Manual peritoneal dialysis requires a significant amount of time and effort from the patient and leaves room for improvement.

[0075] Automated peritoneal dialysis ("APD") is similar to CAPD in that the dialysis treatment involves drain, fill, and dwell cycles. However, APD machines typically perform the cycles automatically while the patient sleeps. APD machines relieve patients from having to manually perform treatment cycles and from having to transport supplies during the day. APD machines fluidly connect an implanted catheter to a source or bag of fresh dialysis fluid and to a fluid drain. The APD machine pumps fresh dialysis fluid from the dialysis fluid source, through the catheter, and into the patient's peritoneal cavity. APD machines also allow the dialysis fluid to dwell within the cavity, allowing waste, toxins, and excess water transfer to occur. The source may include multiple sterile dialysis fluid bags.

[0076] APD machines pump spent or depleted dialysate from the patient's peritoneal cavity, through a catheter, and to a drain. As with manual processes, several drain, fill, and dwell cycles occur during dialysis. A "final fill" occurs at the end of APD, and the fluid remains in the patient's peritoneal cavity until the next treatment.

[0077] Any of the above modalities performed by the machine may be performed on a scheduled basis and may require a start-up procedure. For example, dialysis patients typically perform treatment on a scheduled basis defined by a prescribed therapy or program, such as every other day, daily, etc. Blood treatment machines typically require a certain amount of time before treatment for setup, for example, to perform a disinfection procedure. Patients for the above modalities lead busy lives and may have errands to plan or perform that would necessitate treatment on the scheduled day.

[0078] Much of the appeal of home therapy for patients revolves around the lifestyle flexibility offered by allowing patients to perform therapy at home primarily according to their own schedule. However, home medical fluid delivery machines may include software timers that prompt and constrain patients. Home hemodialysis systems may require patients to be in close proximity to the home hemodialysis machine to initiate, for example, pre-treatment, inter-treatment, and post-treatment sequences.

[0079] In one particular example, a therapy machine may reuse certain components by sanitizing them between treatments. The machine may employ one or more sanitization timers that require a patient or caregiver to use the machine to begin treatment before the sanitization timer expires. Otherwise, the patient would need to wait until another sanitization procedure is completed before beginning treatment. In one embodiment, the therapy machine communicates a treatment start time deadline via the machine's graphical user interface.

[0080] It is envisioned that the software of the disclosed system and methodology will disable communications between the patient and / or caregiver and the machine whenever the machine is in the "patient connected" software state. For example, if a clinician attempts to send a command to a machine that is currently treating a patient, the command may be blocked by the middleware software application so that the command is not forwarded to that machine. The middleware software application may then reply to the clinician informing them that the machine is busy and will not accept communications.

[0081] The embodiments described herein are applicable to any medical fluid delivery system that delivers medical fluids, such as blood, dialysis fluid, replacement fluid, and / or intravenous medications ("IV"). The embodiments are particularly well-suited for renal failure therapies, such as all forms of hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), continuous renal replacement therapy ("CRRT"), and peritoneal dialysis ("PD"), which are collectively or generally referred to herein as prescription therapies or programs. The medical fluid delivery machine may alternatively be a drug delivery or nutritional fluid delivery device, such as a large-volume peristaltic pump or syringe pump. The machines described herein may also be used in home settings. For example, machines operating with a data transfer component may be employed with a home HD machine, which may be activated, for example, overnight while the patient is asleep. The medical fluid data transfer system and methodology of the present disclosure may alternatively be used to assist clinicians or nurses in hospitals and / or clinics.

[0082] Referring now to the drawings, and in particular to FIG. 1 , a medical fluid data transfer system 10 is illustrated. The exemplary system 10 includes a number of medical fluid delivery machines 90 (one type of which is discussed in detail below). The machines 90 of the medical fluid data transfer system 10 may be of the same type (e.g., all PD machines) or different types (e.g., a mix of HD, PD, CRRT, and medical or nutritional fluid delivery).

[0083] Although a single medical fluid delivery machine 90 is illustrated as communicating with the connectivity server 118, the system 10 manages the operation of multiple medical fluid delivery systems and machines of the same type or of different types as listed above. For example, there may be M hemodialysis machines 90, N hemofiltration machines 90, O CRRT machines 90, P peritoneal dialysis machines 90, Q home drug delivery machines 90, and R nutrition or drug delivery machines 90 connected to the server 118 and operating with the system 10. The numbers M through R may be the same or different numbers and may be zero, one, or more than one. In FIG. 1, the medical fluid delivery machine 90 is illustrated as a therapy machine 90 (home indicated by a dashed line).

[0084] The therapy machine 90 may receive purified water at its front end from the water treatment device 60. The water treatment device 60, in one embodiment, connects to the therapy machine 90 via an Ethernet cable. The therapy machine 90 in the illustrated embodiment operates with other devices besides the water treatment device 60, such as a blood pressure monitor 104, a meter, e.g., a wireless meter 106, and a user interface, such as a wireless tablet user interface 122. The therapy machine 90, in one embodiment, connects wirelessly to a server 118 via a modem 102. Each of these components may (but need not) be located within the patient's home, as demarcated by the dashed lines in FIG. 1 . Any one, more, or all of the components 60, 104, 106, and 122 may communicate with the therapy machine 90 wired or wirelessly. Wireless communication may be achieved using a variety of protocols, including Bluetooth, WiFi, and the like. TM , Zigbee®, Z-Wave®, wireless universal serial bus (“USB”), infrared, or any other suitable wireless communication technology. Alternatively, any one, more, or all of components 60, 104, 106, and 122 may communicate with therapy machine 90 via wired communication.

[0085] The exemplary connectivity server 118 communicates with the medical fluid delivery machines 90 via a medical device system hub 120. The exemplary system hub 120 allows data and information about each therapy machine 90 and its peripherals to pass back and forth between the machine 90 and other devices connected to the server 118 via the connectivity server 118. In the illustrated embodiment, the system hub 120 is connected to a service portal 130, an enterprise resource planning system 140, a web portal 150, a business intelligence portal 160, a HIPAA-compliant database 124, a product development team 128, and an electronic medical record database maintained, for example, at a clinic or hospital 126a-126n. The connectivity server 118 and / or the portals 130, 150, and 160 may include gateway devices.

[0086] The illustrated electronic medical record ("EMR") database may be located at the clinic or hospital 126a-126n and store electronic information about patients. The system hub 120 may transmit data collected from the machine 90 log files (e.g., treatment data) to the hospital or clinic database 126a-126n to merge or supplement the patient's medical record. The database at the clinic or hospital 126a-126n may contain patient-specific treatment and prescription data (e.g., prescribed therapies or programs), and access to such databases may be highly restricted. The exemplary enterprise resource planning system 140 is configured to acquire and compile data generated via patient and clinician website access, such as complaints, billing information, and lifecycle management information. A web portal 150 allows patients and the clinics 152a-152n that treat them to access publicly available websites. The Business Intelligence Portal 160 collects data from the System Hub 120 and provides the data to Marketing 162, Research and Development 164, and Quality / Pharmacovigilance 166.

[0087] It should be understood that the systems, methods, and procedures described herein may be implemented using one or more computer programs or components. The component programs may 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 or optical disks, optical memory, or other storage medium. The instructions may be configured to be executed by a processor, which, upon execution of the series of computer instructions, performs or facilitates the performance of all or a portion of the disclosed methods and procedures described herein.

[0088] In one embodiment, therapy machine 90 performs a home therapy, such as home peritoneal dialysis, on a patient in the patient's home and then reports the results of the therapy (as therapy data) to system hub 120, which may communicate with one or more servers. As described in more detail below, the one or more servers analyze the therapy data for reporting to clinicians, doctors, and / or nurses involved in managing the patient's health and well-being.

[0089] In one embodiment, the therapy machine 90 writes log files using, for example, a Linux operating system. The log files document relevant therapy machine 90 data, including peripheral device data. The log files may include any one or more of Extensible Markup Language (“XML”), Comma Separated Values ​​(“CSV”), or text files. The log files are located in a file server repository managed by the therapy machine 90 software. It is also contemplated that data not transmitted to the machine 90 may be stored in a peripheral device, such as the water treatment device 60. Such data may be otherwise obtained via a wired or wireless connection to the peripheral device or downloaded through other data connections or storage media. For example, a maintenance technician may access the additional data via a laptop connected to the water treatment device 60 or the wireless meter 106, for example, via an Ethernet connection. Alternatively, the additional data may be retrieved remotely from the peripheral device, with the therapy machine 90 serving as a data transfer conduit between the peripheral device and an authorized client of the medical fluid data transfer system.

[0090] In one embodiment, the therapy machine 90 uses a connectivity service, e.g., via the Internet, to transfer therapy data between the modem 102 and the system hub 120. Here, a dedicated line may be provided at each patient's home to connect the therapy machine 90 to the connectivity server 118 via the modem 102. The therapy machine 90 in one embodiment accesses the Internet using a separate, e.g., 3G, 4G, or 5G, modem 102. The modem 102 may be a Vodafone TMAn internet service provider ("ISP") such as Axeda may be used. In one implementation, a connectivity agent 114 developed by a connectivity service provider (e.g., the provider of a connectivity server 118) is installed on the therapy machine 90 and launched on the machine's primary control processor ("ACPU") 50. One suitable connectivity service is Axeda TM , which provides a securely managed connection 116 between the medical device and a connectivity server 118.

[0091] 1 is configured to enable therapy machines 90 to connect to a connectivity server 118 and transfer therapy data to and from the connectivity server 118. Connectivity services operating through the agent 114 and server 118 ensure that connections with machines 90 are secure, ensure that data passes correctly through firewalls on machines 90, detect whether there are data or system crashes, and ensure that the connectivity server 118 is communicating with the correct therapy machines 90.

[0092] In one embodiment, the therapy machine 90 may connect to the connectivity server 118 only when the connectivity agent 114 is turned on or activated. During treatment and post-treatment disinfection, while the machine 90 and its peripherals are functioning, in one embodiment, the connectivity agent 114 is automatically turned off, which prevents the therapy machine 90 from communicating with any entity and sending or receiving data during treatment and disinfection or when the machine 90 is running or activated. When the therapy machine 90 is idle, for example, after treatment and post-treatment disinfection are completed, the ACPU 50, in one embodiment, turns on the connectivity agent 114. In some embodiments, the connectivity agent 114 is off during treatment and possibly pre-treatment. After treatment, the connectivity agent 114 uses a connectivity service to read log files from the therapy machine 90 and transfer the treatment data to the connectivity server 118. The connectivity service routes data packets to their appropriate destination, but in one embodiment does not modify, access, or encrypt the data.

[0093] 1 , connectivity services via connectivity server 118 may communicate data via system hub 120 to various locations, such as service portal 130, clinics or hospitals 126a-126n, and web portal 150. Connectivity server 118 enables maintenance personnel 132a-132n and / or clinicians to track and retrieve various assets and their associated information, including machine or modem serial numbers, across a network, such as appropriate therapy machines 90 and 3G, 4G, or 5G modems 102. Connectivity server 118 may also be used to receive and provide firmware upgrades approved by maintenance personnel supervisor 134 and obtained remotely via service portal 130 to authorized therapy machines 90 and associated peripherals, such as water treatment devices 60. A. Exemplary Medical Fluid Delivery Machine

[0094] Referring now to FIG. 2 , an example of an HD flow schematic for a medical fluid delivery machine 90 is illustrated. Because the HD system of FIG. 2 is relatively complex, FIG. 2 and its discussion also provide support for any of the renal failure therapy modalities discussed above, as well as IV, drug delivery, or nutritional fluid delivery machines. Generally, a medical fluid delivery machine 90 is shown having a simplified version of the dialysis or process fluid delivery circuit. The blood circuit is also simplified, but not to the same extent as the dialysis fluid circuit. It should be understood that the circuitry has been simplified for ease of explanation of the present disclosure, and that the system, if implemented, would have additional structure and functionality, such as those found in the publications incorporated by reference above.

[0095] The medical fluid delivery machine 90 of FIG. 2 includes a blood circuit 20. The exemplary blood circuit 20 draws blood from and returns blood to a patient 12. Blood is drawn from the patient 12 via an arterial line 14 and returned to the patient via a venous line 16. The arterial line 14 includes an arterial line connector 14a that connects to an arterial needle 14b, which is in blood draw communication with the patient 12. The venous line 16 includes a venous line connector 16a that connects to a venous needle 16b, which is in blood return communication with the patient. The arterial and venous lines 14 and 16 also include line clamps 18a and 18v, which may be spring-loaded, fail-safe mechanical pinch clamps. The line clamps 18a and 18v, in one embodiment, are automatically closed in an emergency situation.

[0096] The arterial and venous lines 14 and 16 also include air or bubble detectors 22a and 22v, which may include ultrasonic air detectors, respectively. The air or bubble detectors 22a and 22v are configured to detect air in the arterial and venous lines 14 and 16, respectively. If air is detected by one of the air detectors 22a and 22v, the medical fluid delivery machine 90 closes the line clamps 18a and 18v, pauses the blood and dialysis fluid pumps, and provides instructions to the patient to purge the air so that treatment can resume.

[0097] In the illustrated embodiment, a blood pump 30 is located within the arterial line 14. The blood pump 30 includes a first blood pump pod 30a and a second blood pump pod 30b. The blood pump pod 30a operates with an inlet valve 32i and an outlet valve 32o. The blood pump pod 30b operates with an inlet valve 34i and an outlet valve 34o. In one embodiment, the blood pump pods 30a and 30b are each blood containers including a rigid outer shell, e.g., spherical, 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 positive and negative air pressure. The blood pump 30 may alternatively be a peristaltic pump operating with the arterial line 14 or multiple peristaltic pumps operating with the arterial line 14 and the venous line 16.

[0098] 2, a heparin vial 24 and a heparin pump 26 are located between a blood pump 30 and a hemofilter 40 (e.g., a dialyzer). The heparin pump 26 may be a pneumatic pump or a syringe pump (e.g., a stepper motor-driven syringe pump). Providing heparin upstream of the hemofilter 40 helps prevent clotting of the filter membrane.

[0099] A primary control processor (“ACPU”) or control unit 50 includes one or more processors and memory. Control unit 50 receives air detection signals from air detectors 22a and 22v (and other sensors of medical fluid delivery machine 90, such as temperature sensors, blood leak detectors, conductivity sensors, pressure sensors, and access disconnection 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 exiting hemofilter 40 via venous line 16 flows through air trap 28. The exemplary air trap 28 removes air from the dialyzed blood before it is returned to patient 12 via venous line 16.

[0100] In the hemodialysis version of the medical fluid delivery machine 90 of FIG. 2 , dialysis fluid is pumped along the outside of the membrane of the hemofilter 40, while blood is pumped through the inside of the hemofilter membrane. The dialysis fluid is prepared beginning with the purification of water via a water purification unit 60. One suitable water purification unit is described in U.S. Patent Publication No. 2011 / 0197971, entitled “Water Purification System and Method,” filed April 25, 2011, the entire contents of which are incorporated herein by reference. In certain embodiments, the water purification unit 60 includes filters and other structures for purifying tap water (e.g., removing pathogens and ions such as chlorine) so that the water, in one implementation, has less than 0.03 endotoxin units / ml (“EU / ml”) and less than 0.1 colony forming units / ml (“CFU / ml”). The water purification unit 60 may be provided in a housing separate from the housing or chassis of the hemodialysis machine 90, which includes the blood circuit 20 and the dialysis fluid circuit 70.

[0101] The dialysis fluid circuit 70 is again greatly simplified in FIG. 2 for ease of illustration. An actual dialysis fluid circuit 70 may include all of the relevant structures and functionality described in the publications incorporated by reference above. Certain features of the dialysis fluid circuit 70 are illustrated in FIG. 2. In the illustrated embodiment, the dialysis fluid circuit 70 includes a hemofilter dialysis fluid pump 64. The exemplary pump 64 is configured identically to the blood pump 30 in one embodiment. Like the pump 30, the pump 64 includes a pair of pump pods 66, which may again be spherically configured, each having an inlet valve 68i and an outlet valve 68o. Like the blood pump 30, the two pump pods are alternately operated so that one pump pod fills with HD dialysis fluid while the other pump pod expels HD dialysis fluid.

[0102] Pump 64 is a hemofilter-bound dialysis fluid pump. There is another dual pod pump chamber 96 that operates with valves 98i and 98o located in drain line 82 to push spent dialysis fluid to drain. There is a third pod pump (not shown) for pumping purified water through bicarbonate cartridge 72. There may be a fourth pod pump (not shown) used to pump acid from acid container 74 into mixing line 62. The third and fourth pumps, in one embodiment, may be a single pod pump because continuous pumping is less critical in mixing line 62 due to a buffered dialysis fluid tank (not shown) between mixing line 62 and hemofilter-bound dialysis fluid pump 64.

[0103] A fifth pod pump (not shown) may be provided in the drain line 82 to remove a known amount of ultrafiltrate ("UF") as HD therapy is delivered. The medical fluid delivery machine 90 tracks the UF pump to control and keep track of the amount of ultrafiltrate removed from the patient. The medical fluid delivery machine 90 ensures that the required amount of ultrafiltrate is removed from the patient by the end of treatment.

[0104] Each of the pumps described above may alternatively be peristaltic pumps operating in conjunction with pumping tubing. Where applicable, system valves may still be pneumatically actuated in accordance with features of the present disclosure.

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

[0106] 2 also illustrates that the dialysis fluid is pumped along fresh dialysis fluid line 76 through heater 78 and ultrafilter 80 before reaching hemofilter 40, after which the spent dialysis fluid is pumped to be discharged via drain line 82. Heater 78 heats the dialysis fluid to body temperature or approximately 37° C. Ultrafilter 80 further cleanses and purifies the dialysis fluid before it reaches hemofilter 40, filtering out foreign particles and / or contaminants introduced from the dialysis fluid, for example, via bicarbonate cartridge 72 or acid container 74.

[0107] The exemplary dialysis fluid circuit 70 also includes a sample port 84. The dialysis fluid circuit 70 may further include a blood leak detector (not shown, but used to detect whether the fibers of the hemofilter 40 have ruptured) and other components not shown, such as a balance chamber, multiple dialysis fluid valves, and a dialysis fluid holding tank, all of which are illustrated and described in detail in the publications incorporated by reference above.

[0108] In the illustrated embodiment, the medical fluid delivery machine 90 is an online pass-through system that pumps the dialysis fluid through the hemofilter once and then pumps the spent dialysis fluid to drain. Both the blood circuit 20 and the dialysis fluid circuit 70 may be hot-water disinfected after each treatment so that the blood circuit 20 and the dialysis fluid circuit 70 may be reused. In one implementation, the blood circuit 20, including the hemofilter 40, may be hot-water disinfected and reused daily for approximately one month, while the dialysis fluid circuit 70 may be hot-water disinfected and reused for approximately six months.

[0109] In an alternative embodiment, for example, for CRRT, multiple bags of sterile dialysis or infusion fluid are grouped together and used one after the other. In such cases, an empty supply bag can serve as the drain or depleted fluid bag.

[0110] The medical fluid delivery machine 90 includes an enclosure as indicated by the dashed lines in Figure 2. The enclosure of the machine 90 varies depending on the type of treatment, whether the treatment is in-center or home treatment, and whether the dialysis fluid / infusate supply is batch-type (e.g., bagged) or online.

[0111] In some embodiments, the medical fluid delivery machine 90 of FIG. 2 is configured to implement one or more prescribed PD therapies or programs. In these embodiments, the fresh dialysis fluid comprises a peritoneal dialysis solution containing a solution or mixture having 0.5% to 10%, preferably 1.5% to 4.25%, dextrose (or more generally, glucose). The peritoneal dialysis solution may include, for example, Dianeal®, Physioneal®, Nutrineal®, and / or Extraneal® dialysates, commercially available from the assignee of the present disclosure. The dialysate may additionally or alternatively include a percentage of icodextrin.

[0112] In PD embodiments, the blood circuit 20, including the hemofilter, is eliminated. Instead, a fresh dialysis fluid line 76 is connected to a catheter placed adjacent to the peritoneal cavity of the patient 12. The catheter is also connected to a drain line 82, which removes spent dialysis fluid, including accumulated UF. In some embodiments, the drain line 82 may be connected to a recirculation device, such as a sorbent cartridge, configured to clean the spent dialysis fluid before it is returned to the patient's peritoneal cavity. In some cases, the recirculation device may remove uremic toxins from the waste dialysate and reinfuse therapeutic agents (such as ions and / or glucose). One commonly used sorbent is made from zirconium phosphate, which is used to remove ammonia generated from the hydrolysis of urea. B. Exemplary Medical Fluid Delivery System Connectivity Embodiments

[0113] 3 illustrates a schematic diagram of the medical fluid data transfer system 10 of FIG. 1 in accordance with certain exemplary embodiments of the present disclosure. The exemplary medical fluid data transfer system 10 includes a personal mobile communication device 122, operated by, for example, 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 meter 106, and a therapy machine 90 (e.g., a medical fluid delivery machine), similar to the individual devices discussed above in connection with FIGS. 1 and 2. The personal mobile communication device 122, therapy machine 90, blood pressure monitor 104, and meter 106 may be located, for example, in the patient's home, a self-service clinic, and / or a service medical clinic.

[0114] Therapy machine 90 may include any type of hemodialysis machine, peritoneal dialysis machine, CRRT machine, drug and / or nutrient fluid delivery machine, and combinations thereof. Therapy machine 90 may provide, for example, continuous cycling peritoneal dialysis ("CCPD"), tidal flow automated peritoneal dialysis ("APD"), and continuous flow peritoneal dialysis ("CFPD"). Therapy machine 90 may automatically perform drain, fill, and dwell cycles, typically while the patient sleeps.

[0115] The exemplary therapy machine 90 may also include one or more control interfaces 301 for displaying instructions and receiving control inputs from a user. The control interface 301 may include buttons, a control panel, and / or a touch screen. The control interface 301 may also be configured to allow a user to navigate to certain windows or user interfaces on the screen of the therapy machine 90. The control interface 301 may further provide instructions for operating or controlling the therapy machine 90.

[0116] The exemplary therapy machine 90 may receive one or more prescribed therapies or programs remotely from the clinician server 304 and / or the clinician database 306. Additionally, or alternatively, the therapy machine 90 may be locally programmed via the control interface 301 with the prescribed therapies or programs. As discussed herein, the prescribed therapies include parameters that define how the therapy machine 90 should administer one or more scheduled therapies to a patient (e.g., patient 12 of FIG. 1 ). Therapy parameters may include the number of fill-dwell-drain cycles for peritoneal dialysis therapy, as well as the duration of each step. Therapy parameters may also include the total volume of dialysis fluid to be administered (and / or the volume of fluid to be administered per cycle), the glucose concentration, and / or the target UF removal level. Therapy parameters may also include a schedule of treatment dates and a total treatment duration. In some embodiments, the clinician server 304 may remotely update any one of the prescribed therapy parameters.

[0117] The exemplary blood pressure monitor 104 includes any device configured to measure a patient's blood pressure and / or pulse. For example, the blood pressure monitor 104 may measure the patient's blood pressure before, during, and / or after a renal failure therapy treatment. The blood pressure monitor 104 may display a digital value indicating the patient's blood pressure. Alternatively, the blood pressure monitor 104 may display a physical scale with a dial matching the numerical value to indicate the measured blood pressure. In some embodiments, the blood pressure monitor 104 may store blood pressure values ​​before, during, and / or after treatment in a separate window so that when medical information is recorded, patient input is required to view all values. The blood pressure monitor 104 may be integrated with the therapy machine 90. In another embodiment, the blood pressure monitor 104 may include a wearable sensor such as a smartwatch or fitness tracking device. The blood pressure monitor 104 may transmit measured blood pressure values ​​(e.g., therapy data) to the therapy machine 90 and / or personal mobile communication device 122 via a wired or wireless connection, which is then routed to the system hub 120 for processing.

[0118] Exemplary weighing scales 106 include any device configured to measure the mass of a patient or a therapy component. For example, the weighing scale 106 may measure the patient's weight before, during, and / or after a renal failure therapy treatment. Additionally or alternatively, the weighing scale 106 may measure a supply or drain bag to track renal failure therapy. Specifically, the weighing scale 106 may be used to measure the amount of UF removed or the amount of fluid provided to the patient. The weighing scale 106 may display a digital value indicating the weight. Alternatively, the weighing scale 106 may transmit the measured weight value (e.g., therapy data) to the therapy machine 90 and / or personal mobile communication device 122 via a wired or wireless connection, which is then routed to the system hub 120 for processing.

[0119] Collectively, the blood pressure monitor 104 and the meter 106 are referred to as medical devices. It should be understood that the medical fluid data transfer system 10 may include additional medical devices, such as an infusion pump (e.g., a syringe pump, a linear peristaltic pump, a large volume pump ("LVP"), an ambulatory pump, a multi-channel pump), an oxygen sensor, a respiratory monitor, a glucose meter, a blood pressure monitor, an electrocardiogram ("ECG") monitor, and / or a heart rate monitor. In other embodiments, the medical fluid data transfer system 90 may include fewer medical devices and / or co-integrated medical devices (e.g., a blood pressure monitor 104 integrated with the therapy machine 90).

[0120] As shown in Figure 3, the therapy machine 90 is communicatively coupled to the connectivity server 118 via a network 302. As discussed above in connection with Figures 1 and 2, the connectivity server 118 provides bidirectional communication between the therapy machine 90 and the system hub 120. The network 302 may include any wired or wireless network, including the Internet and / or a cellular network.

[0121] The example system hub 120 is also communicatively coupled to 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 performing analyses on therapy data. The clinician database 306 is configured to store prescribed therapies or programs for each patient associated with the system 10. The clinician database 306 is also configured to store one or more records for each patient, including therapy data and / or patient data from the individual therapy machines 90. The clinician database 306 may also store results of analyses performed by the clinician server 304 on the therapy and / or patient data. Additionally, the clinician database 306 may store data structures that associate therapy recommendations and / or guidelines, such as those defined by the ISPD, NKF, and / or NKF DOQI, with ranges of analytical values ​​corresponding to patient therapy compliance, catheter activity, and / or alarms.

[0122] As illustrated in FIG. 3 , the exemplary medical fluid data transfer system 10 includes a web portal 150 to facilitate the transmission of data to clinician devices 152 and / or personal mobile communication devices 122 via a network 308. The exemplary network 308 may include any wired and / or wireless network, such as the Internet and / or a cellular network. The web portal 150 may include one or more application programming interfaces (“APIs”) or other network interfaces that provide for communication of treatment data, patient data, analysis data, and / or recommendations / guidelines. In some instances, the web portal 150 may be configured as a gateway device and / or firewall so that only authorized users and / or devices may communicate with the clinician server 304 and / or clinician database 306. Additionally, the web portal 150 may create a separate session for each connected device 122 and 152.

[0123] The clinician device 152 and / or the personal mobile communication device 122 may include an application 320 configured to interface with the web portal 150 to communicate with the clinician server 304 and / or the clinician database 306. For example, the application 320 may include one or more user interfaces with data fields (discussed further below) that display treatment data, patient data, and / or analytical data. The data fields are mapped to one or more APIs in the web portal 150, which are linked to one or more data structures in the clinician database 306 and / or the clinician server 304. Selection of a user interface through the application 320 causes a request message to be transmitted from the application 320 to the web portal 150, identifying the data fields associated with the requested user interface. The request message may also identify the patient. In response, the web portal 150 transmits one or more request messages to the clinician database 306 and / or clinician server 304 to retrieve treatment, patient, and / or analytical data associated with the identified patient and the identified data field.

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

[0125] In some instances, the web portal 150 is configured to convert the treatment data and / or analysis data from text-based 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, the connectivity server 118 is configured to convert the HL7 treatment data from the therapy machine 90 into a text-based or web-based format (e.g., JSON format) for processing by the clinician server 304 and storage by the clinician database 306.

[0126] 3 , the exemplary personal mobile communications device 122 and clinician device 152 include a processor 322 in communication with a memory 324 that stores instructions. At least some of the instructions, when executed by the processor 322, define or prescribe an application 320 that causes the processor 322 to provide an interface for displaying and interacting with treatment data, patient data, and / or analysis data stored in the clinician database 306. The processor 322 may comprise digital and / or analog circuitry structured as a microprocessor, an application specific integrated circuit (“ASIC”), a controller, or the like. The memory 324 includes a volatile or non-volatile storage medium. Additionally, the memory 324 may include any solid-state or disk storage medium. II. Therapeutic Analysis Embodiments

[0127] The example clinician server 304 of Figure 3 is configured to analyze patient treatment data from a therapy machine 90 (e.g., a medical fluid delivery machine) and determine patient compliance with a prescribed therapy or program. Figure 4 shows a schematic diagram of the clinician server 304, according to an example embodiment of the present disclosure. 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 guideline processor or engine 310c. The processors 310a-310c are defined by one or more machine-readable instructions that specify how the treatment data should be processed, stored, and accessed for display on the clinician device 152 (and / or personal mobile communication device 122). A. Data Analysis Implementation Example

[0128] As shown in FIG. 4 , the analysis processor 310a receives therapy data 402 from the therapy machine 90. The therapy data 402 includes data 402a used to determine adherence, data 402b used to determine catheter functionality, and data 402c used to determine alarm fatigue. The data 402 is received from the therapy machine 90 in one or more therapy log files. The analysis processor 310a is configured to parse or otherwise extract needed data from the log files using data tags, metadata, or pre-programmed knowledge of the data placement within the files. In some embodiments, the data 402 is received from the therapy machine 90 into the clinician database 306 and subsequently accessed by the analysis processor 310a.

[0129] In some embodiments, the therapy data 402 may include an identifier for storing or organizing the data in the clinician database 306. For example, the therapy machine 90 may include a device identifier with the data 402 and / or a patient identifier. The analysis processor 310a is configured to use the identifier to store the therapy data 402 and corresponding analysis data in the appropriate patient record in the database 306. In some instances, the analysis processor 310a may use the identifier to distinguish as to whether the therapy data 402 is from a home therapy machine 90 or a machine 90 located in a clinic. The analysis processor 310a may distinguish between treatment delivery locations to determine whether a patient is more compliant at home or in a clinical setting.

[0130] In addition to the treatment data 402, the example clinician database 306 may store patient data 412. The patient data 412 includes information related to the patient. The patient data 412 may include a patient identifier, a patient name, a patient age, a gender, a medical condition, renal status information, and / or an estimated experience level with the therapy machine 90. The patient data 412 may be transmitted to the clinician database 306 from the personal mobile communication device 122 and / or the clinician device 152. In some embodiments, the patient data 412 is provided when the patient is enrolled in the medical fluid data transfer system 10 disclosed herein.

[0131] The adherence-related therapy data 402a includes an indication of the date and / or time the therapy was administered by the therapy machine 90. The therapy data 402a also includes the duration of the therapy and the measured dwell time per cycle of the therapy (and / or the cumulative dwell time over all cycles). In some embodiments, the therapy data 402a may also include the total volume of dialysate provided to the patient, the glucose level of the peritoneal dialysis fluid, the estimated amount of UF removed, and / or an indication of a therapy-related event that occurred during the therapy (such as a pause in therapy).

[0132] The therapy data 402b related to catheter operability includes the fill time or rate per cycle (and / or the cumulative fill time across all cycles). The therapy data 402b also includes the drain time or rate per cycle (and / or the cumulative drain time across all cycles). In some instances, the analysis processor 310a is configured to calculate the average fill time and drain time across all cycles of the therapy. In some embodiments, the therapy data 402c may include an indication of any alarms activated during the therapy due to line occlusion during the fill or drain phase of the cycle, which may indicate an at least partially blocked catheter. The therapy data 402c may also include an indication of any alarms activated during the therapy due to fluid leakage during the fill or drain phase of the cycle, which may indicate a misaligned catheter.

[0133] The therapy data 402c related to alarm fatigue includes an indication of alarms generated by the therapy machine 90 during therapy. The therapy data 402c may also include an indication as to the alarm type, the duration of the alarm, and / or whether the condition that triggered the alarm was corrected or whether the patient dismissed or bypassed the alarm. The therapy data 402c may further include an indication as to whether the alarm was escalated or whether therapy was terminated as a result of the alarm.

[0134] FIG. 5 is a diagram illustrating at least some of the calculations performed by the analysis processor 310a of FIG. 4 , according to certain exemplary embodiments of the present disclosure. In an exemplary embodiment, the analysis processor 310a is configured to compare treatment data 402 to one or more parameters 404 defined in a prescribed therapy or program. 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 the prescribed therapy or program stored in the patient-related database 306. The analysis processor 310a may use data labels, field names, metadata, and / or text settings to identify the parameters 404. Furthermore, in some embodiments, the patient-specific or general thresholds or limits may be stored as parameters 404 in the clinician database 306.

[0135] 5, the therapy data 402a may include a therapy duration parameter 402aa indicating the therapy duration during which the therapy machine 90 administered the prescribed therapy. The analysis processor 310a is configured to compare or determine the difference between the therapy duration parameter 402aa and the prescribed therapy duration parameter 404a, indicating how long the therapy machine 90 should administer the therapy. The result of the comparison is stored as compliance analysis data 406a (i.e., lost therapy time parameter 406aa). The lost therapy time parameter 406aa indicates the amount of therapy time lost due to the therapy under analysis being terminated early.

[0136] 4, the analysis processor 310a is configured to store a lost treatment time parameter 406aa in the clinician database 306 within a record associated with the patient. The value in the lost treatment time parameter 406aa may be summed with values ​​from previous treatments to determine a cumulative lost treatment time parameter value. In some embodiments, the analysis processor 310a may determine the ratio of the cumulative lost treatment time to the total prescribed treatment time (for treatments already administered) to determine the percentage of treatment time lost due to early termination of treatment.

[0137] 5, the therapy data 402a may include a dwell time parameter 402ab indicating the length of time the therapy machine 90 allowed the dialysis fluid to remain in the patient's peritoneal cavity before draining. The dwell time parameter 402ab may be an average over all cycles of the therapy or may include a cycle-by-cycle dwell time value. The analysis processor 310a is configured to compare or determine the difference between the dwell time parameter 402ab and the estimated dwell time parameter 404b, which indicates the estimated dwell time (e.g., based on expected or prescribed fill and drain times). The result of the comparison is stored as compliance analysis data 406a (i.e., lost dwell time parameter 406ab). The lost dwell time parameter 406ab indicates the amount of time lost to absorb UF due to the therapy (or specific dwell time) under analysis being terminated early.

[0138] 4, the analysis processor 310a is configured to store the dwell time parameter 406ab in the clinician database 306 within the record associated with the patient. The value in the dwell time parameter 406ab may be summed or combined with values ​​from previous treatments to determine a cumulative lost dwell time parameter value. In some embodiments, the analysis processor 310a may determine the ratio of the cumulative lost dwell time to the total estimated dwell time (for treatments already administered) to determine the percentage of dwell time lost due to treatments (or individual dwells) being terminated early.

[0139] Referring again to FIG. 5 , the therapy data 402b may include a drain time parameter 402ba indicating the amount of time elapsed before the therapy machine 90 drains the UF and dialysis fluid from the patient's peritoneal cavity. The drain time parameter 402ba may include a cycle-by-cycle value or an average over all cycles during therapy. The analysis processor 310a is configured to compare or determine a difference between the drain time parameter 402ba and one or more thresholds 404c. A drain time value above a first threshold may indicate that additional time is required to drain the dialysis fluid and UF from the patient, which may be due to a partial blockage in the catheter. A drain time value below a second threshold may indicate that less time is required to drain the dialysis fluid and UF from the patient than expected, which may in some cases be due to an incorrectly placed catheter leaking some fluid. The results of the comparison are stored as catheter analysis data 406b (i.e., difference parameter 406ba). If an alert should be generated, the analysis processor 310 a is configured to cause the alert to be transmitted to the clinician device 152 .

[0140] 4, the analysis processor 310a is configured to store catheter analysis data 406b in the clinician database 306 within a record associated with the patient. Values ​​and / or alarm indications in the catheter analysis data 406b may be combined with values ​​and / or alarm indications from previous treatments to determine cumulative drainage time trends. In some embodiments, the analysis processor 310a may determine drainage time averages over 7, 30, 50, 90, and / or 180 day averages or the most recent drainage time averages for display in the user interface.

[0141] Returning to FIG. 5 , the therapy data 402b may include a fill time parameter 402bb indicating the amount of time elapsed before the therapy machine 90 filled the patient's peritoneal cavity with dialysis fluid. The fill time parameter 402bb may include a cycle-by-cycle value or an average over all cycles during therapy. The analysis processor 310a is configured to compare or determine a difference between the fill time parameter 402bb and one or more thresholds 404d. A fill time value below a first threshold indicates less time than expected to fill the patient's peritoneal cavity with fluid, which, in some embodiments, may be due to an incorrectly placed catheter. A fill time value above a second threshold indicates more time than expected is required to fill the patient's peritoneal cavity with fluid, which may be due to a 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 should be generated, the analysis processor 310a is configured to transmit the alert to the clinician device 152.

[0142] 4, the analysis processor 310a is configured to store catheter analysis data 406b in the clinician database 306 within a record associated with the patient. Values ​​and / or alarm indications in the catheter analysis data 406b may be combined with values ​​and / or alarm indications from previous treatments to determine a cumulative fill time trend. In some embodiments, the analysis processor 310a may determine an average fill time within one to two weeks or an average fill time for the most recent period for display in the user interface.

[0143] Returning to FIG. 5 , the therapy data 402c may include alarm parameters 402c indicating alarms generated during therapy. The alarm parameters 402c may define the type of alarm generated, the time the alarm was generated, the duration of the alarm, whether the condition triggering the alarm was resolved, or an indication of whether the alarm was bypassed, silenced, or escalated. The alarm parameters 402c are compared to one or more thresholds 404e. If the number of alarms generated during therapy exceeds a certain threshold, the patient may be suffering from alarm fatigue. Thus, the analysis processor 310a is configured to generate alarm parameters 406 for transmission to the clinician device 152, indicating possible alarm fatigue.

[0144] 4, the analysis processor 310a is configured to store alarm analysis data 406c in the clinician database 306 within a record associated with the patient. The values ​​and / or alarm indications in the alarm analysis data 406c may be combined with values ​​and / or alarm indications from previous treatments to determine a total number of alarms generated per treatment or an average number of alarms. In some embodiments, the analysis processor 310a may determine the average number of alarms generated when the patient uses a home machine 90 versus a clinic-located machine 90.

[0145] It should be understood that the analysis processor 310a may analyze and / or compare other therapy data parameters. For example, the analysis processor 310a may compare the estimated UF removed during therapy with the prescribed amount of UF to be removed to determine how closely the patient is meeting therapy targets. The analysis processor 310a may also compare the actual dialysis fluid administered to the patient during therapy with the prescribed amount. The analysis processor 310a may also compare glucose levels with prescribed glucose levels to ensure the patient is using the prescribed dialysis fluid. Additionally, the analysis processor 310a may track how the patient's blood pressure and / or weight are changing over time to detect potential fluid accumulation. In these cases, the analysis processor 310a may compare the blood pressure and / or weight with baseline patient blood pressure or weight and / or rate change thresholds.

[0146] 4 illustrates that in some embodiments, the application 310 of the clinician server 304 includes an interface 310b communicatively coupled to the analysis processor 310a and the clinician database 306. In other embodiments, the interface 310b may be included within the web portal 150. The example interface 310b is configured to read or otherwise obtain the treatment data 402, the analysis data 406, and / or the patient data 412. The interface 310b may include one or more APIs for retrieving the data 402, 404, 406, and / or 412 from the clinician database 306.

[0147] The example interface 310b is configured to receive request messages from the application 320 on the personal mobile communication device 122 and / or the clinician device 152. The request message may, for example, identify a user interface, data fields, and / or a web page for display. The request message may also identify a session and / or a patient. In response to the request message, the interface 310b creates a response document 420 containing the requested data. To create the document 420, the interface 310b accesses the requested patient record in the clinician database 306 and identifies the requested data 402, 404, 406, and / or 412. The data may include singular values ​​or trends over time that correspond to graphs displayed by the user interface. The interface 310b organizes the retrieved data by data fields into the response document 420 for incorporation by the application 320 into an appropriate user interface. The interface 310b may also label or provide metadata identifiers for the data to enable the application 320 to store the data in the 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 should be displayed within the web browser application 320. The interface 310b transmits the response document 420 to the personal mobile communications device 122 and / or clinician device 152 via the web portal 150.

[0148] In some embodiments, the analysis processor 310a may transmit the newly processed analysis data 406 to the interface 310b. In response, the interface 310b may update the user interfaces on the personal mobile communication device 122 and / or the clinician device 152 in near real time. In alternative embodiments, the analysis processor 310a transmits all of the analysis data 406 to the clinician database 306 instead of to the interface 310b. 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.) and updates the user interfaces on the personal mobile communication device 122 and / or the clinician device 152.

[0149] 6-13 illustrate example user interfaces created, rendered, or otherwise provided by the application 320 on the personal mobile communication device 122 and / or clinician device 152 using at least some data 402, 404, 406, and / or 412 from the clinician database 306, according to certain example embodiments of the present disclosure. FIG. 6 shows a schematic diagram of an example dashboard user interface 600, according to certain example embodiments of the present disclosure. The dashboard user interface 600 provides an overall view of a patient's adherence to one or more prescribed therapies or programs administered by one or more therapy machines 90 (e.g., medical fluid delivery machines). The user interface 600 may be displayed by the application 320 on the clinician device 152, for example, after selection of a patient's name from among a list of patients the clinician is treating or otherwise involved in overseeing. The user interface 600 may be displayed by the application 320 on the personal mobile communication device 122 as a front or loading page, as patients would not be allowed to see other patients' information.

[0150] The user interface 600 includes a trigger section 602. In the illustrated example, the trigger section 602 displays the current values ​​of the adherence analysis data and the trigger value or threshold for generating an alert. The trigger section 602 also displays the current values ​​of the weekly averages for drain time and fill time treatment data, in addition to the trigger value or threshold. The user interface 600 also includes a summary section 604 that shows the adherence analysis data for the patient compared to the clinic average (or the average of multiple patients at multiple clinics). In the illustrated example, the patient has lower adherence compared to the population of patients receiving treatment at the clinic (from which the treatment data is received). The summary section 604 also shows the catheter treatment data as defined by the average fill and drain times. The summary section 604 further shows the average number of alarms per treatment for the patient compared to the clinic average. The summary section 604 allows the user to view data over the past 30, 60, 90, and / or 180 days.

[0151] In some cases, the application 320 is configured to allow a clinician to define trigger values ​​or thresholds for compliance, catheter health, and / or alarms. For example, selecting a link or field in the user interface 600 may cause the application 600 to load another user interface that allows the trigger values ​​and / or thresholds to be modified by the clinician. A threshold may include a discrete number or percentage increase over a period of time or during a treatment. Setting a trigger value or threshold may cause the value to be transmitted to the interface 310b of the clinician server 304 and stored in the clinician database 306 as a threshold parameter 404. Setting a trigger value may, for example, cause the interface 310b or the analysis processor 310a to display an icon, notification, or other alert on the patient or treatment dashboard user interface (or via a push notification message) indicating that the treatment or analysis data exceeds the threshold or trigger.

[0152] 7 illustrates an adherence user interface 700 displaying adherence analysis data, according to an exemplary embodiment of the present disclosure. The adherence user interface 700 indicates whether a particular patient meets prescribed treatment dates, total treatment time, and / or estimated dwell time. Such information provides early detection of poor treatment delivery, thereby providing for early intervention by clinicians. Generally, adherence below 90% is associated with significant increases in technique failure, peritonitis rates, hospitalizations, and / or mortality. The user interface 700 may be displayed by the application 320 in response to a user selection of adherence analysis data within the user interface 600.

[0153] The user interface 700 includes a numeric section 702 and a graph section 704 that display adherence analysis data over a 30-, 60-, 90-, or 180-day period. The interface 700 includes an adherence summary over different time periods to provide patient adherence trends. Sections 702 and 704 display patient adherence compared to average adherence for patients at the same clinic (from which the data is received) or for multiple patients at one or more clinics. Additionally, sections 702 and 704 display the percentage or proportion of missed treatment days in which treatment was not administered as scheduled, the percentage or proportion of completed treatment days in which scheduled treatment was administered, the percentage or proportion of treatment time lost from completed treatment (indicating the patient terminated treatment early), and the percentage or proportion of lost dwell time from completed treatment (indicating the patient bypassed the entire dwell phase of the cycle). Lost dwell time information is particularly important because it conveys the amount of opportunity or prescription time lost for the patient's UF absorption due to elimination.

[0154] FIG. 8 illustrates a treatment time user interface 800 that may be displayed by application 320 in response to selection of treatment data within user interface 600 or 700. User interface 800 displays a scatter plot of treatment times for a patient, relating prescribed treatment times to actual treatment times. In the illustrated example, interface 310b of FIG. 4 is configured to transmit individual treatment times and prescribed treatment times for each day of scheduled treatment within document 420. Application 320 populates the treatment data from document 420 into data fields associated with user interface 800 and generates the scatter plot. As shown, the prescribed treatment time increases slightly over time, from approximately 450 minutes to 480 minutes. In comparison, actual treatment times vary and are generally less than the prescribed treatment time. A user may mouse over each data point on the scatter plot of user interface 800 to cause application 320 to display the time, date, and / or prescribed / actual treatment time values. The user interface 800 also shows the average actual treatment time over a 30-day, 60-day, 90-day, or 180-day period.

[0155] FIG. 9 illustrates a dwell time user interface 900 that may be displayed by application 320 in response to selection of dwell data within user interface 600 or 700. User interface 900 displays a scatter plot of dwell times for a patient, relating estimated dwell times (calculated from prescribed or defined fill and drain times) to actual dwell times. As shown, the estimated dwell time remains constant at approximately 87 minutes per cycle in therapy. In comparison, actual dwell times fluctuate and are generally less than the estimated dwell times. A user may mouse over each data point on the scatter plot to have the application display the time, date, and / or estimated / actual dwell time values. User interface 900 also displays the average actual dwell time over a 30-, 60-, 90-, or 180-day period.

[0156] 10 and 11 show separate drain and fill time user interfaces 1000 and 1100 that may be displayed by application 320 in response to selection of drain or fill time analysis data within user interface 600 or 700. Drain and fill time user interfaces 1000 and 1100 show scatter plots of average drain and fill times per treatment. The displayed information provides early indication of problems with a patient's catheter, where a slow decrease or increase in fill or drain time may not be noticeable when viewed on a daily basis. The data may indicate catheter flow restriction, misalignment, clogging, and / or fibrin strand buildup.

[0157] The drain time user interface 1000 shows the individual average drain time per treatment relative to a trend line, which in this embodiment indicates that the average drain time increased from 17 minutes to 19 minutes. The user interface 1000 also shows the average actual drain time over a 7-day, 30-day, 60-day, 90-day, or 180-day period, indicating that a recent increase in drain time may indicate a problem with the catheter. The fill time user interface 1100 shows the individual average fill time per treatment relative to a trend line, which in this embodiment indicates that the average fill time decreased from 8 minutes to 7.5 minutes. The difference in the change in fill time relative to the change in drain time may provide information indicating a flow restriction where a faster fill rate may not be affected by a partial blockage of the catheter. The user may mouse over any of the data points in the user interfaces 1000 and 1100 to view the date, time, and value per minute of the value.

[0158] 12 and 13 show alarm user interfaces 1200 and 1300 for displaying alarm analysis data, according to an exemplary embodiment of the present disclosure. The alarm user interface 1200 of FIG. 12 includes a scatter plot of the average number of alarms generated by the therapy machine 90 during a treatment. The plot also includes a trend line for the alarms. The plot may be used by clinicians for early intervention to resolve alarm issues for patients and provide better rest periods and better adherence to their prescribed therapy or program. An increase in alarms per treatment may indicate compliance issues, catheter problems, and / or technique failures. An increase in alarms may lead to patient sleep disturbances and alarm fatigue. In some instances, the user interface may show the date / time the alarm was generated and the type of alarm and / or an indication of whether the alarm was silenced, escalated, or resolved. The user interface 1200 also shows the average number of alarms over a 30-day, 60-day, 90-day, or 180-day period.

[0159] FIG. 13 shows a user interface 1300 including average alarm types per therapy over different time periods. Alarm types include, for example, fill manual bypass, drain manual bypass, smart drain alert, and dwell time manual bypass. The illustrated alarms indicate the patient completing the fill, dwell, and drain phases earlier than prescribed. In other embodiments, the user interface 1300 may display alarms indicating access disconnection detection, line occlusion, etc. In some embodiments, the alarms may also indicate whether measured therapy data exceeds one or more thresholds for pre / post therapy blood pressure, blood glucose, pre / post patient weight, heart rate, drained UF, kt / V, CCI, fill volume, drain volume, transporter type, number of manual exchanges, etc. The number and types of alarms shown in the user interface 1300 may be used by clinicians for therapy intervention to reduce the number of recurring alarms or help identify patient therapy compliance issues. B. Recommended Treatment Practices

[0160] 4, the exemplary application 310 on the clinician server 304 may include a guideline processor 310c configured to provide evidence-based analysis or apply evidence-based models. The guideline processor 310c is configured to analyze the data 402, 404, 406, and / or 412 and provide recommendations and / or guidelines regarding the clinical benefits and risks of prescribed therapies and / or programs. The recommendations and / or guidelines are actionable by the clinician to proactively engage with the patient to improve adherence, catheter problems, and / or alarm problems.

[0161] In some embodiments, clinician database 306 stores data structure 428 that associates recommendations and / or guidelines with at least some portions or ranges of 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. The recommendations or guidelines may include recommended therapy or program settings or parameters for modifying a prescribed therapy or program. The recommendations or guidelines may also include recommended settings or ranges for notification thresholds. The recommendations or guidelines may further include analysis / metric definitions, links to websites with additional information, typical clinician values ​​for similar patients, potential patient-related risks, and / or actions for the clinician to take, such as contacting the patient, scheduling maintenance on the catheter or therapy machine 90, or silencing certain alarms on the therapy machine 90.

[0162] 4 is configured to compare data 402, 404, 406, and / or 412 with one or more thresholds or ranges for recommendations and / or guidelines provided in data structure 428. If at least some of data 402, 404, 406, and / or 412 corresponds to a recommendation or guideline, guideline processor 310c creates recommendation document 430 that includes the identified recommendation or guideline. Guideline processor 310c causes interface 310b to transmit recommendation document 430 to application 320 for display.

[0163] To create the guideline document 430, the guideline processor 310c may include the text of the associated recommendations and / or guidelines. Additionally or alternatively, the guideline processor 310c may access a list of predefined guidelines or recommendations stored in the data structure 428. The guideline processor 310c identifies the predefined guidelines or recommendations that correspond to the comparison. After making the identification, the guideline processor 310c writes the predefined guidelines or recommendations to the recommendation document 430. In some embodiments, the guideline processor 310c may access web pages or other web-based content via one or more links in the associated guidelines or recommendations to obtain text or multimedia content for incorporation into the guideline document 430.

[0164] 14 shows the compliance user interface 700 of FIG. 7 with an icon 1402 that allows the user to view recommendations or guidelines determined by the guideline processor 310c. The application 320 may display the icon 1402 after the recommendation document 430 is received. Alternatively, selection of the icon 1402 may cause the guideline processor 310c to transmit instructions to create the recommendation document 430.

[0165] In some embodiments, selection of icon 1402 causes application 320 to display recommendation user interface 1404. In the illustrated example, guideline processor 310c has concurrently or previously determined that recommendations exist for patients with adherence metrics below 90%. Guideline processor 310c extracts the associated recommendations and guidelines, which are displayed in user interface 1404. The guidelines include a brief explanation of possible causes for the low adherence rate, as well as actions the clinician can take to help the patient improve adherence. The recommendations in user interface 1404 include links to websites or web pages with additional information or content to assist the clinician. In some cases, the link may open an email program, a text messaging program, or initiate a phone call to the patient to allow the clinician to quickly connect with the patient. In other cases, the link may open a user interface with editable fields related to the prescribed therapy or program. If warranted, the clinician may use the interface to modify or create new prescription therapies or programs, which are transmitted to the clinician server 304 for processing / verification prior to transmission to the therapy machine 90. C. Exemplary Procedure for Therapeutic Analysis

[0166] FIG. 15 is a flow diagram of an example procedure 1500 for generating analytical data 406 using treatment data 402 and / or thresholds / parameters 406 of a prescribed therapy or program, according to an example embodiment of the present disclosure. While procedure 1500 is described with reference to the flow diagram illustrated in FIG. 15 , it should be understood that many other ways of implementing the steps associated with procedure 1500 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the described blocks may be optional. In an embodiment, the number of blocks may be changed based on the analytical data determined. Additionally, steps of determining recommendations and / or guidelines may be omitted. The actions described in procedure 1500 are defined by one or more instructions and may be implemented across multiple devices, including, for example, clinician server 304 and / or clinician database 306.

[0167] The exemplary procedure 1500 begins in FIG. 15 when the clinician server 304 receives treatment data 402 related to a patient from one or more therapy machines 90 (e.g., medical fluid delivery machines) (block 1502). The clinician server 304 receives the treatment data 402 after a treatment has completed. In other instances, the clinician server 304 receives the treatment data on a periodic basis, such as every 5 seconds, 10 seconds, 30 seconds, 1 minute, 5 minutes, 15 minutes, 1 hour, or 24 hours. In some embodiments, the clinician server 304 may convert the received treatment data 402 from HL7 format to JSON format or a text-based format. The clinician server 304 identifies prescribed therapy parameters or defined thresholds 404 corresponding to the received data (block 1504). For example, the clinician server 304 may access the patient record in the clinician database 306 to determine the prescribed therapy parameters. The clinician server 304 may also access a clinician database 306 to determine any default or clinician-defined thresholds or triggers for generating alerts.

[0168] The example clinician server 304 then determines analysis parameters by comparing or determining differences between at least some of the treatment data 402 and the prescribed therapy parameters and / or defined thresholds 404. This may include determining lost treatment time analysis data 406aa (block 1506), average dwell time analysis data 406ab (block 1508), average fill time analysis data 406bb (block 1510), and average drain time analysis data 406ba (block 1512), as described above in connection with FIGURE 5. The example clinician server 304 also determines alarm analysis data 406c (block 1514) by processing the treatment data 402 and determining the number of alarms generated, the type of alarm, and / or whether the alarm was bypassed, dismissed, resolved, or escalated.

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

[0170] The clinician server 304, in some embodiments, may determine whether a recommendation or guidance should be provided based on, for example, whether an alert was generated or based on the analysis data 406. If a recommendation should be generated, the clinician server 304 determines the appropriate or corresponding recommendation and creates a recommendation document 430 for transmission and display via the application 320 (block 1522). The example procedure 1500 of FIG. 15 may then end. The procedure 1500 may be initiated again when additional treatment data is received. III. Treatment Prediction Embodiments

[0171] In some embodiments, the exemplary 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 discontinue or reduce therapy administered by the therapy machine 90. Figure 16 is a schematic diagram of an application 310 of the clinician server 304, including a prediction processor 310d, according to an exemplary embodiment of the present disclosure.

[0172] The exemplary prediction processor 310d may include one or more AI models, such as a LightGBM model and / or a feedforward neural network model, configured or trained to predict patient discontinuation at least 5-7 days in advance and up to 21-30 days in advance. The prediction processor 310d is trained using a training dataset 1602 comprising treatment data 402 and / or logs for patients over a repeated 6-12 month period. The treatment data 402 is analyzed during this period to identify patients who experienced a gap in treatment of at least 5-14 days. The prediction processor 310d correlates the identified patients with the treatment data 402, patient data 412, and / or any thresholds stored within the records of the clinician database 306. Thus, the prediction processor 310d possesses a dataset identifying patients who discontinued treatment and the treatment and personal characteristics of those patients who discontinued treatment versus those who did not.

[0173] The exemplary prediction processor 310d is configured to determine a model output 1604 by comparing the treatment data 402 and / or patient data 412 to the modeled patient. The model output 1604 includes an average predicted probability of the patient under consideration discontinuing or reducing their treatment of a prescribed regimen or program. The predicted probability is determined by comparing the treatment data 402 (including the patient's historical treatment data 402) and the patient data 412 to training or modeling data and using at least three to five (or more) parameters to determine how closely the patient's data matches or correlates with the training or modeling data set. For example, a patient's treatment data 402 that is nearly identical to the treatment data of other patients who have discontinued treatment is determined by the prediction processor 310d to have a predicted probability of discontinuing treatment of 95% to 100%. However, if the treatment data of the patient under consideration deviates from the data of other patients who discontinued treatment (meaning the data begins to resemble the data of patients who continued treatment), the predicted probability determined by the prediction processor 310d is lower.

[0174] In some embodiments, the training dataset 1602 includes a table of treatment data 402 and / or patient data 412, with each row defining a day of prescribed treatment for a patient. Columns may include treatment data 402 and / or patient data 412 (e.g., input features) related to that patient's days of treatment. The columns may also include an indication (e.g., target variable) regarding whether the patient subsequently discontinued treatment. Additionally, at least some of the training dataset 1602 may be excluded from the modeling process and instead used as holdout or validation data to ensure that the training data adequately trained the predictive model.

[0175] In some embodiments, after training, the predictive model is configured to use recursive feature elimination to remove parameters that do not substantially contribute to determining the concern score. Additionally, or alternatively, the parameters of the predictive model may be optimized using a Bayesian search over the parameter space. Furthermore, the predictive model may be tested for stability before use using treatment and / or patient data from a longer time interval to ensure that one or more predictions made on the training model have not become unstable.

[0176] Using the trained prediction model, the prediction processor 310d may classify the predicted probability as a “concern score” and report the concern score to an associated clinician if it exceeds a certain threshold (e.g., greater than a 50% chance of terminating treatment). In addition to reporting the concern score, the prediction processor 310d may include or identify important parameters or contributing factors that caused the relatively high score, thereby providing transparency regarding the AI ​​or machine learning model or engine. In some embodiments, important parameters may be weighted based on their importance or correlation with the concern score. Additionally, in some embodiments, the prediction processor 310d may determine a first concern score related to the probability that the patient will terminate their prescribed therapy (over at least two weeks) and a second concern score related to the probability that the patient will reduce treatment frequency or duration.

[0177] In some cases, the prediction processor 310d is configured using a supervised learning approach, which compares current and historical treatment / patient data with the patient's actual outcome (e.g., target variable) of continuing or discontinuing treatment. The prediction processor 310d determines that a patient has discontinued treatment by identifying when treatment data has not been uploaded by the machine 90 for a period of at least two weeks beginning at some point during a prediction window (a prediction time frame, such as within two weeks after a date of interest, one week beginning from that date, etc.). In other words, the prediction processor 310d determines that no treatment has been present for at least two weeks, indicating that the patient (in the training set) has discontinued treatment. To determine the target patient's concern score using patients from the training set, the AI ​​or machine learning system of the prediction processor 310d uses parameter inputs to determine a best-fit model to the modeling data. The prediction processor 310d may be configured to use techniques such as cross-validation and testing on a "holdout set" not used for training to avoid overfitting the model.

[0178] In some instances, the prediction processor 310d receives patient / treatment data inputs, provides differences between current and prior values, and uses models that show trends and cumulative counts of values ​​(e.g., alerts) over a time frame (e.g., 28 days). In addition, the prediction 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, the prediction processor 310d may generate a target variable concern score in addition to the trend / cumulative count. The prediction processor 310d provides the patient treatment data inputs (a set of inputs per patient per day) to the prediction model for comparison with the target variable for that patient (e.g., a 1 or 0 to indicate whether the patient discontinued (or did not discontinue) using the therapy machine 90 during the prediction window). The prediction processor 310d may then use one or more machine learning models (such as LGBM, neural networks, and logistic regression) to generate a probability (a decimal number between 0 and 1) that the target variable is "1" (e.g., the patient will discontinue use of the therapy machine 90 beginning sometime during the prediction window).

[0179] In some embodiments, only a small subset of the treatment data for the patient under consideration may be used in the analysis. For example, the prediction processor 310d may exclude recent treatment data 402 for the patient under consideration (e.g., data within the last 5-7 days). Furthermore, the prediction processor 310d may only use treatment data received within the last 5-30 days, preferably 7-21 days, for analysis. Thus, a patient's past long-term compliance cannot bias future predicted treatment compliance; rather, short-term trends, which are more indicative of therapy discontinuation in the near future, are taken into account.

[0180] Key parameters used by one or more patient prediction models and / or engines of prediction processor 310d include: - Emptying time (weighted average, maximum, mean, minimum, variable, and / or cumulative elimination time per treatment), - discharge volume (which may include at least one of initial or cumulative, weighted average, maximum, average, minimum, and / or variation values ​​of discharge values); - Estimated day / night UF removal per treatment (including at least one of the following: weighted average, maximum, mean, minimum, and / or variance of estimated UF removed), -Dwell time (weighted average, maximum, average, minimum, variable, or cumulative drain time per treatment), -Fill time (average or cumulative fill time per treatment), - Expanded messages / alarms / alerts generated by the machine 90 during the treatment (which may include weighted averages, maximum, average, minimum, and / or variance values ​​during the month / week / per treatment alarm, message, or alert); -Cumulative alarms / alerts, -Number of days of experience with therapy machines 90 (including pre-prescribed therapy), - number of days of treatment in the clinic, - the number of days the patient received prescribed therapy, - Number of times prescription therapy has been revised, - the average time between separate treatments (e.g., between daytime and nighttime treatments), - number of cycles on each treatment, - patient age, -Patient gender, - prescription therapy identifier, - total treatment volume (which may include weighted average, maximum, average, minimum, and / or variation of treatment fluid volume); - treatment duration (which may include weighted average, maximum, mean, minimum, and / or variance of treatment duration); - Patient pre- / post-treatment weight (which may include weighted average, maximum, mean, minimum, and / or variation of patient weight); - patient blood pressure (including at least one of weighted average, maximum, mean, minimum, variable diastolic and / or systolic blood pressure); - patient heart rate, and - Patients with renal conditions.

[0181] It should be appreciated that the predictive model may use at least three of the above parameters, and as many as 20-30. If the concern score exceeds a certain threshold, interface 310b is configured to generate document 1606 including the concern score and the top several contributing significant parameters. Interface 310b may also include the patient's values ​​for each significant parameter used in the patient prediction model / engine of prediction processor 310d. In other embodiments, the concern score and top significant parameters may be provided by interface 310b when requested by the clinician via application 320.

[0182] 17 illustrates a concern score user interface 1700, according to an exemplary embodiment of the present disclosure. The user interface 1700 displays the concern score and several top important parameters (in this example, the top five important parameters). The important parameters include values ​​related to the patient. In this example, the patient has a 62% chance of discontinuing treatment in the future (e.g., within the next 1-4 weeks). Indicators that may cause the patient to discontinue treatment include the number of escalating alerts, the cumulative alert count, the average amount of UF cleared, the patient's blood pressure, and a long drain time.

[0183] A clinician reviewing this information has the opportunity to intervene before the patient terminates treatment. The patient may communicate that they are frustrated using the machine (as indicated by the alerts and blood pressure) and that it is taking longer (longer drain time) and is providing reduced benefit (less UF removal). In response, the clinician can contact the patient and determine whether a different glucose level is needed to help clear the UF more quickly. The clinician can also help prevent the patient from turning off alarms and / or alerts. Overall, by allowing the patient to anticipate and act before discontinuing therapy, the clinician has a better chance of keeping the patient on treatment.

[0184] 18 illustrates another embodiment of a concern score user interface 1800, according to an exemplary embodiment of the present disclosure. The user interface 1800 includes a report on patients for whom a clinician is involved. The user interface 1800 includes the patient's name, identifier, and concern score. The user interface 1800 also includes important parameters for each patient. It should be understood that important factors will vary between patients. This patient-specific analysis allows the clinician to narrow down and address specific causes of a patient's risk of discontinuing treatment. The user interface 1800 also includes a list of previous concern scores to show patient trends.

[0185] In some embodiments, the application 310 of the clinician server 304 may include a guideline processor 310c to provide recommendations for addressing critical parameters. The guideline processor 310c is configured to compare the patient's critical parameters with values ​​or ranges of values ​​assigned to different recommendations and / or guidelines provided in a data structure 428 (shown in FIG. 16 ). Recommendations or guidelines may be determined for each critical parameter, i.e., the top identified critical parameters, or provided generally based on the concern score.

[0186] If at least some of the key parameters and / or concern scores correspond to specific recommendations or guidelines, the guideline processor 310c creates a recommendation document 430 that includes the identified recommendations or guidelines. The guideline processor 310c causes the interface 310b to transmit the recommendation document 430 to the application 320 for display. Figure 19 shows the adherence user interface 1700 of Figure 17 with an icon 1902 that allows a user to view the recommendations or guidelines determined by the guideline processor 310c. Selection of the icon 1902 causes the application 320 to display the recommendation user interface 1900.

[0187] In the illustrated example, the guideline processor 310c determines that recommendations exist for a patient with a concern score of 62%. The guideline processor 310c extracts the associated recommendations and guidelines, which are displayed in the user interface 1900. The guidelines include a brief explanation of possible causes for the concern score, as well as actions the clinician can take to help the patient improve their adherence to the prescribed therapy. The user interface 1900 accordingly guides the clinician to improve the patient's adherence to the prescribed therapy based on a predictive analysis of patients receiving similar treatments.

[0188] 20 is a flow diagram of an example procedure 2000 for predicting and reporting whether a patient is likely to discontinue or reduce treatment for a prescribed therapy, according to an example embodiment of the present disclosure. While procedure 2000 is described with reference to the flow diagram illustrated in FIG. 20 , it should be understood that many other ways of implementing the steps associated with procedure 2000 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the described blocks may be optional. In an embodiment, steps of determining recommendations and / or guidelines may be omitted. The actions described in procedure 2000 are defined by one or more instructions and may be implemented across multiple devices, including, for example, clinician server 304 and / or clinician database 306.

[0189] 20, when the clinician server 304 receives training treatment data 1602 for a patient population (block 2002). The clinician server 304 may identify and select patients with similar prescribed therapies or programs, patients prescribed the same type of dialysis therapy (e.g., HD or PD therapy), patients who received therapy from the same type of medical fluid delivery machine, and / or patients who received a prescribed therapy and / or program within the past year. In some cases, the training data includes treatment data for all patients under analysis by the clinician server 304 over the past 6-18 months.

[0190] The exemplary clinician server 304 uses the training treatment data 1602 to create one or more patient prediction models or engines, including, for example, a LightGBM model and / or a neural network model (block 2004). The clinician server 304 then accesses the treatment data 402 and / or patient data 412 for the patient under analysis (block 2006). The clinician server 304 applies the treatment data 402 and / or patient data 412 to the one or more patient prediction models to determine a concern score 1604 (block 2008). As discussed above, the concern score includes the probability that the patient will prematurely terminate (and / or significantly reduce) their prescribed treatment. The clinician server 304 may also determine the top several important parameters or attributes that primarily contributed to the concern score (block 2010). This may include at least one important parameter or as many as ten important parameters.

[0191] The example clinician server 304 may compare the concern score to a threshold (block 2012). If the threshold is exceeded, the clinician server 304 generates an alert, which is transmitted to the application 320 on the clinician device 152 via a document or message 1606 (block 2014). The alert indicates that a clinician-defined or default threshold for the concern score has been exceeded and alerts the clinician that the patient is at risk of terminating or reducing their treatment. The example clinician server 304 also stores the concern score and key parameters 1604 (and / or all parameters that contributed to the calculation of the concern score) in one or more patient records in the clinician database 306 of FIG. 16 (block 2016). The clinician server 304 or web portal 150 may later retrieve the stored data 1604 upon request for rendering and display on the personal mobile communications device 122 or the application 320 on the clinician device 152.

[0192] The clinician server 304, in some embodiments, may determine whether a recommendation or guidance should be provided based on, for example, whether an alert was generated or based on the concern score 1604. If a recommendation should be generated, the clinician server 304 determines the appropriate or corresponding recommendation and creates a recommendation document 430 for transmission and display via the application 320 (block 2018). The example procedure 2000 of FIG. 20 may then end. The procedure 200 may begin again when additional treatment data is received. IV. conclusion

[0193] 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 present subject matter and without diminishing its intended advantages. It is therefore intended that such changes and modifications be covered by the appended claims.

Claims

1. A system for predicting that a target patient will discontinue prescribed treatment administered by an automated peritoneal dialysis ("APD") machine, the system comprising: a memory device for storing treatment data including alarm parameters indicative of alarms generated during treatment, the alarm parameters including a number of alarms generated during treatment; an analysis processor communicatively coupled to the memory device, the analysis processor comprising: receiving the therapy data from the APD machine for a target patient; storing the therapy data received by the interface device in the memory device; comparing the number of alarms generated with an alarm threshold; determining that the target patient is likely to be suffering from alarm fatigue; Displaying an alarm fatigue alarm within a user interface on the clinician device; an analysis processor configured to: A system comprising:

2. The alarm parameter further comprises: The type of each alarm that was generated, The time each alarm was generated, The duration of each alarm generated, and Indication of when the condition that triggered each alarm has been resolved, or whether each alarm has been bypassed, silenced, or escalated The system of claim 1 , comprising:

3. The system described in claim 1 or 2, wherein the analysis processor is configured to store the treatment data in a clinician database within a record associated with the target patient.

4. A system as described in claims 1 to 3, wherein the memory includes values ​​of the alarm parameters in the treatment data that are combined with values ​​of the alarm parameters from previous treatments to determine at least one of a total number of alarms generated per treatment and an average number of alarms for the target patient.

5. The system of claim 4, wherein at least one of the total number of alarms generated per treatment and the average number of alarms generated for the target patient is configured for display within the user interface on the clinician device.

6. The system described in claim 1 or 2, wherein the analysis processor is configured to determine that the target patient is likely to be suffering from alarm fatigue when the number of alarms generated exceeds the alarm threshold.

7. The system described in claim 1 or 2, wherein the user interface is configured to allow a clinician to enter input to silence at least some alarms for subsequent treatment.

8. A method of operating a system for predicting discontinuation of a prescribed treatment by a target patient administered by an automated peritoneal dialysis ("APD") machine, the system comprising: a memory device; and an analysis processor communicatively coupled to the memory device, the method comprising: the memory device storing treatment data relating to a target patient receiving a prescribed therapy or program, the treatment data including alarm parameters indicative of alarms generated during the treatment, the alarm parameters including a number of alarms generated during the treatment; the analysis processor receiving the therapy data from the APD machine for the target patient; storing the treatment data received by the interface device in the memory device by the analysis processor; the analysis processor comparing the number of alarms generated with an alarm threshold; the analysis processor determining that the target patient is likely suffering from alarm fatigue; causing the analysis processor to display a fatigue alarm in a user interface on the clinician device; A method of operation comprising:

9. The alarm parameter further comprises: The type of each alarm that was generated, The time each alarm was generated, The duration of each alarm generated, and Indication of when the condition that triggered each alarm has been resolved, or whether each alarm has been bypassed, silenced, or escalated The method of claim 8, comprising:

10. The operating method further comprises: the analysis processor storing the treatment data in a clinician database within a record associated with the target patient.

10. The method of claim 8 or 9, comprising:

11. An operating method as described in claims 8 to 10, wherein the memory includes values ​​of the alarm parameters in the treatment data that are combined with values ​​of the alarm parameters from previous treatments to determine at least one of a total number of alarms generated per treatment and an average number of alarms for the target patient.

12. The operating method further comprises: and displaying within the user interface on the clinician device the at least one of the total number of alarms generated and the average number of alarms generated per treatment for the target patient. The method of claim 11 , comprising:

13. An operating method as described in claim 8 or 9, wherein determining that the target patient is likely to be suffering from alarm fatigue is determined when the number of alarms generated exceeds the alarm threshold.

14. The method of operation described in claim 8 or 9, wherein the user interface is configured to allow a clinician to enter input to silence at least some of the alarms for subsequent treatment.

15. An analysis processor for predicting that a target patient will discontinue a prescribed treatment administered by an automated peritoneal dialysis ("APD") machine, the analysis processor comprising: receiving treatment data from an APD machine regarding the target patient receiving a prescribed therapy or program, the treatment data including alarm parameters indicative of alarms generated during treatment, the alarm parameters including a number of alarms generated during treatment; storing the treatment data in a memory device; comparing the number of alarms generated with an alarm threshold; determining that the target patient is likely to be suffering from alarm fatigue; Displaying an alarm fatigue alarm within a user interface on the clinician device; an analysis processor configured to:

16. The alarm parameter further comprises: The type of each alarm that was generated, The time each alarm was generated, The duration of each alarm generated, and Indication of when the condition that triggered each alarm has been resolved, or whether each alarm has been bypassed, silenced, or escalated 16. The analysis processor of claim 15, comprising:

17. The analysis processor of claim 15 or 16, wherein the analysis processor is further configured to store the treatment data in a clinician database within a record associated with the target patient.

18. The analysis processor of claim 17, wherein the memory of the memory device includes values ​​of the alarm parameters in the treatment data that are combined with values ​​of the alarm parameters from previous treatments to determine at least one of a total number of alarms generated per treatment and an average number of alarms for the target patient.

19. The analysis processor of claim 18, wherein at least one of the total number of alarms generated per treatment and the average number of alarms generated for the target patient is configured for display within the user interface on the clinician device.

20. The analysis processor of claim 15 or 16, wherein the analysis processor is configured to determine that the target patient is likely to be suffering from alarm fatigue when the number of alarms generated exceeds the alarm threshold.

Images