Medical fluid delivery systems including remote machine updates and control

Abstract

This invention relates to a medical fluid delivery system including remote machine updates and control. A medical fluid delivery system includes: a medical fluid delivery machine configured to generate a message instructing the medical fluid delivery machine to prepare to perform a task; and at least one server that communicates with the medical fluid delivery machine via a first link to receive the message, the at least one server being configured to: (i) relay the message from the medical fluid delivery machine to a remote mobile communication device via a second link, (ii) receive a response from the remote mobile communication device via the second link instructing the start of the task, and (iii) send a notification to the medical fluid delivery machine via the first link to start the task.

Description

[0001] This application is a divisional application, the parent application of which is an invention patent application filed by Baxter International Inc., filed on December 20, 2017, with application number 201780078356.9, entitled "Medical Fluid Delivery System Including Remote Machine Updates and Control".

[0002] Cross-reference to related applications

[0003] This application claims priority to U.S. Patent Application No. 15 / 386,913, filed December 21, 2016, entitled “Medical Fluid Delivery System Including Remote Machine Updating and Control,” the entire contents of which are incorporated herein by reference and are relied upon. Technical Field

[0004] This disclosure generally relates to apparatus, systems, and methods for use in medical fluid delivery machines. More specifically, this disclosure relates to the interaction between a medical fluid delivery machine and a mobile communication device of a patient or caregiver. Background Technology

[0005] One related medical fluid delivery device is a kidney failure treatment device. Regarding kidney failure treatment devices, the human kidney system may fail for various reasons. Kidney failure causes several physiological disorders. It becomes unable to maintain water and mineral balance or excrete the daily metabolic load. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, etc.) can accumulate in the blood and tissues.

[0006] Dialysis has been used to treat kidney failure and impaired kidney function. Dialysis removes waste, toxins, and excess water from the body that normally functioning kidneys would otherwise remove. Dialysis, used to replace kidney function, is crucial for many people because the treatment is life-saving.

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

[0008] Hemofiltration (“HF”) is an alternative renal replacement therapy that relies on the convective transport of toxins from the patient’s blood. HF is achieved by adding a replacement or replacement fluid (typically ten to ninety liters of such fluid) to the extracorporeal circuit during treatment. During HF treatment, the replacement fluid and the fluid accumulated by the patient between treatments are ultrafiltered, providing a convective transport mechanism that is particularly advantageous in removing medium and large molecules (in hemodialysis, a small amount of waste is removed along with the fluid acquired between dialysis sessions; however, the solute resistance from removing this ultrafiltrate is insufficient to provide convective clearance).

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

[0010] Most HD (HF, HDF) treatments occur in centers. There is a growing trend towards home hemodialysis (“HHD”), partly because HHD can be performed daily, offering superior therapeutic benefits compared to in-center hemodialysis, which typically occurs two or three times a week. Studies have shown that more frequent treatments remove more toxins and waste products compared to patients receiving less frequent but potentially longer treatments. Patients receiving more frequent treatments do not experience as much of a decline in circulation as patients in centers, who have accumulated two to three days of toxins before treatment. In some areas, the nearest dialysis center may be many miles from a patient's home, making door-to-door treatment time consume most of the day. HHD can be performed overnight or during the day while the patient relaxes, works, or otherwise produces.

[0011] Another type of treatment for kidney failure is peritoneal dialysis, in which a dialysis solution, also known as dialysate, is infused into the patient's peritoneal cavity via a catheter. The dialysate comes into contact with the peritoneal diaphragm of the peritoneal cavity. Waste, toxins, and excess water flow from the patient's bloodstream, through the peritoneal diaphragm and into the dialysate due to diffusion and osmosis—that is, an osmotic gradient across the diaphragm. The osmotic agent in dialysis provides this osmotic gradient. Used or discarded dialysate is drained from the patient, removing waste, toxins, and excess water. This cycle is repeated, for example, multiple times.

[0012] Various types of peritoneal dialysis therapies exist, 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 line to allow used or discarded dialysate to drain from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysate to infuse fresh dialysate into the patient through the catheter. The patient disconnects the catheter from the fresh dialysate bag and allows the dialysate to remain in the peritoneal cavity, where waste, toxins, and excess water are transported. After the residence period, the patient repeats the manual dialysis procedure, for example, four times a day, with each treatment lasting approximately one hour. Manual peritoneal dialysis requires a significant amount of time and effort from the patient, leaving ample room for improvement.

[0013] Automated peritoneal dialysis (“APD”) is similar to CAPD in its convenience for dialysis treatment, including drainage, filling, and retention cycles. However, APD machines typically perform cycles automatically while the patient is asleep. APD machines free patients from the need for manual treatment cycles and supply transfers during the day. The APD machine is fluidly connected to an implanted catheter, a source or bag of fresh dialysate, and a fluid drain line. The APD machine pumps fresh dialysate from the source, through the catheter, and into the patient's peritoneal cavity. The APD machine also allows dialysate to remain in the cavity and allows for the removal of waste, toxins, and excess water. The source may include multiple sterile dialysate bags.

[0014] The APD machine pumps used or discarded dialysate from the peritoneal cavity, through a catheter, and into a drain line. Similar to the manual procedure, several cycles of draining, filling, and retention occur during dialysis. The “final fill” occurs at the end of APD and remains in the patient's peritoneal cavity until the next treatment.

[0015] Any of the above-described forms performed by a machine can be run on a scheduled basis and may require initiation of a procedure. For example, dialysis patients typically receive treatment on a scheduled basis, such as every other day, daily, etc. Blood treatment machines typically require a certain amount of time for setup before treatment, for example, to run a sterilization procedure. Patients in the above-described forms may lead busy lives and have scheduled appointments or errands to run on days scheduled for treatment. A solution that claims to be helpful to patients is disclosed in U.S. Patent No. 8,315,654 (“654 Patent”), entitled “Extracorporeal Blood Treatment Device and Method For Preparing Blood Treatment Using An Extracorporeal Blood Treatment Device”. ’654 Patent discloses a method in which the patient sends an initiation code from an external communication unit to the blood treatment device to initiate a routine at the blood treatment device. (See the abstract of the ’654 Patent specification). However, as discussed in more detail below, the method of ’654 Patent does not take into account certain important factors related to the machine and to the treatment itself.

[0016] Therefore, there is a need for an improved way to enable patients to interact remotely with medical fluid delivery machines. Summary of the Invention

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

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

[0019] The medical fluid delivery machines and medical fluid data transmission systems and methodologies described herein can be used with home-based machines. For example, the systems can be used with home-based HD, HF, or HDF machines that are operated at the convenience of a patient. One such home-based system is described in U.S. Patent No. 8,029,454 (“'454 Patent”), filed November 4, 2004, entitled “High Convection Home Hemodialysis / Hemofiltration and Sorbent System,” which has been assigned to the assignee of this application. Other such home-based systems are described in U.S. Patent No. 8,393,690 (“'690 Patent”), filed August 27, 2008, entitled “Enclosure for a Portable Hemodialysis System,” issued March 12, 2013. The entire contents of each of the foregoing references are incorporated herein by reference and are relied upon.

[0020] Most of the appeal of home-based therapy for patients revolves around the lifestyle flexibility offered by allowing the patient to perform treatment primarily according to his or her own schedule at home. The home medical fluid delivery machine, however, may include a software timer that is assigned to and constrains the user or patient. Home-based hemodialysis systems may, for example, require the patient to be extremely close to the home-based hemodialysis machine to initiate pre-treatment, during-treatment, and post-treatment sequences.

[0021] In one specific example, the home therapy machine can be reused by sterilizing certain components between treatments. The machine may employ one or more sterilization timers that require the patient or caregiver to use the machine to begin treatment before the sterilization timer expires. Otherwise, the patient would have to wait until another sterilization procedure is completed before starting treatment. In an embodiment, the home therapy machine communicates the treatment start time deadline via the machine's graphical user interface, requiring the patient to be near the machine to access the start time deadline and respond accordingly.

[0022] It should be understood that this disclosure applies to any type of sterilization, such as hot water sterilization and chemical sterilization. In this regard, this disclosure is not limited to home therapy machines, for example, central machines are typically chemically sterilized and treatment start dates can be set after such sterilization. Furthermore, this disclosure is not limited to start dates based on sterilization, but can also be applied to, for example, other start dates based on the completion of priming. Even further, this disclosure is not limited to initial start dates. For example, most machines will allow the patient to temporarily stop treatment and disconnect from the machine to perform some type of necessary action away from the machine. For blood therapy, the machine will typically flush the blood back to the patient and may or may not allow the dialysate to circulate for a period of time. In any case, the time during which the patient can temporarily disconnect from the machine is not unlimited, and this disclosure is also contemplated to apply to return time limits.

[0023] In one embodiment, the system of this disclosure provides a software application (“app”) installed on the personal mobile communication device (e.g., a smartphone) of the patient and / or caregiver. In one embodiment, the app is provided via a middleware software application, examples of which are discussed in detail below. In an alternative embodiment, the software is configured to communicate directly with the personal mobile communication device of the patient and / or caregiver, such as a smartphone, using text messaging features via the middleware software application. In any case, the app or text message in one embodiment is configured to remind the patient of any upcoming deadlines and allow the patient and / or caregiver to track when treatment needs to begin without tying the patient to a machine.

[0024] It is conceivable that communication software could be alternatively or otherwise constructed to automatically program reminders on a user's mobile communication device, for example, on a device's native task tracking feature, such as a calendar application. Most smartphones are provided with a calendar that divides each day into time periods, such as hours. The software of the systems and methodologies disclosed herein can be programmed to access the smartphone calendar of authorized patients and / or caregivers and, for example, the machine will populate the appropriate time period(s) of the appropriate day with appropriate information, such as the start or completion of disinfection within that time period.

[0025] In one embodiment, communication from the software systems and methodologies of this disclosure is unidirectional. For example, communication could be from a medical fluid delivery machine (which may be a home machine) in the home to a patient's or caregiver's mobile communication device. In an alternative embodiment, the software systems and methodologies of this disclosure enable bidirectional communication between the medical fluid delivery machine and the patient's or caregiver's mobile communication device. In one example, bidirectional communication could allow the patient or caregiver to remotely initiate certain machine routines using their mobile communication device. One example routine is an automated self-test routine, which can be executed without any user interaction with the system, rather than a startup or start sequence. For example, remotely starting a sequence can benefit the patient or caregiver by providing additional time away from the machine performing other tasks. Communication becomes bidirectional when the machine initiates communication by instructing the machine to prepare to execute a self-test routine. The patient or caregiver responds back to the machine via the software systems and methodologies of this disclosure at the desired time to initiate the sequence.

[0026] The software of the systems and methodologies disclosed herein is envisioned to disable communication between patients and / or caregivers and the machine whenever the machine is in a "patient-connected" software state. For example, if a clinician attempts to send a command to the machine currently treating a patient, the command might be intercepted by a middleware application, preventing it from being delivered to the machine. The middleware application can then communicate back to the clinician, informing them that the machine is busy and not accepting communication.

[0027] As described in detail below, the medical fluid data transmission system and methodology of this disclosure can operate within a larger platform system that includes: numerous machines of many different types, patients, clinicians, physicians, service personnel, electronic medical record (“EMR”) databases, websites, resource planning systems that process data generated via patient and clinician communications, and business intelligence. The medical fluid data transmission system and methodology of this disclosure operate seamlessly throughout the entire system and without violating its rules and protocols.

[0028] This document also discloses a system specifically configured for a hospital or clinical setting that allows a single physician, nurse, or clinician to monitor and potentially control multiple medical fluid delivery machines. The hospital or clinical system allows for the viewing of multiple machines and may allow for the control of multiple machines via a single mobile communication device.

[0029] In view of the disclosure herein and without limiting the disclosure in any way, in the first aspect of this disclosure, unless otherwise specified, the first aspect of this disclosure may be combined with any other aspect listed herein. A medical fluid delivery system includes: a first medical fluid delivery machine configured to generate a first message for remote transmission to a first patient or caregiver, the first message indicating (i) that the first medical fluid delivery machine is ready to perform a task or (ii) a pre-programmed time for the first medical fluid delivery machine to perform the same or different tasks; and a second medical fluid delivery machine configured to generate a second message for remote transmission to a second patient or caregiver, the second message indicating (i) that the second medical fluid delivery machine is ready to perform the same or different tasks or (ii) a pre-programmed time for the second medical fluid delivery machine to perform the same or different tasks.

[0030] In the second aspect of this disclosure, unless otherwise specified, the second aspect of this disclosure may be combined with any other aspect listed herein, wherein the first medical fluid delivery machine and the second medical fluid delivery machine communicate data with at least one server, a first message and a second message are transmitted to the server, and the server is configured to (i) relay the first message to a first mobile communication device for a first patient or caregiver and (ii) relay the second message to a second mobile communication device for a second patient or caregiver.

[0031] In this third aspect of disclosure, unless otherwise specified, this third aspect of disclosure may be combined with the second aspect in conjunction with any other aspects listed herein, and at least one server includes at least one dedicated server or cloud server.

[0032] In the fourth aspect of this disclosure, unless otherwise specified, the fourth aspect of this disclosure may be combined with the second aspect in conjunction with any other aspects listed herein, and relaying at least one of the first or second messages includes using a cellular network that networks at least one server and at least one of the first or second mobile communication devices.

[0033] In the fifth aspect of this disclosure, unless otherwise specified, the fifth aspect of this disclosure may be combined with the fourth aspect in conjunction with any other aspect listed herein, wherein communication over a cellular network is via Short Message Service (“SMS”) or Multimedia Messaging Service (“MMS”) protocols.

[0034] In the sixth aspect of this disclosure, unless otherwise specified, the sixth aspect of this disclosure may be combined with the second aspect in conjunction with any other aspect listed herein, wherein the first medical fluid delivery machine and the second medical fluid delivery machine are home machines that communicate data with at least one server via an Internet connection.

[0035] In the seventh aspect of this disclosure, unless otherwise specified, the seventh aspect of this disclosure may be combined with the second aspect in conjunction with any other aspect listed herein, wherein the first medical fluid delivery machine and the second medical fluid delivery machine are central machines, wherein at least one server is maintained at the center.

[0036] In the eighth aspect of this disclosure, unless otherwise specified, the eighth aspect of this disclosure may be combined with the second aspect in conjunction with any other aspect listed herein, including the relay of at least one of the first or second messages via at least one server, including updating software applications downloaded to at least one of the first or second mobile communication devices.

[0037] In the ninth aspect of this disclosure, unless otherwise specified, the ninth aspect of this disclosure may be combined with the eighth aspect in conjunction with any other aspect listed herein, wherein at least one software application is downloaded from the system.

[0038] In the tenth aspect of this disclosure, unless otherwise specified, the tenth aspect of this disclosure may be combined with the second aspect in conjunction with any other aspect listed herein, including updating a calendar installed on at least one of the first or second messages via at least one server.

[0039] In the eleventh aspect of this disclosure, unless otherwise specified, the eleventh aspect of this disclosure may be combined with any other aspect listed herein, including the same or different tasks, including the initiator task.

[0040] In the twelfth aspect of this disclosure, unless otherwise specified, the twelfth aspect of this disclosure may be combined with any other aspect listed herein, with the same or different tasks including disinfection procedures or self-testing routines.

[0041] In the thirteenth aspect of this disclosure, unless otherwise specified, the thirteenth aspect of this disclosure may be combined with any other aspect listed herein, wherein the pre-programmed time for at least one of the first medical fluid delivery machine or the second medical fluid delivery machine is (i) a set duration from when the first message or the second message is generated or (ii) the time programmed for the start of the same or different tasks.

[0042] In the fourteenth aspect of this disclosure, unless otherwise specified, the fourteenth aspect of this disclosure may be combined with any other aspect listed herein, a medical fluid delivery system comprising: a medical fluid delivery machine configured to generate messages indicating (i) that the medical fluid delivery machine is ready to perform a task or (ii) a pre-programmed time for the medical fluid delivery machine to perform the same or different tasks; and at least one server communicating data with the medical fluid delivery machine to receive messages, the at least one server including middleware software for relaying messages from the medical fluid delivery machine to a remote mobile communication device.

[0043] In the fifteenth aspect of this disclosure, unless otherwise specified, the fifteenth aspect of this disclosure may be combined with the fourteenth aspect in conjunction with any other aspect listed herein, wherein middleware software updates are downloaded to software applications on mobile communication devices to relay messages.

[0044] In the sixteenth aspect of this disclosure, unless otherwise specified, the sixteenth aspect of this disclosure may be combined with the fourteenth aspect in conjunction with any other aspect listed herein, wherein middleware software updates the calendar installed on the mobile communication device to relay messages.

[0045] In the seventeenth aspect of this disclosure, unless otherwise specified, the seventeenth aspect of this disclosure may be combined with the fourteenth aspect in conjunction with any other aspect listed herein, wherein the middleware software uses a cellular communication network that networks at least one server and at least one of a first mobile communication device or a second mobile communication device to relay messages.

[0046] In the eighteenth aspect of this disclosure, unless otherwise specified, the eighteenth aspect of this disclosure may be combined with the fourteenth aspect in conjunction with any other aspect listed herein, and at least one server includes at least one dedicated server or cloud server.

[0047] In the nineteenth aspect of this disclosure, unless otherwise specified, the nineteenth aspect of this disclosure may be combined with any other aspect listed herein, a medical fluid delivery system comprising: a medical fluid delivery machine configured to generate a message instructing the medical fluid delivery machine to prepare to perform a task; and at least one server that communicates data with the medical fluid delivery machine via a first link to receive the message, the at least one server being configured to (i) relay the message from the medical fluid delivery machine to a remote mobile communication device via a second link, (ii) receive a response from the remote mobile communication device via the second link instructing the start of a task, and (iii) send a notification of the start of a task to the medical fluid delivery machine via the first link.

[0048] In the twentieth aspect of this disclosure, unless otherwise specified, the twentieth aspect of this disclosure may be combined with the nineteenth aspect in conjunction with any other aspect listed herein, wherein the first link is an Internet link.

[0049] In aspect twenty-one of this disclosure, unless otherwise specified, aspect twenty-one may be combined with aspect nineteen in conjunction with any other aspect listed herein, wherein the second link is an Internet link or a cellular communication network link.

[0050] In the twenty-second aspect of this disclosure, unless otherwise specified, the twenty-second aspect of this disclosure may be combined with the nineteenth aspect in conjunction with any other aspect listed herein, and at least one server includes at least one dedicated server or cloud server.

[0051] In the twenty-third aspect of this disclosure, unless otherwise specified, the twenty-third aspect of this disclosure may be combined with any other aspect listed herein, a mobile communication device comprising: a first link to a first medical fluid delivery machine, the first link enabling the mobile communication device to receive from the first medical fluid delivery machine a first message indicating (i) that the first medical fluid delivery machine is ready to perform the same or different task or (ii) a pre-programmed time for the first medical fluid delivery machine to perform the task; and a second link to a second medical fluid delivery machine, the second link enabling the mobile communication device to receive from the second medical fluid delivery machine a second message indicating (i) that the second medical fluid delivery machine is ready to perform the same or different task or (ii) a pre-programmed time for the second medical fluid delivery machine to perform the same or different task.

[0052] In the twenty-fourth aspect of this disclosure, unless otherwise specified, the twenty-fourth aspect of this disclosure may be combined with the twenty-third aspect in conjunction with any other aspect listed herein, wherein the first link and the second link respectively include a first icon and a second icon on the screen of the mobile communication device, the first icon and the second icon being associated with the first medical fluid delivery machine and the second medical fluid delivery machine, respectively.

[0053] In the twenty-fifth aspect of this disclosure, unless otherwise specified, the twenty-fifth aspect of this disclosure may be combined with the twenty-fourth aspect in conjunction with any other aspect listed herein, and the first icon and the second icon are associated with the first message and the second message, respectively.

[0054] In the twenty-sixth aspect of this disclosure, unless otherwise specified, the twenty-sixth aspect of this disclosure may be combined with the twenty-fourth aspect in conjunction with any other aspect listed herein, and at least one of the first icon or the second icon is user-selectable to view the first message or the second message respectively.

[0055] In the twenty-seventh aspect of this disclosure, unless otherwise specified, the twenty-seventh aspect of this disclosure may be combined with the twenty-fourth aspect in conjunction with any other aspect listed herein, depending on how the first medical fluid delivery machine and the second medical fluid delivery machine are arranged in the facility on the mobile communication device, the first icon and the second icon are arranged.

[0056] In the twenty-eighth aspect of this disclosure, unless otherwise specified, the twenty-eighth aspect of this disclosure may be combined with the twenty-fourth aspect in conjunction with any other aspect listed herein, wherein the mobile communication device includes at least one action icon that is selectable by a user to cause at least one of the first medical fluid delivery machine or the second medical fluid delivery machine to perform the same or different tasks.

[0057] In the twenty-ninth aspect of this disclosure, unless otherwise specified, the twenty-ninth aspect of this disclosure may be combined with the twenty-eighth aspect in conjunction with any other aspect listed herein, wherein at least one action icon is operated in conjunction with the first icon or the second icon to select at least one of the first medical fluid delivery machine or the second medical fluid delivery machine to perform the same or different tasks.

[0058] In the thirtieth aspect of this disclosure, unless otherwise specified, the thirtieth aspect of this disclosure may be combined with any other aspect listed herein, a medical fluid delivery system comprising: a first medical fluid delivery device; a second medical fluid delivery device; a server communicating with the first and second medical fluid delivery devices; a software application for a mobile communication device, the software application causing a first icon to be displayed to represent the first medical fluid delivery device and a second icon to be displayed to represent the second medical fluid delivery device; a first communication link between the first and second medical fluid delivery devices and the server; and a second communication link between the server and the software application, the software application being programmed to receive at least one status update from the first or second medical fluid delivery device via the server and the first and second links.

[0059] In the thirty-first aspect of this disclosure, unless otherwise specified, the thirty-first aspect may be combined with the thirtieth aspect in conjunction with any other aspect listed herein, wherein the first communication link and the second communication link are Internet links.

[0060] In the thirty-second aspect of this disclosure, unless otherwise specified, the thirty-second aspect of this disclosure may be combined with the thirty-third aspect in conjunction with any other aspect listed herein, and the software application is also programmed to send operating commands to the first medical fluid delivery machine and the second medical fluid delivery machine via the server and the first and second links.

[0061] In the thirty-third aspect of this disclosure, regarding Figures 1 to 9 Any structure and functionality disclosed may be related to... Figures 1 to 9 Any other structural and functional combinations disclosed.

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

[0063] Another advantage of this disclosure is that it provides for improved patient lifestyles.

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

[0065] Another advantage of this disclosure is that it provides improved machine efficiency.

[0066] Another advantage of this disclosure is that it provides improved patient compliance.

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

[0068] Another advantage of this disclosure is that it provides a medical fluid data transmission system and methodology that enables communication between a medical fluid delivery machine and multiple individuals, such as patients and clinicians or patients and primary caregivers.

[0069] In addition, one advantage of this disclosure is that it reduces waste of disposable kits and other auxiliary soft goods due to discards, which often occur when machine timers expire.

[0070] The advantages discussed herein may be found in one or more, and possibly not all, of the embodiments disclosed herein. Additional features and advantages are described herein and will be apparent from the following detailed description and figures. Attached Figure Description

[0071] Figure 1 This is a schematic diagram illustrating one embodiment of a medical fluid data transmission system incorporated into the medical fluid delivery machine of this disclosure, enabling data to be transmitted to and from such a machine.

[0072] Figure 2 This is a schematic diagram of one embodiment of the medical fluid delivery machine disclosed herein.

[0073] Figure 3 The diagram is used to... Figure 2 A perspective view of a blood set used in an embodiment of a medical fluid delivery machine.

[0074] Figure 4 This is a schematic diagram of one embodiment of the medical fluid delivery machine and data transmission system and method used in this disclosure.

[0075] Figure 5 This is a schematic diagram of a second embodiment of the medical fluid delivery machine and data transmission system and method used in this disclosure.

[0076] Figure 6 This is a schematic diagram of a third embodiment of the medical fluid delivery machine and data transmission system and method disclosed herein.

[0077] Figure 7 This is a schematic diagram of an embodiment of a hospital or clinical version of the medical fluid delivery device, data transmission system and method of this disclosure, which has a mobile communication device application in a first state.

[0078] Figure 8 This is a schematic diagram of an embodiment of a hospital or clinical version of the medical fluid delivery device, data transmission system and method of this disclosure, which has a mobile communication device application in a second state.

[0079] Figure 9 This is a schematic diagram of an embodiment of a hospital or clinical version of the medical fluid delivery device, data transmission system, and method of this disclosure, which incorporates mobile communication devices in a third state. Detailed Implementation

[0080] The examples described herein apply to any medical fluid delivery system that delivers medical fluids such as blood, dialysate, replacement fluid, or intravenous medications (“IV”). These examples 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”), collectively or generally individually referred to herein as renal failure therapies. The medical fluid delivery machine may alternatively be a medication delivery or nutrient solution delivery device, such as a large-volume peristaltic pump or infusion pump. The machines described herein can be used in home settings. For example, a machine operating in accordance with the data transmission method of this disclosure can be used with a home HD machine, which may operate, for example, at night while the patient is sleeping. The medical fluid data transmission systems and methodologies of this disclosure may alternatively be used to assist clinicians or nurses in hospitals and / or clinics.

[0081] Now refer to the accompanying drawings and especially to... Figure 1The medical fluid data transmission system 10 is illustrated as operating within a medical fluid delivery machine 90. The system 10 incorporates a plurality of medical fluid delivery machines 90 (one type of which is discussed in detail below). The machines 90 of the data transmission system 10 may be of the same type (e.g., all HD machines) or of different types (e.g., a mixture of HD, PD, CRRT, and medical or nutrient fluid delivery).

[0082] Although a single medical fluid delivery device 90 is illustrated as communicating with a connection server 118, system 10 oversees the operation of multiple medical fluid delivery systems and machines of the same or different types 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 medication delivery machines 90, and R nutrition or medication delivery machines 90 connected to server 118 and operating with system 10. The quantities M to R can be the same or different, and can be zero, one, or more than one. Figure 1 In the illustration, the medical fluid delivery machine 90 is shown as a home therapy machine 90 (home is indicated by a dashed line).

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

[0084] Connection server 118 communicates with medical fluid delivery machine 90 via medical device system hub 120. System hub 120 enables data and information about each home therapy machine 90 and its peripherals to travel back and forth between machine 90 and other clients connected to server 118 via connection server 118. In the illustrated embodiment, system hub 120 is connected to service portal 130, enterprise resource planning system 140, web portal 150, business intelligence portal 160, HIPAA-compatible database 124, product development team 128, and electronic medical record databases maintained, for example, at clinics or hospitals 126a to 126n.

[0085] Electronic medical record (“EMR”) databases at clinics or hospitals 126a to 126n store electronic information about patients. System hub 120 can send data collected from the log files of machine 90 to the hospital or clinic databases 126a to 126n to merge or supplement the patient’s medical record. The databases at clinics or hospitals 126a to 126n can contain patient-specific treatment and prescription data, thus access to such databases can be highly restricted. Enterprise resource planning system 140 acquires and compiles data generated via patient and clinician website access, such as complaints, billing information, and lifecycle management information. Web portal 150 enables patients and clinics 152a to 152n that treat these patients to access a website publicly available to users of medical fluid delivery machine 90. Business intelligence portal 160 collects data from system hub 120 and provides the data to marketing 162, research and development 164, and quality / pharmacovigilance 166.

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

[0087] In one embodiment, the home therapy machine 90 performs home treatments such as home hemodialysis on the patient at their home and then reports the results of the treatment to the clinician, doctor, and nurse responsible for managing the patient's health and condition.

[0088] In one embodiment, the home therapy machine 90 uses, for example, Linux. TMThe operating system writes to a log file. The log file records relevant data from the home therapy machine 90, including peripheral device data. The log file may include any one or more of Extensible Markup Language (“XML”), comma-separated values ​​(“CSV”), or text files. The log file is placed in a file server box of the home therapy machine 90's software. It is also envisioned that data be stored, for example, at a peripheral device of the water treatment device 60, which is not sent to the machine 90. Such data may otherwise be obtained via a wired or wireless connection to the peripheral device, or downloaded via other data connections or storage media. For example, a service provider may access additional data via a laptop connected to the water treatment device 60 or the wireless scale 106, for example via an Ethernet connection. Alternatively, additional data may be retrieved remotely from a peripheral device, where the home therapy machine 90 serves as a data transfer link between the peripheral device and an authorized client of the medical fluid data transmission system.

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

[0090] Connection agent 114 allows home therapy machine 90 to connect to connection server 118 and transmit data to and from connection server 118. The connection service, operating via agent 114 and server 118, ensures that the connection to machine 90 is secure, ensures that data passes correctly through machine 90's firewall, checks for data corruption or system crashes, and ensures that connection server 118 is communicating with the correct home therapy machine 90.

[0091] In one embodiment, the home therapy machine 90 may connect to the connection server 118 only when the connection agent 114 is connected or activated. During treatment and post-treatment sterilization, while the machine 90 and its peripherals are running, in one embodiment, the connection agent 114 is shut down. This prevents the home therapy machine 90 from communicating with any entity and sending or receiving data during treatment and sterilization, or while the machine 90 is running. When the home therapy machine 90 is idle, for example, after treatment and post-treatment sterilization are complete, in one embodiment, the ACPU 50 connects the connection agent 114. In another embodiment, the connection agent 114 is shut down during treatment and possible pre-treatment. After treatment, the connection agent 114 retrieves log files from the home therapy machine 90 and uses the connection service to transmit data to the connection server 118. The connection service routes data packets to their appropriate destinations, but in one embodiment, the data is not modified, accessed, or encrypted.

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

[0093] Now for reference Figure 2 The illustration shows an example of an HD process diagram for a medical fluid delivery machine 90. Because... Figure 2 HD systems are relatively complex, so Figure 2 The discussion also provides support for any of the renal failure treatment modalities discussed above, as well as for IV, drug delivery, or nutrient solution delivery machines. Typically, the medical fluid delivery machine 90 is shown as a simplified version with a dialysate or process fluid delivery circuit. The blood circuit is also simplified, but not to the extent that the dialysate circuit is simplified. It should be understood that the circuit has been simplified to facilitate the description of this disclosure, and the system, when implemented, will have additional structural and functionalities, such as those found in the disclosure incorporated above by reference.

[0094] Figure 2The medical fluid delivery device 90 includes a blood circuit 20. The blood circuit 20 draws blood from a patient 12 and returns blood to the 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 connected 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 connected to a venous needle 16b, which is in blood return communication with the patient. The arterial line 14 and the venous line 16 also include line clamps 18a and 18v, which may be spring-loaded, fail-safe mechanical clamps. In one embodiment, line clamps 18a and 18v automatically close in an emergency.

[0095] Arterial line 14 and venous line 16 also include air or bubble detectors 22a and 22v, respectively, which may be ultrasound air detectors. Air or bubble detectors 22a and 22v detect air in arterial line 14 and venous line 16, respectively. If air is detected by one of the air detectors 22a and 22v, system 10 closes line clamps 18a and 18v, pauses the blood and dialysate pumps, and issues a command to the patient to purge the air, allowing treatment to resume.

[0096] In the illustrated embodiment, blood pump 30 is located in arterial line 14. In the illustrated embodiment, blood pump 30 includes a first blood pump pod 30a and a second blood pump pod 30b. Blood pump pod 30a operates with inlet valve 32i and outlet valve 32o. Blood pump pod 30b operates with inlet valve 34i and outlet valve 34o. In this embodiment, blood pump pods 30a and 30b are each blood receivers comprising a rigid housing, such as a spherical one, having a flexible diaphragm located within the housing, forming a diaphragm pump. One side of each diaphragm receives blood, while the other side of each diaphragm operates via negative and positive pressure. Blood pump 30 may alternatively be a peristaltic pump operating with arterial line 14 or multiple peristaltic pumps operating with arterial line 14 and venous line 16.

[0097] In the illustrated embodiment, heparin bottle 24 and heparin pump 26 are located between blood pump 30 and blood filter 40 (e.g., dialyzer). Heparin pump 26 can be a pneumatic pump or an injection pump (e.g., a stepper motor driven injection pump). Supplying heparin upstream of blood filter 40 helps prevent clogging of the filter diaphragm.

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

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

[0100] exist Figure 2 The dialysate circuit 70 is again highly simplified for ease of illustration. The dialysate circuit 70 can actually include all the relevant structures and functionalities set forth in the disclosure incorporated above by reference. Certain features of the dialysate circuit 70 are illustrated in... Figure 2 In the illustrated embodiment, the dialysate circuit 70 includes a dialysate pump 64 leading to a blood filter. In one embodiment, pump 64 is configured identically to blood pump 30. Like pump 30, pump 64 includes a pair of pump pods 66, each having an inlet valve 68i and an outlet valve 68o, which may again be ball-shaped. Similar to blood pump 30, the two pump pods are operated alternately, such that one pod is filled with HD dialysate while the other pod is draining HD dialysate.

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

[0102] A fifth pod pump (not shown) in the discharge line 82 is provided for removing a known amount of ultrafiltration (“UF”) during HD therapy. System 10 tracks the UF pump to control and know how much ultrafiltration has been removed from the patient. System 10 ensures that the necessary amount of ultrafiltration is removed from the patient at the end of treatment.

[0103] Each of the pumps described above may alternatively be a peristaltic pump operating in conjunction with a pumping line. If so, the system valves can still be pneumatically actuated according to the features of this disclosure.

[0104] In one embodiment, purified water from the water purification unit 60 is pumped along the mixing line 62 via a bicarbonate cartridge 72. Acid from container 74 is pumped along the mixing line 62 into the bicarbonated water flowing from the bicarbonate cartridge 72 to form an electrolytically and physiologically compatible dialysate solution. The pumps used to properly mix the purified water with the bicarbonate and acid, and the temperature-compensated conductivity sensor, are not illustrated but are disclosed in detail in the above disclosure incorporated by reference.

[0105] Figure 2 The illustration also shows the dialysate being pumped along the fresh dialysate line 76 via a heater 78 and an ultrafilter 80 before reaching the blood filter 40. Used dialysate is then pumped to the discharge line via a discharge line 82. The heater 78 heats the dialysate to body temperature or approximately 37°C. The ultrafilter 80 further cleans and purifies the dialysate before it reaches the blood filter 40 to filter out foreign matter and / or contaminants introduced from the dialysate, for example, via a bicarbonate cartridge 72 or an acid container 74.

[0106] In the illustrated embodiment, the dialysate circuit 70 also includes a sample port 84. The dialysate circuit 70 will further include a blood leak detector (not shown but for detecting whether the fibers of the blood filter 40 are torn) and other components not shown, such as a balance chamber, multiple dialysate valves, and a dialysate holding tank, all of which are illustrated and described in detail in the disclosure incorporated above by reference.

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

[0108] In alternative embodiments, such as for CRRT, multiple bags of sterile dialysate or infusion fluid are combined and used one after another. In this case, the emptied supply bags can be used as discharge or waste bags.

[0109] Medical fluid delivery machines 90 include, for example, via Figure 2 The accessories indicated by the dotted lines. The accessories for machine 90 vary depending on the type of treatment, whether the treatment is at a center or at home, and whether the dialysis fluid / infusion material is in batches (e.g., bagged) or on-line.

[0110] Figure 3 The diagram shows Figure 2 The machine 90 can operate in conjunction with the infusion set 100. The infusion set 100 includes an arterial line 14, a venous line 16, a heparin bottle 24, a heparin pump 26 / blood pump 30, and a blood filter 40 (e.g., a dialyzer). An air trap 28 can be located in the venous line 16 to remove air from the blood before it is returned to the patient 12. Air detectors 22a and 22v contact the arterial line 14 and the venous line 16, respectively, for operation.

[0111] exist Figure 2 and Figure 3 In this embodiment, pumps 26, 30 (30a and 30b), 64, 96 (and other pumps not shown) and valves such as valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98o can be pneumatically actuated. In this embodiment, each of these pumps and valves has a fluid side and an air side separated by a flexible diaphragm. A negative pneumatic pressure can be applied to the air side of the diaphragm to draw fluid into the pump chamber or to open the valve (or the pump or valve can be opened by venting a positive closing pressure to the atmosphere and allowing the fluid pressure to open). A positive pneumatic pressure is applied to the air side of the diaphragm to discharge fluid from the pump chamber or to close the valve.

[0112] Now for reference Figure 4The illustration shows system 110a of this disclosure. System 110a in the illustrated embodiment operates together with system 10 described above and includes a connection server 118, a system hub 120, a service portal 130, an enterprise resource planning system 140, a web portal 150, and a business intelligence portal 160, which... Figure 4 The diagram shows a cloud environment. Connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150, and business intelligence portal 160 may each be part of the cloud environment or located on one or more dedicated servers.

[0113] Figure 4 Other components of system 10 (not shown) may also be part of system 110a. For example, medical fluid delivery machines 90a and 90b may reside in the homes of patients 12a and 12b (shown as not at home), respectively. Alternatively, medical fluid delivery machines 90a and 90b may reside in the same clinic among 126a to 126n or in different clinics among 126a to 126n. Clinicians 112a and 112b may reside inside or outside the clinic.

[0114] As described above, medical fluid delivery machines 90a and 90b are connected to connection server 118 via secure hosted connection 116. To do this, machines 90a and 90b are connected to the Internet 52, for example, via modem 102 discussed above. In one embodiment, system hub 120 stores middleware software that can be accessed by mobile communication devices 200a and 200b (collectively referred to herein as device 200 or generally referred to individually as device 200). Mobile communication devices 200a and 200b may be, for example, based on Android... TM iOS TM Windows Phone TM BlackBerry TM Sailfish OS TM Tizen TM or Ubuntu Touch TM A smartphone running on an operating system. Mobile communication devices 200a and 200b may belong to patients 12a and 12b, and / or to clinicians 112a and 112b, respectively. Figure 4 The mobile communication devices 200a and 200b shown in the diagram are also connected to the Internet 52.

[0115] In one embodiment, mobile communication devices 200a and 200b download application software (“app”) from middleware software stored on system hub 120 via their connection to the Internet 52. The app is updated whenever the state of the corresponding machine 90a or 90b changes. For example, medical fluid delivery machine 90a may have just completed its automated self-test routine and is now ready to run a sterilization procedure. Machine 90a can generate a code recognizing this state and send that code to the middleware software stored on system hub 120. The middleware software then uses, for example, a lookup table to translate the code into a message such as “Self-test complete, preparing for sterilization,” and causes the app downloaded to the mobile communication device 200a of patient 12a or clinician 112a to display that message. The app can be programmed to provide, along with the message, a visual identifier such as an icon associated with the specific state in which machine 90a resides. The app can also provide any one or more of the following: an audio alarm such as a "ding" sound and / or a tactile alarm such as a vibration, prompting the patient 12a or clinician 112a to check the app and see the status changes of the machine 90.

[0116] In another example, the medical fluid delivery machine 90b may be pre-programmed to begin treatment at 3:00 PM. The machine may require three hours for self-checking and sterilization. Patient 12a or clinician 112a therefore needs to arrive at machine 90b before noon to begin pre-treatment. In an embodiment, patient 12a or clinician 112a sets a notification or alarm on machine 90b about how long before the three-hour preparation time, for example, two hours. So in this example, machine 90b could generate a code at 10:00 AM and send it to middleware software stored on system hub 120. The middleware software then uses, for example, a lookup table to translate the code into a message such as "treatment preparation needs to begin within two hours," and causes an app downloaded to patient 12b or clinician 112b's mobile communication device 200b to display the message. This app can again be programmed to provide a visual identifier along with the message, such as a countdown timer from 120 minutes to zero timeout. The app can also provide any one or more audio alerts such as a "ding" sound and / or tactile alerts such as vibrations, prompting the patient 12b or clinician 112b to check the app and see the treatment preparation notification. The app can also be programmed to repeat the "ding" sound and / or tactile feedback at pre-programmed intervals of one hour and thirty minutes during countdown periods, for example.

[0117] As a supplement or alternative to providing an app on the user's communication device 200b, it is envisioned that middleware software at the system hub 120 translates code from machine 90b into messages that are presented to native task tracking features of device 200, such as its calendar application. For example, most smartphone devices 200 are provided with a calendar that divides each day into time periods such as hours. Here, the messages translated by the middleware software of the system hub 120 can be programmed to access the calendar of the authorized communication device 200b and fill the appropriate time period of the appropriate day with appropriate information. In the example above, for the appropriate day, the native calendar software application would have its 10:00 AM time slot filled with a message such as "Treatment preparation needs to begin within two hours". Audio and / or haptic feedback signals can be provided to notify the patient 12 or clinician 112 of calendar entries.

[0118] It should be understood that the middleware software at machines 90a and 90b, the central server 120, and the communication devices 200a and 200b can be programmed and operated as described above to provide patients 12a and 12b and / or clinicians 112a and 112b with any desired messages, not limited to those described herein. For example, an accompanying countdown timer can be used to similarly notify patients 12a and 12b and / or clinicians 112a and 112b that treatment needs to begin within the countdown time to avoid the need for re-sterilization of machines 90a and 90b.

[0119] Now for reference Figure 5 The illustration shows system 110b of this disclosure. System 110b in the illustrated embodiment operates together with system 10 described above, and includes a connection server 118, a system hub 120, a service portal 130, an enterprise resource planning system 140, a web portal 150, and a business intelligence portal 160, which... Figure 5 The image is shown as part of a cloud environment, but may alternatively be located on one or more dedicated servers. Figure 5 Other components of system 10 (not shown) may also be part of system 110a. A single medical fluid delivery device 90 is illustrated for ease of description; however, multiple medical fluid delivery devices 90 may be similarly connected to system 110b. The medical fluid delivery device 90 may reside in the home of patient 12 (illustrated as not at home) or in the clinic 126a to 126n of clinician 112. In the illustrated embodiment, the medical fluid delivery device 90 uses, for example, modem 102 to reconnect to connection server 118 via secure hosting connection 116 and Internet connection 52.

[0120] In one embodiment, system hub 120 stores middleware software that can be accessed by mobile communication device 200 (shown as a single device for convenience, but multiple devices 200 can be connected to system 110b in the same way). Figure 5 Mobile communication devices 200 in the middle include those for Figure 4 All structures, functionalities, and alternatives disclosed in the devices 200a and 200b illustrated in the diagram, including those connected to the Internet 52. Figure 5 In this context, mobile communication device 200 can, but is not required to, download software applications (“apps”) from middleware software stored on system hub 120 via its connection to the Internet 52. This can be precisely as described above regarding... Figure 4 The app operates as described, including middleware software converting encoded messages from machine 90 into a format that the app can display. Alternatively or additionally, middleware software stored on system hub 120 may be able to... Figure 4 Any method described herein that converts code from machine 90 into a message that is presented on native task tracking features of mobile communication device 200, such as its calendar application.

[0121] Further alternatively or additionally, system 110b includes, for example, a cellular network 210 that interfaces between middleware software stored at system hub 120 and mobile communication device 200. Cellular network 210 may include a network of cellular telephone towers operating using radio waves and / or employ satellites. Communication protocols suitable for use with cellular network 210 of system 110b may be long-range protocols such as (i) the Global Microwave Access Interoperability (“WiMAX”) protocol; and (ii) the Global System for Mobile Communications (“GSM”) protocol, which is a widespread long-range wireless protocol enabling data communication with cellular phones throughout many parts of the world. Network 210 may alternatively or additionally employ a mid-range protocol, such as a wireless local area network (“WLAN”), which may be a protocol as part of the Institute of Electrical and Electronics Engineers (“IEEE”) 802.11 standard, such as (i) IEEE 802.11a, (ii) IEEE 802.11b, (iii) WEE 802.11g, or (iv) 802.11n. Other suitable cellular technologies may include CDMA, AMPS (analog), General Packet Radio Service (“GPRS”), cdmaOne, CDMA2000, Evolved Data Optimized (“EV-DO”), Enhanced Data Rate GSM Evolution (“EDGE”), Universal Mobile Telecommunications System (“UMTS”), Digital Enhanced Cordless Communication (“DECT”), Digital AMPS (“IS-136 / TDMA”), and Integrated Digital Enhanced Network (“iDEN”).

[0122] Mobile communication device 200 communicates with cellular network 210, for example, via Short Message Service (“SMS”) or Multimedia Messaging Service (“MMS”) protocols, in any manner known to a technician. Middleware software at system hub 120 can communicate with cellular network 210 in many ways. In one example, the phone numbers and carriers of users 12, 112 (any or all of Patient 12, the patient at the home care partner’s facility, or the patient’s clinician 112) are associated with specific machine 90, for example, via a lookup table at the middleware software. When a message / code from specific machine 90 is received by the middleware, the middleware software can be programmed to send an email to [user phone number]@[carrier].net. For example, if patient 001’s phone number is (555)555-5555 and patient 001’s carrier is AT&T. TM When patient 001's machine 90 sends a message to the middleware software of system hub 120, upon receiving it, the middleware software 120 is programmed to relay the email to 5555555555@att.net, which is then received as a text message by patient 001's mobile communication device 200. Those skilled in the art will understand that multiple websites exist dedicated to informing users how to send emails to text messages and outlining the details required by different carriers.

[0123] The middleware software stores each of the phone numbers for each of the mobile communication devices 200 and matches each of those numbers with machine 90. When an event code is sent from machine 90 to the middleware software as described above, the middleware software locates the phone number of the mobile communication device 200 associated with that machine, for example, by using a lookup table as described above to convert the code into an appropriate message, and sends the converted message to the callback phone number. It is envisioned that multiple communication devices 200 may be associated with the same medical fluid delivery machine 90. For example, in any of clinics 126a to 126n, multiple doctor, nurse, and / or clinician phone numbers may be associated with the same machine 90. In a home setting, the phone numbers for patient 12 and his or her clinician and / or nursing assistant may be associated with the same machine 90.

[0124] Similarly, the telephone number used for the mobile communication device 200 can be associated with multiple medical fluid delivery machines 90. For example, in any of clinics 126a to 126n, a single nurse can monitor multiple machines 90. If an event occurs in any of those machines during the nurse's shift, the nurse can be notified via a cellular message sent to the mobile communication device 200. (See below for further details.) Figures 7 to 9 Describe this scene in detail.

[0125] Cellular messaging can convey information about any of the same events discussed above for the software app, as well as populate the calendar update pattern of mobile communication device 200 with information. For example, medical fluid delivery machine 90 may have just completed its automated self-test routine and is now ready to run a sterilization procedure. Machine 90 can generate a code that identifies this state and send that code to middleware software stored on system hub 120. The middleware software then uses, for example, a lookup table to translate the code into a message such as “Self-test complete, preparing for sterilization,” and causes, for example, the cellular output routine discussed above to send a text message to the mobile communication device 200 of patient 12 or clinician 112 to display that message. In an alternative embodiment, no code is required and machine 90 instead sends an actual text string, which the middleware software forwards as a text message to mobile communication device 200 via, for example, the cellular output routine discussed above. It is well known that receiving a text message on communication device 200 can be accompanied by, for example, an audio “ding” sound and / or a tactile alarm such as vibration, prompting patient 12 or clinician 112 to view the information.

[0126] In another example, the medical fluid delivery machine 90 may be pre-programmed to begin treatment at 3:00 PM. The medical fluid delivery machine 90 may again require three hours for self-checking and sterilization. The patient 12 or clinician 112 therefore needs to arrive at the machine 90 before noon to begin pre-treatment. In an embodiment, the patient 12 or clinician 112 makes a setting on the machine 90 regarding how long before the three-hour preparation time, for example, two hours, the patient 12 or clinician 112 should be notified or alerted. Here, the machine 90 generates a code at 10:00 AM and sends that code to middleware software stored on the system hub 120. The middleware software then uses, for example, a lookup table to translate the code into a message such as "treatment preparation needs to begin within two hours," and causes, for example, the cellular output routine discussed above to send a text message to the patient 12 or clinician 112's mobile communication device 200 to display the message, for example, along with an audio alarm such as a "ding" sound and / or a haptic alarm such as a vibration, prompting the patient 12 or clinician 112 to check the notification.

[0127] It should be understood that the middleware software and communication devices 200 at machine 90 and central server 120 can be programmed and operated as described above to alternatively or additionally use cellular network 210 to provide any desired messages to patient 12 and / or clinician 112. For example, patient 12 and / or clinician 112 can be notified at the end of sterilization that treatment needs to begin within a countdown time to avoid the need for re-sterilization of machine 90. It should also be understood that this can be done via internet connection or via... Figure 5The cellular network 210 shown in the diagram completes the updating of native task tracking features for calendar applications such as communication device 200.

[0128] Now for reference Figure 6 The illustration shows system 110c of this disclosure. System 110c in the illustrated embodiment operates together with system 10 described above, and includes a connection server 118, a system hub 120, a service portal 130, an enterprise resource planning system 140, a web portal 150, and a business intelligence portal 160, which... Figure 6 The image is shown as part of a cloud environment, but may alternatively be located on one or more dedicated servers. Figure 6 Other components of system 10 (not shown) may also be part of system 110a. For ease of description, a single medical fluid delivery device 90 is illustrated; however, multiple medical fluid delivery devices 90 can be similarly connected to system 110b. The medical fluid delivery device 90 may reside in the home of patient 12 (illustrated as not at home) or in the clinic 126a to 126n of clinician 112. In the illustrated embodiment, the medical fluid delivery device 90 uses, for example, modem 102 to reconnect to connection server 118 via secure hosting connection 116 and Internet connection 52. Figure 6 In this context, connection server 118 and secure managed connection 116 are used for bidirectional communication.

[0129] In one embodiment, system hub 120 stores middleware software that can be accessed by mobile communication device 200 (for convenience, it is shown as a single device, but multiple devices 200 can be connected to system 110b in the same way). Figure 6 Mobile communication devices 200 in the middle include those for Figure 4 All structures, functionalities, and alternatives disclosed in the devices 200a and 200b illustrated in the diagram, including those connected to the Internet 52. Figure 6 In this context, mobile communication device 200 can, but is not required to, download software applications (“apps”) from middleware software stored on system hub 120 via its connection to the Internet 52. This can be precisely as described above regarding... Figure 4 The app operates as described, including middleware software converting encoded messages from machine 90 into a format that the app can display. Alternatively or additionally, middleware software stored on system hub 120 may be able to... Figure 4 Any method described herein may be used to convert the code from machine 90 into a message that is presented to the native task tracking feature of mobile communication device 200, such as its calendar application. Alternatively, this may be done via the methods described above. Figure 5 The cellular network 210 discussed (in) Figure 6The calendar application is updated as an alternative (illustrated by dashed lines).

[0130] Figure 6 The illustration shows that communication between the medical fluid delivery machine 90 and the mobile communication device 210 can be bidirectional. Communication between the mobile communication device 210 and the middleware software at the server computer 120 can be via the Internet 52 and / or the cellular network 210. As described in detail above, communication between the middleware software at the server computer 120 can be via a secure hosted connection 116, via a connection server 118.

[0131] As discussed above, the home therapy machine 90 is connected to the connection server 118 via its onboard connection agent 114. In one embodiment, the connection agent 114 is shut down during treatment, such as while the machine 90 and its peripherals are running (the connection agent 114 may or may not be shut down during post-treatment sterilization). This prevents the home therapy machine 90 from communicating with any entity and sending or receiving data during treatment and sterilization, or while the machine 90 is running. Communication via systems 110a to 110c is contemplated to be protected in the same manner. For example, suppose a particular machine 90 is configured to communicate with both the patient 12 and the clinician 112 via middleware software. Here, if a patient is being treated by the machine 90, it is contemplated that the connection agent 114 is shut down so that the clinician 112 cannot then receive notifications from or send commands to the machine 90. In an alternative embodiment, the clinician 112 may be able to receive notifications from the machine 90 during treatment.

[0132] Determining when to disconnect agent 114 (no communication) can depend on what or how much machine status systems 110a to 110c expect to transmit to mobile communication device 200. For example, suppose that only two hours before treatment preparation is expected, the patient 12 or clinician 112 needs to return to machine 90 to begin treatment preparation. Here, the patient 12 or clinician 112 could initially, for example, run the first treatment preparation step of a self-test routine, and then disconnect agent 114.

[0133] In another example, it might be desirable for machine 90 to automatically run a self-check routine at a preset time before treatment is set to begin. Machine 90 notifies patient 12 or clinician 112 when to begin sterilization. Here, once patient 12 or clinician 112 begins machine sterilization, the connection agent 114 can be disconnected. In another example, it might be desirable for machine 90 to notify patient 12 when sterilization is complete, so that the patient can begin treatment within a certain time after sterilization ends, eliminating the need for repeated sterilization. Here, once patient 12 or clinician 112 begins treatment, for example, initially before the patient is connected to, for example, a treatment line connected to arterial line 14 or venous line 16, the connection agent 114 can be disconnected.

[0134] System 110c allows patient 12 or clinician 112 to remotely initiate any of the aforementioned actions (and other actions not explicitly described herein). Patient 12 or clinician 112 may, for example, select an icon displayed on an app on mobile communication device 200 to initiate, for example, a self-test routine or disinfection procedure. The selection of the icon is sent to middleware software via the Internet 52. The middleware software may then, for example, translate the icon selection into action code, via a lookup table, which is sent to machine 90 connected via connection server 118 and secure managed connection 116, to allow the action code for the selected action to be sent to ACPU 50 of the machine initiating the execution of the selected action.

[0135] In an alternative embodiment, patient 12 or clinician 112 may, for example, type a known code in a text message to select a specific action to be performed at machine 90, such as a self-test routine or disinfection procedure. The code may be a suggested code such as "self-test" or "disinfect". The text message is sent via cellular network 210 to middleware software at system hub 120. The middleware software converts the text code into an action code for the selected action, for example, via a lookup table. Alternatively, the code typed by patient 12 or clinician 112 may be an action code, eliminating the need for conversion. In either case, the action code is sent via connection server 118 and secure managed connection 116 to machine 90, where its connection agent 114 is connected, to allow the action code for the selected action to be sent to ACPU 50 of the machine initiating the execution of the selected action.

[0136] Figure 6The following example illustrates a seven-step sequence. In step 1, the medical fluid delivery machine 90 sends a message to the middleware software application at the system hub 120, instructing the machine to prepare for the patient 12 to initiate, for example, a two-hour automated self-test routine. In step 2, the middleware software application at the system hub 120 sends a corresponding message, for example a translated message, to the patient's mobile communication device 200, instructing the machine 90 to prepare for the patient 12 to initiate the automated self-test routine.

[0137] In step 3, a customized app downloaded to the patient's mobile communication device 200 alerts the patient 12 via audio, visual, and / or tactile alarms and related messages that the patient's machine 90 is ready for the patient to initiate, for example, a two-hour automated self-test routine. In step 4, the patient 12 uses the customized app on the mobile communication device 200 to confirm that the machine 90 should begin its automated self-test routine.

[0138] In step 5, the patient's mobile communication device 200 sends a message to the middleware software application at the system hub 120, acknowledging that the patient's machine 90 is expected to begin its automated self-test routine. In step 6, the middleware software application at the system hub 120 sends (e.g., converts and sends) a message to the machine 90 indicating that the patient 12 has acknowledged that the machine 90 will begin its automated self-test routine. In step 7, the machine 90 begins and executes its automated self-test routine.

[0139] Once the self-check is performed, except that the action is now a disinfection procedure instead of an automated self-check routine, system 110c is assumed to perform the same steps 1 to 7 discussed above. Here, a custom app downloaded to the patient's mobile communication device 200 can display a countdown timer to the patient 12 to remind them how much time they must have left before returning to machine 90 to begin treatment. It should be understood that different types of medical fluid delivery machines may have different one, two, three, or more actions that the patient 12 or clinician 112 can perform before treatment begins.

[0140] Regarding systems 110a to 110c, it is envisioned that the app on the mobile communication device 200 is programmed to be configurable by the user to select which type of notification the user wants to receive on their device 200, for example, via the app itself, via text messages, and / or via calendar notifications. In one embodiment, the system hub 120 may send all notification types, where the mobile communication device 200 ignores communication types that the user has disabled. In another embodiment, the system hub 120 stores the user's preferences and sends information only according to the selected notification type.

[0141] Now for reference Figures 7 to 9An embodiment of a system 110d having a clinician-based downloadable software application (“app”) 230 with a mobile communication device 200 for a doctor, clinician, or nurse is illustrated on frames 232-236. As discussed above, the mobile communication device 200 may be a patient’s mobile communication device 200 or a doctor / nurse / clinician’s mobile communication device 200. Figures 7 to 9 Screenshots 232 to 236 illustrate the use of app 230 in clinics or hospitals 126a to 126n, where a nurse, for example, is in charge of multiple machines 90a to 90n. Machines 90a to 90n may again be hemodialysis machines, peritoneal dialysis machines, CRRT machines, drug and / or nutrient delivery machines, and combinations thereof.

[0142] Screen 232 illustrates that app 230 can monitor and, if necessary, control multiple machines 90. In the illustrated embodiment, machines 90a to 90n are each represented by dedicated icons 190a to 190n displayed on screen 232 of app 230. In the illustrated embodiment, icons 190a to 190n are arranged on screens 232 to 236 in the same manner as machines 90a to 90n are arranged in clinics 126a to 126c to aid in locating the doctor / nurse / clinician 112.

[0143] It is envisioned that app 230 operates in conjunction with system hub 120 as discussed herein, wherein system hub 120 is located remotely from clinics or hospitals 126a to 126n and is maintained, for example, by the manufacturer of one or more of machines 90a to 90n. For example, it could initially be in Figure 1 The diagram shows product development at point 128 and app development at point 230. Then it can be accessed via... Figure 1 and Figure 7 The service entry point 130, as illustrated, sends app 230 from product development 128 to system hub 120. Any nurse, clinician, or physician 112 authorized to download app 230 can do so from system hub 120. Thereafter, system hub 120 maintains middleware software to operate with app 230 in the manner described above in systems 110a to 110c.

[0144] In an alternative embodiment, clinics 126a to 126n can maintain their own local area networks (LANs), each operating in conjunction with the local system hub 220. App 230 can again be accessed via product development 128 (…). Figure 1The app 230 is developed and delivered via service entry 130 to the local system hub 220 of clinics 126a to 126n that operate with the overall system 10. Each nurse, clinician, or physician 112 authorized to download app 230 does so from the local system hub 220. The local system hub 220 then maintains middleware software to operate with the app in the manner described above for system hub 120 in systems 110a to 110c. In a further alternative embodiment, app 230 may be developed by clinics 126a to 126n and stored on their local system hub 220.

[0145] The middleware software of system hub 120 or local system hub 220 updates the status of each machine 90a to 90n. Nurses, clinicians, or doctors 112 can select icons 190a to 190n at any time to view the current status of each machine 90a to 90n, for example, as... Figure 8 The screen 234 illustrates "Stationary," "Self-Check," "Disinfect," or "Patient Treatment." Other status markers are envisioned and may differ for different types of machines. The nurse, clinician, or doctor 112 can then select any of "Stationary," "Self-Check," "Disinfect," or "Patient Treatment" to return to, as shown in the image. Figure 9 The homepage icons 190a to 190n are shown in the figure.

[0146] As discussed above, it is envisioned that the connection agent 114 of each machine 90 be shut down while the machines are running, and especially when patient 12 is connected to the machines. However, it is also envisioned that the connection agent 114 of each machine 90a to 90n in clinics 126a to 126n remain connected until sterilization is complete, so that middleware software at system hub 120 or local system hub 220 can receive changes in status to "treating patient" from each machine 90a to 90n. Furthermore, because each machine 90a to 90n knows its planned treatment duration, the machine can also send the planned duration to the middleware software, which then sends the duration along with the "treating patient" status change in the form of a countdown timer. Here, when nurses, clinicians, or doctors 112 are... Figure 8 When selecting "Treat Patients", they can see a countdown timer displayed as follows: Figure 9 The remaining treatment time is shown in the diagram.

[0147] For a countdown timer, connection agent 114 is designed to allow machines 90a to 90n to send remaining time data to system hub 120, enabling app 230 to display the actual remaining time for each machine 90 as it goes through the timing process. App 230 considers potential warnings or other delays that machines 90 may experience. During warning situations, the corresponding icons 190a to 190f can display messages such as "Warning" or "Safe Mode." The nurse, clinician, or doctor 112 can then select... Figure 9 The countdown time in the middle is used to return to Figure 7 The homepage icons shown in the image are 190c, 190d, and 190h.

[0148] The nurse, clinician, or physician 112 can also toggle the alarm on / off icon 238 to allow or disallow visual, auditory, and / or tactile alarms for changes in the status of machines 90a to 90n. If the alarm on / off icon 238 is toggled to "on," the app 230 of the mobile communication device 200 will provide visual, auditory, and / or tactile alarms whenever the machine's status changes, for example, (i) self-test start, (ii) self-test complete, (iii) disinfection start, (iv) disinfection complete, (v) treatment start, (vi) treatment complete. In an embodiment, the code for (i) to (v) is sent via machines 90a to 90n through a secure hosted connection 116, a connection server 118, and a system hub 120 or a local system hub 220 to be translated and forwarded by middleware software to the app 230, which updates the appropriate icon 190. In various embodiments, “(vi) treatment complete” may be (a) sent via machines 90a to 90n with an activated connection agent 114 or (b) deduced when the countdown timer of the appropriate icons 190a to 190n expires, wherein the connection agent 114 may still be off.

[0149] If the alarm on / off icon 238 is switched to off, for example, if the nurse, clinician, or doctor 112 does not want to be interrupted at a given time, icons 190a to 190n will still be updated as described above, but no audible and / or tactile alarms will be provided. However, by selecting the associated icons 190a to 190n, the nurse, clinician, or doctor 112 can still actively view the status of each machine 90a to 90n.

[0150] Figures 232 to 236 illustrate action buttons 240a and 240b (collectively referred to herein as action button 240 or generally referred to individually as action button 240). Any number of action buttons 240 may be provided for any type of pre-treatment action required for any form of hemodialysis, peritoneal dialysis, CRRT, drug and / or nutrient solution delivery, for example. In the illustrated embodiment, action button 240a is used to initiate a self-test of machine 90, while action button 240b is used to initiate a sterilization sequence of machine 90.

[0151] In one embodiment, when the self-test button 240a is selected, any machine 90a to 90n capable of performing a self-test will have its corresponding icon 190a to 190n highlighted. A nurse, clinician, or doctor 112 selects any one or more icons 190 for the machine(s) 90(s) for which the nurse, clinician, or doctor 112 wishes to perform a self-test. That selected icon(s) 190(s) can then become a "Confirm" button, which the nurse, clinician, or doctor 112 must press again to have the selected machine(s) 90(s) perform its self-test. The app 230 of the mobile communication device 200 then sends the corresponding self-test code to middleware software at system hub 120 or local system hub 220, which, if necessary, translates the self-test code into a self-test initiation command. This self-test initiation command is sent via connection server 118 through secure managed connection 116 to connection agent 114 of the selected machine 90, which then transmits the command to the machine's ACPU 50, which in turn initiates the self-test.

[0152] In the illustrated embodiment, when the disinfection button 240b is selected, any machine 90a to 90n capable of performing disinfection will have its corresponding icon 190a to 190n highlighted. A nurse, clinician, or doctor 112 selects any one or more icons 190 for the machine(s) 90(s) they wish to disinfect. That selected icon(s) 190 can then become a "Confirm" button, which the nurse, clinician, or doctor 112 must press again to have the selected machine(s) 90(s) perform its disinfection. The app 230 of the mobile communication device 200 then sends the corresponding disinfection code to middleware software at system hub 120 or local system hub 220. If the middleware software needs to convert the disinfection code into a disinfection initiation command, the disinfection initiation command is sent via connection server 118 through secure managed connection 116 to connection agent 114 of the selected machine 90. Connection agent 114 then transmits the command to the machine's ACPU 50, which in turn initiates disinfection.

[0153] The program just described for action button 240 can also be implemented in system 110c and for other machine commands, which may vary depending on the type of machine 90. It is also envisioned that clinic 126a can determine that it is sufficiently safe for one or more nurses, clinicians, or doctors 112 present at the clinic to activate the connection agent 114 during or part of treatment. In this case, the nurse, clinician, or doctor 112 can control the activities of machine 90 during treatment. For example, the nurse, clinician, or doctor 112 can receive and respond to warnings / alarms via app 230 at mobile connection device 200, start and stop pumps and other treatment aspects, start and stop sterilization, start and stop pretreatment, etc.

[0154] Each of systems 110a through 110d operates according to some form of addressing. As discussed above, in one embodiment, a connection server 118 is provided to ensure that data is delivered in the appropriate form to the appropriate machine 90, and that data from machine 90 is delivered in the appropriate form to the appropriate destination. In one embodiment, when machine 90 sends data to system hub 120 or local system hub 220 for delivery to mobile communication device 200, the data is provided with a machine identifier that identifies the machine 90 from which the data was sent. Connection server 118 knows each mobile communication device 200 to which the data of a particular machine belongs and tells system hub 120 or local system hub 220 which communication devices 200 will receive the data. System hub 120 or local system hub 220 can then transform the data as discussed herein. When sending, for example, transformed data, system hub 120 or local system hub 220 can strip the machine identifier from the data because the machine identifier is no longer needed. However, in system 110d, the machine identifier can be transmitted along with, for example, the converted data, so that app 230 knows which icons 190a to 190n to populate with the new data. Here, once the machine identifier is no longer needed, app 230 can remove the machine identifier.

[0155] In one embodiment, when mobile communication device 200 sends data to system hub 120 or local system hub 220 for delivery to machine 90, the data is provided with a mobile communication device 200 identifier, which identifies the mobile communication device 200 from which the data was sent. System hub 120 or local system hub 220 may or may not translate the data from mobile communication device 200 as discussed above, but in either case, the mobile communication device 200 identifier is maintained for connection server 118. Connection server 118 knows which machine 90 will receive, for example, translated data from each mobile communication device 200, and sends, for example, the translated data to each associated communication device 200. Once the data has been delivered to machine 90, connection server 118 can remove the mobile communication device 200 identifier from the data, as it is no longer needed.

[0156] As described above, app 230 allows nurses, clinicians, or doctors 112 to set up, monitor, and potentially control treatment at the medical fluid delivery machine 90. It is envisioned that treatment can be administered to the patient 12 or at the patient's home via the app. Figure 1 The dashed box in the image provides similar functionality for caregivers of patient 12. Connections can be made with... Figures 7 to 9 The same as shown. However, the setting is not clinics 126a to 126n, but instead a home or other non-clinical location such as a business or vacation location. Furthermore, typically only a single machine 90 exists, rather than multiple machines 90a to 90n. However, it is possible that a single patient 12 can be treated via multiple machines 90, each supported by an app as described herein. If the patient 12 is at home but away from the machine 90, the app can provide valuable information such as the amount of time remaining to start or complete a startup procedure, disinfection procedure, or self-check routine. While a patient is being treated via machine 90, he / she can see information about its user interface 122, which itself can be as follows: Figure 1 The illustrated tablet. However, caregivers such as spouses, friends, or home nurses can also assist patient 12 at home during treatment. Caregivers benefit from the home application by receiving status updates, remaining time for initiation procedures, remaining time for disinfection, remaining time for pretreatment, remaining time for treatment, information on whether patient 12 is connected to machine 90, alarms, warnings, etc. In one embodiment, the app requires a login name and password associated with the patient to be entered before the app can be downloaded to the caregiver's mobile communication device 200, so that only authorized personnel can view the patient's treatment data.

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

Claims

1. A medical fluid delivery device, comprising: Blood circuitry, which includes a blood filter and a blood pump; A dialysate circuit, which is fluidly coupled to the blood filter and includes at least one dialysate pump; processor; as well as The memory stores instructions that, when executed by the processor, cause the processor to: Receive disinfection input to begin the disinfection procedure. Using a disinfectant, the blood pump and the at least one dialysate pump perform a disinfection procedure on the blood circuit and the dialysate circuit. After the disinfection procedure is completed, start the disinfection timer. When a dialysis input is received before the disinfection timer reaches zero, dialysis treatment can be performed. When the disinfection timer reaches zero before the dialysis input is received, the dialysis treatment is prevented until the disinfection procedure is repeated.

2. The medical fluid delivery device according to claim 1, wherein, The disinfection input is received in the processor via a network from a mobile communication device.

3. The medical fluid delivery device according to claim 2, wherein, After the processor transmits the following message to the mobile communication device via the network, it receives the disinfection input, the message indicating: (i) Prepare to carry out the aforementioned disinfection procedure, or (ii) The time required to perform the disinfection procedure.

4. The medical fluid delivery device according to claim 2, wherein, The processor is further configured to transmit at least one of the following to the mobile communication device: Indicates information about the disinfection timer; or It indicates that the disinfection procedure has been completed.

5. The medical fluid delivery device according to claim 2, further comprising: A connection agent, communicatively coupled to the processor, is configured to prevent the processor from communicating with the mobile communication device during the disinfection process.

6. The medical fluid delivery device according to claim 1, wherein, The blood circuit additionally includes venous tubing, arterial tubing, at least one tubing clamp, and a bubble detector, and The dialysate circuit is fluidly coupled to a source of fresh dialysate and additionally includes an ultrafilter, a heater, and an outlet line.

7. The medical fluid delivery device according to claim 6, wherein, The blood circuit additionally includes at least two blood pumps.

8. The medical fluid delivery device according to claim 1, wherein, At least one of the blood filter and the dialysate circuit is disposable.

9. The medical fluid delivery device according to claim 8, wherein, The blood circuit is configured to be used for one month prior to replacement, and the dialysate circuit is configured to be used for six months.

10. The medical fluid delivery device according to claim 1, wherein, in, The disinfectant is hot water or a chemical solution.

11. The medical fluid delivery device of claim 1, further comprising a graphical user interface communicatively coupled to the processor. in, The processor is configured such that information indicating the disinfection timer is displayed on the graphical user interface.

12. A medical fluid delivery device, comprising: A dialysate circuit, which includes at least one dialysate pump; processor; as well as The memory stores instructions that, when executed by the processor, cause the processor to: Receive disinfection input to begin the disinfection procedure. Using a disinfectant, the at least one dialysate pump performs a disinfection procedure on the dialysate circuit. After the disinfection procedure is completed, start the disinfection timer. When a dialysis input is received before the disinfection timer reaches zero, dialysis treatment can be performed. When the disinfection timer reaches zero before the dialysis input is received, the dialysis treatment is prevented until the disinfection procedure is repeated.

13. The medical fluid delivery device according to claim 12, wherein, The processor is further configured to: Before receiving the disinfection input, (i) determine whether the disinfection procedure is ready to be performed, or (ii) determine the time for performing the disinfection procedure; as well as The information indicating (i) or (ii) will be transmitted to the mobile communication device.

14. The medical fluid delivery device according to claim 13, wherein, The processor is communicatively coupled to the server via a network, and The processor will instruct the information in (i) or (ii) to be transmitted to the mobile communication device via the server and the network, and will receive the disinfection input via the server and the network.

15. The medical fluid delivery device according to claim 13, wherein, The processor is configured to transmit at least one of the following to the mobile communication device: Indicates information about the disinfection timer; or It indicates that the disinfection procedure has been completed.

16. The medical fluid delivery device according to claim 13, further comprising: A connection agent, communicatively coupled to the processor, is configured to prevent the processor from communicating with the mobile communication device during the disinfection process.

17. The medical fluid delivery device according to claim 13, wherein, The processor is communicatively coupled to the mobile communication device via at least one of a cellular network or an Internet link.

18. The medical fluid delivery device according to claim 17, wherein, The disinfection input is received via Short Message Service ("SMS") or Multimedia Messaging Service ("MMS") protocols.

19. The medical fluid delivery device of claim 12, further comprising a graphical user interface communicatively coupled to the processor. in, The processor is configured such that information indicating the disinfection timer is displayed on the graphical user interface.

20. The medical fluid delivery device according to claim 19, wherein, The processor is further configured such that the graphical user interface displays information indicating that the disinfection procedure needs to be repeated when the disinfection timer reaches zero before the dialysis input is received.

Images