Medical fluid delivery systems including remote machine update and control

Abstract

To provide an improved form for enabling a patient to interact remotely with a medical fluid delivery machine.SOLUTION: A medical fluid delivery system comprises: a medical fluid delivery machine configured to generate a message indicating that the medical fluid delivery machine is ready to perform a task; and at least one server in data communication with the medical fluid delivery machine via a first link to receive the message. The at least one server is configured to (i) relay the message from the medical fluid delivery machine to a remote mobile communication device via a second link, (ii) receive from the remote mobile communication device a response indicating the need to start the task via the second link, and (iii) transmit to the medical fluid delivery machine a notification for starting the task via the first link.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] (Citation of related applications) This application claims priority to U.S. Patent Application No. 15 / 386,913 (filed December 21, 2016, titled "Medical Fluid Delivery System Including Remote Machine Updating and Control"), the entire contents of which are incorporated herein by reference and reliance upon.

[0002] This disclosure generally relates to devices, systems, and methods for medical fluid delivery machines. More specifically, this disclosure relates to the interaction between a medical fluid delivery machine and a patient's or caregiver's mobile communication device. [Background technology]

[0003] One relevant medical fluid delivery machine is a renal failure treatment machine. Regarding renal failure treatment machines, the human renal system can cease to function due to various causes. Renal failure results in several physiological disturbances. Maintaining fluid and mineral balance, or excreting daily metabolic loads, becomes impossible. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, and others) can accumulate in the blood and tissues.

[0004] Kidney failure and impaired kidney function are treated with dialysis. Dialysis removes waste products, toxins, and excess fluid from the body that a normally functioning kidney would otherwise remove. Dialysis treatment for kidney function replacement is important for many people because the treatment is life-saving.

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

[0006] Hemofiltration ("HF") is an alternative renal replacement therapy that relies on the convective transport of toxins from a patient's blood. HF is performed by adding a replacement fluid or replacement fluid (typically 10–90 liters of such fluid) to an extracorporeal circuit during the procedure. The replacement fluid and the fluid accumulated by the patient between procedures are ultrafiltered over a series of HF procedures, providing a convective transport mechanism that is particularly beneficial in removing medium and large molecules (in hemodialysis, a small amount of waste is removed along with the fluid obtained between dialysis sessions, however, solute extraction from the removal of its ultrafiltrate is not sufficient to provide convective clearance).

[0007] Hemodiafiltration ("HDF") is a treatment modality that combines convective and diffusion clearance. HDF uses a dialysate that flows through a dialyzer, similar to standard hemodialysis, to provide diffusion clearance. In addition, an alternative fluid is supplied directly to the extracorporeal circuit to provide convective clearance.

[0008] Most HD (HF, HDF) treatments are performed at a center. The trend toward home hemodialysis ("HHD") exists today, partly because HHD can be performed daily and offers superior therapeutic benefits compared to center-based hemodialysis treatments, which are typically performed two or three times a week. Studies have shown that more frequent treatments remove more toxins and waste products than patients receiving less frequent but possibly longer treatments. Patients receiving more frequent treatments do not experience as many downcycles as center-based patients who have accumulated two or three days' worth of toxins prior to their treatment. In some areas, the nearest dialysis center is miles from the patient's home, resulting in door-to-door treatment time taking up a significant portion of the day. HHD can be performed overnight or during the day while the patient is relaxing, working, or otherwise productive.

[0009] Another type of kidney failure treatment is peritoneal dialysis, which involves injecting dialysate, also called dialysis fluid, into the patient's peritoneal cavity via a catheter. The dialysate comes into contact with the peritoneum of the peritoneal cavity. Waste products, toxins, and excess fluid enter the dialysate from the patient's bloodstream, through the peritoneum, into the dialysate due to diffusion and osmosis; that is, an osmotic gradient occurs across the membrane. The osmotic agent in dialysis provides this osmotic gradient. Used or depleted dialysate is drained from the patient, removing waste products, toxins, and excess fluid from the patient. This cycle is repeated, for example, multiple times.

[0010] There are various types of peritoneal dialysis treatments, including continuous outpatient peritoneal dialysis ("CAPD"), automated peritoneal dialysis ("APD"), tidal flow dialysis, and continuous fluid peritoneal dialysis ("CFPD"). CAPD is a manual dialysis procedure. Here, the patient manually connects an implanted catheter to a drain to allow used or depleted dialysate fluid to be drained from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysate to inject fresh dialysate into the patient through the catheter. The patient disconnects the catheter from the bag of fresh dialysate, allowing the dialysate to remain in the peritoneal cavity, and the transfer of waste products, toxins, and excess fluid occurs. After a certain retention period, the patient repeats the manual dialysis procedure, for example, four times per day, with each procedure lasting approximately one hour. Manual peritoneal dialysis requires a considerable amount of time and effort from the patient and has room for improvement.

[0011] Automated peritoneal dialysis ("APD") is similar to CAPD in that the dialysis procedure includes draining, filling, and retention cycles. However, APD machines typically perform the cycles automatically while the patient is asleep. APD machines free patients from the need to manually perform the procedure cycles and the need to transport supplies during the day. An APD machine is fluidically connected to an implanted catheter, a source or bag of fresh dialysis fluid, and a fluid drain. The APD machine pumps fresh dialysis fluid from the dialysis fluid source through the catheter into the patient's peritoneal cavity. The APD machine also allows the dialysis fluid to remain in the cavity, enabling the transfer of waste, toxins, and excess fluid. The source may include multiple sterile dialysis fluid bags.

[0012] The APD machine pumps used or depleted dialysate from the peritoneal cavity through a catheter into a drain. Like a manual process, several draining, filling, and retention cycles occur during dialysis. The "final filling" occurs at the end of APD and remains in the patient's peritoneal cavity until the next procedure.

[0013] Any of the above modalities performed by machines may be performed on a schedule and may require a start procedure. For example, dialysis patients typically undergo treatment on a schedule, such as every other day or daily. Blood treatment machines typically require a certain amount of time before treatment, for example, to set up for disinfection procedures. Patients for the above modalities may lead busy lives and have other errands to run that make it difficult to schedule treatment on the scheduled day. One solution considered useful for patients is disclosed in U.S. Patent No. 8,315,654 (Patent No. 654, Patent Document 1), titled "Extracorporeal Blood Treatment Device And Method For Preparing Blood Treatment Using An Extracorporeal Blood Treatment Device." Patent No. 654 discloses a form in which the patient transmits a start code to the blood treatment device from an external communication unit to initiate a routine in the blood treatment device (see Patent No. 654 in the abstract). However, as will be discussed in more detail below, the form of Patent No. 654 does not take into account certain important factors related to the machine and the treatment itself.

[0014] An improved form is needed accordingly to allow patients to interact remotely with medical fluid delivery machines. [Prior art documents] [Patent Documents]

[0015] [Patent Document 1] U.S. Patent No. 8,315,654 [Overview of the project] [Means for solving the problem]

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

[0017] The modality described above may be provided by a medical fluid delivery machine that houses components necessary for delivering medical fluids, such as one or more pumps, multiple valves, optionally heaters, optionally multiple sensors such as one or more of the following: 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 for controlling the equipment described above. The medical fluid delivery machine may also include one or more filters, such as dialyzers or hemofilters for cleaning blood and / or ultrafilters for purifying water, dialysate, or other fluids.

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

[0019] Much of the appeal of home-based treatment for patients revolves around the lifestyle flexibility provided by allowing patients to perform treatments at home, primarily according to their own schedules. However, home medical fluid delivery machines may include software timers that instruct and constrain the user or patient. Home hemodialysis systems may require the patient to be in close proximity to the home hemodialysis machine, for example, to initiate pre-treatment, inter-treatment, and post-treatment sequences.

[0020] In one particular example, a home treatment machine may reuse certain components by disinfecting them between treatments. The machine may employ one or more disinfection timers that require a patient or caregiver to start a treatment using the machine before the disinfection timer expires. Otherwise, the patient would need to wait until another disinfection procedure is completed before starting the treatment. A home treatment machine in some embodiments communicates a treatment start time limit via the machine's graphical user interface, which requires the patient to be near the machine in order to access and respond to the start time limit.

[0021] It should be understood that the present disclosure applies to any type of disinfection, such as thermal disinfection and chemical disinfection. In this regard, the present disclosure is not limited to home treatment machines. For example, in-center machines are typically chemically disinfected and may set a treatment start deadline after such disinfection. Additionally, the present disclosure is not limited to start time limits based on disinfection. It may also apply to other start time limits, such as those based on completion of pre-infusion. Furthermore, the present disclosure is not limited to an initial start time limit. For example, most machines will allow a patient to temporarily pause a treatment, disconnect from the machine, and perform any necessary actions away from the machine. For blood treatments, the machine may typically either rinse the blood back to the patient and circulate the dialysis fluid for a period of time or not. In either case, the time a patient may be temporarily disconnected from the machine is not unlimited, and it is contemplated that the present disclosure also applies to return time limits.

[0022] In one embodiment, the system of the present disclosure provides a software application (an "app") installed on a patient and / or caregiver's personal mobile communication device, such as a smartphone. The app, in one embodiment, 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 with a patient and / or caregiver's personal mobile communication device, such as a smartphone, using the text messaging feature directly through the middleware software application. In either case, the app or text message, in one embodiment, is constructed to remind the patient of any impending deadlines without connecting the patient to the machine and to enable the patient and / or caregiver to track when treatment needs to be initiated.

[0023] Alternatively, or in addition, it is contemplated to configure the communication software to automatically program reminders on the user's mobile communication device, such as on the device's native task tracking feature, such as a calendar application. Most smartphones are provided with a calendar that divides each day into time segments such as hours. The software of the system and methodology of the present disclosure can access the approved patient and / or caregiver's smartphone calendar and be programmed to enter appropriate information, such as the machine starting or completing disinfection within that time segment, into the appropriate time segment of the appropriate day.

[0024] In one embodiment, communication from the software system and methodology of the Disclosure is unidirectional. For example, communication may be from a medical fluid delivery machine, which may be a home-based machine, to a patient's or caregiver's mobile communication device. In an alternative embodiment, the software system and methodology of the Disclosure enables bidirectional communication between the medical fluid delivery machine and the patient's or caregiver's mobile communication device. In one example, bidirectional communication may allow a machine routine to be remotely initiated by a patient or caregiver using their mobile communication device. One exemplary routine is an automated self-test routine, which may be performed without any user interaction with the system other than starting or initiating a sequence. Remotely initiating a sequence may benefit the patient or caregiver by providing additional time, for example, that the patient or caregiver can leave the machine to perform other tasks. Communication becomes bidirectional when the machine initiates communication by indicating that the machine is ready to perform the self-test routine. The patient or caregiver responds to the machine via the software system and methodology of the Disclosure for a desired amount of time and initiates the sequence.

[0025] The software of the system and methodology of this disclosure considers disabling communication between the patient and / or caregiver and the machine whenever the machine is in the “connected patient” software state. For example, if a clinician attempts to send a command to a machine currently treating a patient, the command may be blocked by a middleware software application so that the command is not forwarded to the machine. The middleware software application may then reply to the clinician, informing them that the machine is busy and not allowing communication.

[0026] As described in detail below, the medical fluid data transfer systems and methodologies of this disclosure may operate within a larger platform system encompassing many machines, including many different types of machines, patients, clinicians, physicians, maintenance personnel, electronic medical record ("EMR") databases, websites, a resource planning system that handles data generated through patient and clinician communications, and business intelligence. The medical fluid data transfer systems and methodologies of this disclosure operate seamlessly within the entire system without violating its rules and protocols.

[0027] Furthermore, disclosed herein are systems specifically configured for a hospital or clinical setting that enable a single physician, nurse, or clinician to monitor and, in some cases, control multiple medical fluid delivery machines. The hospital or clinical system enables the multiple machines to be viewed and, in some cases, controlled via a single mobile communication device.

[0028] In light of the disclosure herein, and without limiting this disclosure in any way, unless otherwise specified, a first aspect of this disclosure, which can be combined with any other aspects enumerated herein, includes a first medical fluid delivery system configured to (i) ensure that a first medical fluid delivery machine is ready to perform a task, or (ii) generate a first message for remote transmission to a first patient or caregiver indicating a pre-programmed time for the first medical fluid delivery machine to perform the same or a different task, and a second medical fluid delivery machine configured to (i) ensure that a second medical fluid delivery machine is ready to perform the same or a different task, or (ii) generate a second message for remote transmission to a second patient or caregiver indicating a pre-programmed time for the second medical fluid delivery machine to perform the same or a different task.

[0029] In a second aspect of this disclosure, which may be combined with any other aspects enumerated herein unless otherwise specified, the first and second medical fluid delivery machines communicate data with at least one server, the first and second messages being delivered to the server, the server being 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.

[0030] Unless otherwise specified, in the third aspect of this disclosure, which may be combined with the second aspect in combination with any other aspect enumerated herein, at least one server includes at least one dedicated server or cloud server.

[0031] Unless otherwise specified, a fourth aspect of this disclosure, which may be combined with the second aspect in combination with any other aspect enumerated herein, includes relaying at least one of the first or second messages by using a cellular network that networks at least one server and at least one of the first or second mobile communication devices.

[0032] Unless otherwise specified, the fifth aspect of this disclosure, which may be combined with the fourth aspect in combination with any other aspect enumerated herein, describes communications over a cellular network as being via the Short Messaging Service ("SMS") or Multimedia Messaging Service ("MMS") protocol.

[0033] Unless otherwise specified, in the sixth aspect of this disclosure, which may be combined with the second aspect in combination with any other aspect enumerated herein, the first and second medical fluid delivery machines are home machines that communicate data with at least one server via an internet connection.

[0034] Unless otherwise specified, in the seventh aspect of this disclosure, which may be combined with the second aspect in combination with any other aspect enumerated herein, the first and second medical fluid delivery machines are in-center machines, and at least one server is maintained at the center.

[0035] Unless otherwise specified, an eighth aspect of this disclosure, which may be combined with the second aspect in combination with any other aspect enumerated herein, includes the relay of at least one of the first or second messages by at least one server, which includes updating a software application downloaded to at least one of the first or second mobile communication devices.

[0036] Unless otherwise specified, in the ninth aspect of this disclosure, which may be combined with the eighth aspect in combination with any other aspect enumerated herein, at least one software application is downloaded from the system.

[0037] Unless otherwise specified, a tenth aspect of this disclosure, which may be combined with the second aspect in combination with any other aspect enumerated herein, includes the relay of at least one of the first or second messages by at least one server, which includes updating a calendar installed on at least one of the first or second mobile communication devices.

[0038] Unless otherwise specified, the eleventh aspect of this disclosure, which can be combined with any other aspects listed herein, includes the same or different tasks, including startup procedure tasks.

[0039] Unless otherwise specified, the twelfth aspect of this disclosure, which can be combined with any other aspects enumerated herein, includes the same or different tasks, including disinfection procedures or self-testing routines.

[0040] Unless otherwise specified, in a thirteenth aspect of this disclosure, which can be combined with any other aspects enumerated herein, the pre-programmed time for at least one of the first or second medical fluid delivery machines is (i) a set duration from when the first or second message was generated, or (ii) a programmed start time for the same or different task.

[0041] Unless otherwise specified, a 14th aspect of this disclosure, which may be combined with any other aspects enumerated herein, includes a medical fluid delivery system comprising: a medical fluid delivery machine configured to generate a message indicating that (i) 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 a different task; and at least one server that data-communicates with the medical fluid delivery machine to receive messages, the server including middleware software for relaying messages from the medical fluid delivery machine to a remote mobile communication device.

[0042] Unless otherwise specified, in Aspect 15 of this Disclosure, which may be combined with Aspect 14 in combination with any other aspects enumerated herein, middleware software updates software applications downloaded on mobile communication devices in order to relay messages.

[0043] Unless otherwise specified, in Aspect 16 of this Disclosure, which may be combined with Aspect 14 in combination with any other aspects enumerated herein, middleware software updates a calendar installed on a mobile communication device in order to relay messages.

[0044] Unless otherwise specified, in Aspect 17 of this Disclosure, which may be combined with Aspect 14 in combination with any other aspects enumerated herein, the middleware software uses a cellular communication network that networks at least one server and at least one of the first or second mobile communication devices to relay messages.

[0045] Unless otherwise specified, in Aspect 18 of this Disclosure, which may be combined with Aspect 14 in combination with any other aspects enumerated herein, at least one server includes at least one dedicated server or cloud server.

[0046] Unless otherwise specified, a 19th aspect of the present disclosure, which can be combined with any other aspects enumerated herein, includes a medical fluid delivery system comprising a medical fluid delivery machine configured to generate a message indicating that the medical fluid delivery machine is ready to perform a task, and at least one server communicating data with the medical fluid delivery machine via a first link to receive the message, the 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 indicating that the task should be initiated via the second link, and (iii) send a notification to the medical fluid delivery machine via the first link to initiate the task.

[0047] Unless otherwise specified, in the 20th aspect of this disclosure, which may be combined with the 19th aspect in combination with any other aspect enumerated herein, the first link is an internet link.

[0048] Unless otherwise specified, in Aspect 21 of the Disclosure, which may be combined with Aspect 19 in combination with any other aspects enumerated herein, the second link is an Internet link or a cellular communication network link.

[0049] Unless otherwise specified, in Aspect 22 of this Disclosure, which may be combined with Aspect 19 in combination with any other aspects enumerated herein, at least one server includes at least one dedicated server or cloud server.

[0050] Unless otherwise specified, in a 23rd aspect of this disclosure, which may be combined with any other aspects enumerated herein, the mobile communication device includes a first link to a first medical fluid delivery machine, the mobile communication device enabling the mobile communication device to receive from the first medical fluid delivery machine a first message indicating a pre-programmed time for the first medical fluid delivery machine to perform the same or different task, or (ii) a second link to a second medical fluid delivery machine, the mobile communication device enabling the mobile communication device to receive from the second medical fluid delivery machine a second message indicating a pre-programmed time for the second medical fluid delivery machine to perform the same or different task.

[0051] Unless otherwise specified, in the 24th aspect of this disclosure, which may be combined with the 23rd aspect in combination with any other aspect enumerated herein, the first and second links each include first and second icons on the screen of a mobile communication device, and the first and second icons each are associated with first and second medical fluid delivery machines.

[0052] Unless otherwise specified, in Aspect 25 of this Disclosure, which may be combined with Aspect 24 in combination with any other aspects enumerated herein, the first and second icons are associated with the first and second messages, respectively.

[0053] Unless otherwise specified, in Aspect 26 of this Disclosure, which may be combined with Aspect 24 in combination with any other aspects enumerated herein, at least one of the first or second icons is user-selectable for viewing the first or second message, respectively.

[0054] Unless otherwise specified, in Aspect 27 of this Disclosure, which may be combined with Aspect 24 in combination with any other aspects enumerated herein, the first and second icons are arranged on a mobile communication device in accordance with the manner in which the first and second medical fluid delivery machines are arranged in the facility.

[0055] Unless otherwise specified, in Aspect 28 of the Disclosure, which may be combined with Aspect 24 in combination with any other aspects enumerated herein, the mobile communication device includes at least one action icon that the user can select to cause at least one of the first or second medical fluid delivery machines to perform the same or different task.

[0056] Unless otherwise specified, in Aspect 29 of this Disclosure, which may be combined with Aspect 28 in combination with any other aspects enumerated herein, at least one action icon is operated in combination with a first or second icon for selecting at least one of a first or second medical fluid delivery machine to perform the same or different tasks.

[0057] Unless otherwise specified, a 30th aspect of this disclosure, which may be combined with any other aspects enumerated herein, includes 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 which displays a first icon representing the first medical fluid delivery device and a second icon representing 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, wherein the software application is programmed to receive at least one status update from the server and the first or second medical fluid delivery device via the first and second links.

[0058] Unless otherwise specified, in Aspect 31 of this Disclosure, which may be combined with Aspect 30 in combination with any other aspects enumerated herein, the first and second communication links are Internet links.

[0059] Unless otherwise specified, in Aspect 32 of this Disclosure, which may be combined with Aspect 30 in combination with any other aspects enumerated herein, the software application is further programmed to transmit operational commands to the first and second medical fluid delivery machines via the server and the first and second links.

[0060] In the 33rd aspect of this disclosure, any of the structures and functionalities disclosed in connection with Figure 1-9 may be combined with any other structures and functionalities disclosed in connection with Figure 1-9.

[0061] In light of this disclosure and the aspects described above, it is therefore advantageous to provide an improved medical fluid delivery system.

[0062] Another benefit of this disclosure is that it provides an improved lifestyle for patients.

[0063] A further benefit of this disclosure is that it provides improved clinician or caregiver efficiency.

[0064] Providing improved mechanical efficiency is yet another advantage of this disclosure.

[0065] Providing improved patient compliance is another further benefit of this disclosure.

[0066] Another advantage of this disclosure is that it provides medical fluid data transfer systems and methodologies that can be applied to different types of medical fluid delivery machines.

[0067] A further advantage of this disclosure is to provide a medical fluid data transfer system and methodology that enables communication between a medical fluid delivery machine and multiple individuals, such as a patient and a clinician, or a patient and a primary caregiver.

[0068] Furthermore, a benefit of this disclosure is that it reduces the waste of disposable sets and other auxiliary textile products that often occur when the machine timer expires.

[0069] The advantages discussed herein may be found in one or more of the embodiments disclosed herein, and perhaps not in all of them. Additional features and advantages will be evident from the embodiments and drawings for carrying out the invention described herein. The present invention provides, for example, the following: (Item 1) A medical fluid delivery system, wherein the medical fluid delivery system is A medical fluid delivery machine, wherein the medical fluid delivery machine is configured to generate a message indicating that the medical fluid delivery machine is in a state where it can perform a task, At least one server that communicates data with the medical fluid delivery machine via a first link in order to receive the aforementioned message Prepare, The aforementioned at least one server is (i) relaying the message from the medical fluid delivery machine to a remote mobile communication device via a second link, (ii) Receiving a response from the remote mobile communication device via the second link indicating that the task should be initiated, (iii) Sending a notification to the medical fluid delivery machine via the first link to initiate the task A medical fluid delivery system configured to perform the following actions. (Item 2) The aforementioned first link is an internet link, the medical fluid delivery system described in item 1. (Item 3) The medical fluid delivery system described in item 1, wherein the second link is an internet link or a cellular communication network link. (Item 4) The medical fluid delivery system according to item 1, wherein the at least one server includes at least one dedicated server or cloud server. (Item 5) A medical fluid delivery system, wherein the medical fluid delivery system is A medical fluid delivery machine, wherein the medical fluid delivery machine is (i) The medical fluid delivery machine is in a state where it can perform the task, or (ii) The pre-programmed time for the medical fluid delivery machine to perform the same or different tasks A medical fluid delivery machine configured to generate a message indicating, To receive the aforementioned message, at least one server communicates with the medical fluid delivery machine and Equipped with, The medical fluid delivery system includes middleware software for relaying the messages from the medical fluid delivery machine to a remote mobile communication device, wherein the at least one server is part of the medical fluid delivery system. (Item 6) The medical fluid delivery system according to item 5, wherein the middleware software updates a software application downloaded on the mobile communication device in order to relay the message. (Item 7) The medical fluid delivery system according to item 5, wherein the middleware software updates a calendar installed on the mobile communication device in order to relay the message. (Item 8) The medical fluid delivery system according to item 5, wherein the middleware software uses a cellular communication network that networks the at least one server and at least one of the first or second mobile communication devices in order to relay the messages. (Item 9) The medical fluid delivery system described in item 5, wherein the at least one server includes at least one dedicated server or cloud server. (Item 10) A medical fluid delivery system, wherein the medical fluid delivery system is A first medical fluid delivery machine, wherein the first medical fluid delivery machine is (i) The first medical fluid delivery machine is in a state where it can perform the task, or (ii) A pre-programmed time for the first medical fluid delivery machine to perform the same or different tasks. A first medical fluid delivery machine configured to generate a first message for remote transmission to a first patient or caregiver indicating, Second medical fluid delivery machine and Equipped with, The second medical fluid delivery machine is (i) The second medical fluid delivery machine is in a state where it can perform the same or different task, (ii) A medical fluid delivery system in which the second medical fluid delivery machine is configured to generate a second message for remote transmission to a second patient or caregiver indicating a pre-programmed time for performing the same or different task. (Item 11) The medical fluid delivery system according to item 10, wherein the first and second medical fluid delivery machines communicate data with at least one server, the first and second messages are delivered to the server, and the server is configured to (i) relay the first message to a first mobile communication device for the first patient or caregiver, and (ii) relay the second message to a second mobile communication device for the second patient or caregiver. (Item 12) The medical fluid delivery system according to item 11, wherein the at least one server includes at least one dedicated server or cloud server. (Item 13) The medical fluid delivery system according to item 11, wherein relaying at least one of the first or second messages includes using a cellular network that networks the at least one server and at least one of the first or second mobile communication devices. (Item 14) The medical fluid delivery system described in item 13, wherein the communication via the cellular network is via the Short Message Service ("SMS") or Multimedia Message Service ("MMS") protocol. (Item 15) The medical fluid delivery system according to item 11, wherein the first and second medical fluid delivery machines are home-based machines that communicate data with the at least one server via an internet connection. (Item 16) The medical fluid delivery system according to item 11, wherein the first and second medical fluid delivery machines are in-center machines, and the at least one server is maintained at the center. (Item 17) The medical fluid delivery system according to item 11, wherein relaying at least one of the first or second messages by the at least one server includes updating a software application downloaded to at least one of the first or second mobile communication devices. (Item 18) The aforementioned at least one software application is downloaded from the system, the medical fluid delivery system described in item 17. (Item 19) The medical fluid delivery system according to item 11, wherein relaying at least one of the first or second messages by the at least one server includes updating a calendar installed on at least one of the first or second mobile communication devices. (Item 20) The aforementioned same or different tasks include the medical fluid delivery system described in item 10, including the startup procedure tasks. (Item 21) The aforementioned same or different tasks include disinfection procedures or self-testing routines for the medical fluid delivery system described in item 10. (Item 22) The medical fluid delivery system according to item 10, wherein the pre-programmed time for at least one of the first or second medical fluid delivery machines is (i) a set duration from when the first or second message was generated, or (ii) a programmed start time for the same or different task. (Item 23) A mobile communication device, wherein the mobile communication device is A first link to a first medical fluid delivery machine, wherein the first link is (i) the first medical fluid delivery machine is in a state where it can perform the same or different tasks, or (ii) the mobile communication device receives a first message from the first medical fluid delivery machine indicating a pre-programmed time for the first medical fluid delivery machine to perform a task, and Second link to the second medical fluid delivery machine and Equipped with, The second link mentioned above is, (i) The second medical fluid delivery machine is in a state where it can perform the same or different task, or (ii) The mobile communication device is able to receive a second message from the second medical fluid delivery machine indicating a pre-programmed time for the second medical fluid delivery machine to perform the same or different task. Mobile communication device. (Item 24) The mobile communication device described in item 23, wherein the first and second links each include first and second icons on the screen of the mobile communication device, and the first and second icons each are associated with the first and second medical fluid delivery machines. (Item 25) The first and second icons are the mobile communication devices described in item 24, which are associated with the first and second messages, respectively. (Item 26) The mobile communication device according to item 24, wherein at least one of the first or second icons is user-selectable for viewing the first or second message. (Item 27) The mobile communication device according to item 24, wherein the first and second icons are arranged on the mobile communication device in accordance with the manner in which the first and second medical fluid delivery machines are arranged in the facility. (Item 28) A mobile communication device according to item 24, comprising at least one action icon, wherein the at least one action icon is user-selectable to cause at least one of the first or second medical fluid delivery machines to perform the same or different task. (Item 29) The mobile communication device according to item 28, wherein the at least one action icon is operated in combination with the first or second icon for selecting at least one of the first or second medical fluid delivery machines, respectively, to perform the same or different task. (Item 30) A medical fluid delivery system, wherein the medical fluid delivery system is A first medical fluid delivery device and A second medical fluid delivery device, A server that communicates with the first and second medical fluid delivery devices, A software application for a mobile communication device, wherein the software application causes a first icon representing the first medical fluid delivery device to be displayed and a second icon representing the second medical fluid delivery device to be displayed. A first communication link between the first and second medical fluid delivery devices and the server, A second communication link between the server and the software application Equipped with, A medical fluid delivery system in which the software application is 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. (Item 31) The first and second communication links are internet links, as described in item 30 of the medical fluid delivery system. (Item 32) The medical fluid delivery system according to item 30, wherein the software application is further programmed to transmit operation commands to the first and second medical fluid delivery machines via the server and the first and second links. [Brief explanation of the drawing]

[0070] [Figure 1] Figure 1 is a schematic diagram illustrating one embodiment of a medical fluid data transfer system, wherein the system incorporates a medical fluid delivery machine of the present disclosure, and data can be transferred to and from such a machine.

[0071] [Figure 2] Figure 2 is a schematic diagram of one embodiment of the medical fluid delivery machine of the present disclosure.

[0072] [Figure 3] Figure 3 is a perspective view illustrating a blood set for use with one embodiment of the medical fluid delivery machine shown in Figure 2.

[0073] [Figure 4] Figure 4 is a schematic diagram of one embodiment of the medical fluid delivery machine, data transfer system, and method of the present disclosure.

[0074] [Figure 5] Figure 5 is a schematic diagram of a second embodiment of the medical fluid delivery machine and data transfer system and method of the present disclosure.

[0075] [Figure 6] Figure 6 is a schematic diagram of a third embodiment of the medical fluid delivery machine and data transfer system and method of the present disclosure.

[0076] [Figure 7]Figure 7 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device and data transfer system and method of the present disclosure having a mobile communication device application in a first state.

[0077] [Figure 8] Figure 8 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device and data transfer system and method of the present disclosure, having a mobile communication device application in a second state.

[0078] [Figure 9] Figure 9 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device and data transfer system and method of the present disclosure having a mobile communication device application in a third state. [Modes for carrying out the invention]

[0079] The examples described herein are applicable to any medical fluid delivery system for delivering medical fluids such as blood, dialysis fluids, replacement fluids, and / or intravenous drugs ("IV"). The examples are particularly well suited to the treatment of renal failure, such as hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), continuous renal replacement therapy ("CRRT"), and peritoneal dialysis ("PD"), which are referred to herein collectively or generally, or individually, as the treatment of renal failure. The medical fluid delivery machine may, as an alternative, be a drug delivery or nutritional fluid delivery device such as a high-volume peristaltic pump or syringe pump. The machines described herein may be used in home settings. For example, a machine operating in the data transfer form of this disclosure may be employed with a home HD machine that can be activated, for example, at night while the patient is sleeping. The medical fluid data transfer systems and methodologies of this disclosure may, as an alternative, be used to assist clinicians or nurses in hospitals and / or clinics.

[0080] Referring here to the drawings, in particular Figure 1, a medical fluid data transfer system 10 operating within a medical fluid delivery machine 90 is illustrated. System 10 incorporates many medical fluid delivery machines 90 (one type of which will be discussed in detail below). The machines 90 of the data transfer 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 nutritional fluid delivery).

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

[0082] The home treatment machine 90 may receive purified water from a water treatment device 60, as discussed above, at its front end. In one embodiment, the water treatment device 60 connects to the home treatment machine 90 via an Ethernet® cable. In the illustrated embodiment, the home treatment machine 90 operates with other devices besides the water treatment device 60, such as a blood pressure monitor 104, a weighing device, e.g., a wireless weighing device 106, and a user interface such as a wireless tablet user interface 122. In one embodiment, the home treatment machine 90 connects wirelessly to a server 118 via a modem 102. Each of these components may be located within the patient's home, as demarcated by the dashed lines in Figure 1 (although it is not necessary). One or more or all of the components 60, 104, 106, and 122 may communicate with the home treatment machine 90 by wire or wireless. Wireless communication may include Bluetooth®, WiFi, etc. TM This may be via Zigbee®, Z-Wave®, Wireless Universal Serial Bus ("USB"), infrared, or any other suitable wireless communication technology. Alternatively, one or more or all of components 60, 104, 106, and 122 may communicate with the home medical device 90 via wired communication.

[0083] The connectivity server 118 communicates with the medical fluid delivery machines 90 via the medical device system hub 120. The system hub 120 enables data and information about each home treatment machine 90 and its peripherals to be exchanged between the machines 90 and other clients connected to the server 118 via the connectivity server 118. In the illustrated embodiment, the system hub 120 is connected to a service portal 130, an enterprise resource planning system 140, a web portal 150, a business intelligence portal 160, a HIPAA-compliant database 124, a product development team 128, and an electronic medical record database maintained, for example, in a clinic or hospital 126a-126n.

[0084] Electronic medical record ("EMR") databases in clinics or hospitals 126a-126n store electronic information about patients. System hub 120 transmits data collected from log files of machine 90 to hospital or clinic databases 126a-126n, which may merge or supplement the medical records of those patients. Databases in clinics or hospitals 126a-126n may include patient-specific treatment and prescription data, and therefore access to such databases may be highly restricted. Enterprise resource planning system 140 retrieves 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-152n treating patients to access a publicly available website for 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 / pharmaceutical safety monitoring 166.

[0085] It should be understood that the systems, methods, and procedures described herein may be implemented using one or more computer programs or components. The programs of a component may 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 or optical disks, optical memory, or other storage media. The instructions may be configured to be executed by a processor that, upon execution of the set of computer instructions, implements all or part of the disclosed methods and procedures, or a processor that facilitates such implementation.

[0086] In one embodiment, the home treatment device 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, physician, and nurse involved in managing the patient's health and well-being.

[0087] In one embodiment, the home treatment machine 90 writes log files using, for example, a Linux® operating system. The log files document the data of the home treatment machine 90, including peripheral device data. The log files may include one or more of the following: Extended Markup Language ("XML"), comma-separated values ​​("CSV"), or text files. The log files are located in the home treatment machine 90's software file server box. It is also considered that data not transmitted to the machine 90 may be stored in a peripheral device, for example, a water treatment device 60. Such data may be acquired separately via a wired or wireless connection to the peripheral device, or downloaded through other data connections or storage media. For example, a maintenance worker may access additional data via a laptop connected to the water treatment device 60 or a wireless meter 106, for example, via an Ethernet® connection. Alternatively, additional data may be read remotely from a peripheral device, and the home treatment machine 90 may act as a data transfer channel between the peripheral device and an authorized client of a medical fluid data transfer system.

[0088] In one embodiment, the home-based medical device 90 uses connectivity services, for example, via the Internet, to transfer data between the modem 102 and the system hub 120. Here, a dedicated line may be provided at each patient's home to connect the home-based medical device 90 to the connectivity server 118 via the modem 102. In one embodiment, the home-based medical device 90 accesses the Internet using a separate, for example, 3G, 4G, or 5G modem 102. The modem 102 is a Vodafone TM Internet service providers (ISPs) such as the above can be used. In one implementation, a connectivity agent 114 developed by a connectivity service provider (e.g., the provider of the connectivity server 118) is installed on the home treatment machine 90 and started on the machine's ACPU 50. One preferred connectivity service is Axeda TMProvided by [the system], it provides a securely managed connection 116 between the medical device and the connectivity server 118.

[0089] The connectivity agent 114 enables the home healthcare machine 90 to connect to the connectivity server 118, transfer data to and from the connectivity server 118. The connectivity services operating through the agent 114 and server 118 ensure that the connection with the machine 90 is secure, that data correctly passes through the machine 90's firewall, that data or system crashes are present, and that the connectivity server 118 is communicating with the correct home healthcare machine 90.

[0090] In one embodiment, the home treatment machine 90 can connect to the connectivity server 118 only when the connectivity agent 114 is turned on or active. During treatment and post-treatment disinfection, while the machine 90 and its peripherals are functioning, in one embodiment, the connectivity agent 114 is turned off, which prevents the home treatment machine 90 from communicating with any entity, sending or receiving data during treatment and disinfection, or when the machine 90 is operating or started up. When the home treatment machine 90 is idle, for example, after treatment and post-treatment disinfection are complete, the ACPU 50 turns on the connectivity agent 114 in one embodiment. In another embodiment, the connectivity agent 114 is off during treatment and possibly pre-treatment. After treatment, the connectivity agent 114 uses connectivity services to read log files from the home treatment machine 90 and transfer data to the connectivity server 118. The connectivity service routes data packets to their appropriate destinations, but in one embodiment, the connectivity service does not modify, access, or encrypt the data.

[0091] In the medical fluid data transfer system 10 of Figure 1, connectivity services via the connectivity server 118 can communicate data to various locations such as the service portal 130, clinics or hospitals 126a-126n, and a web portal 150 via the system hub 120. The connectivity server 118 enables maintenance personnel 132a-132n and / or clinicians to track and retrieve various assets traversing the network, such as appropriate home treatment machines 90 and 3G, 4G, or 5G modems 102, as well as their associated information, including machine or modem serial numbers. The connectivity server 118 may be used to receive firmware upgrades remotely obtained via the service portal 130, authorized by the supervisor of the maintenance personnel 134, and provide them to authorized home treatment machines 90 and associated peripherals such as water treatment devices 60.

[0092] Referring here to Figure 2, an example of a schematic HD flow diagram for a medical fluid delivery machine 90 is illustrated. Since the HD system in Figure 2 is relatively complex, Figure 2 and its discussion also provide support for any of the renal failure treatment modalities discussed above, as well as for IV, drug delivery, or nutritional fluid delivery machines. Generally, a simplified version of the medical fluid delivery machine 90 with a dialysis fluid or process fluid delivery circuit is shown. The blood circuit is also simplified, but not to the same extent as the dialysis fluid circuit. The circuits have been simplified to facilitate the explanation in this disclosure, and it should be understood that the system, if implemented, would have additional structures and functionalities, such as those found in publications incorporated by reference above.

[0093] The medical fluid delivery machine 90 in Figure 2 includes a blood circuit 20. The blood circuit 20 draws blood from 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 that connects to an arterial needle 14b that communicates with the patient 12 for blood collection. The venous line 16 includes a venous line connector 16a that connects to a venous needle 16b that communicates with the patient for blood return. The arterial and venous lines 14 and 16 also include line clamps 18a and 18v, which may be spring-loaded fail-safe mechanical pinch clamps. In one embodiment, the line clamps 18a and 18v automatically close in an emergency situation.

[0094] The arterial and venous lines 14 and 16 also include air or bubble detectors 22a and 22v, which may be ultrasonic air detectors. The air or bubble detectors 22a and 22v search for air in the arterial and venous lines 14 and 16, respectively. If air is detected by one of the air detectors 22a and 22v, the system 10 closes the line clamps 18a and 18v, pauses the blood and dialysis fluid pumps, and provides the patient with an order to clear the air so that the procedure can be resumed.

[0095] In the illustrated embodiment, the blood pump 30 is located within the arterial line 14. In the illustrated embodiment, the blood pump 30 includes a first blood pump pod 30a and a second blood pump pod 30b. The blood pump pod 30a operates with an inlet valve 32i and an outlet valve 32o. The blood pump pod 30b operates with an inlet valve 34i and an outlet valve 34o. In one embodiment, each of the blood pump pods 30a and 30b is, for example, a blood container including a spherical rigid outer shell, with a flexible diaphragm located within the shell to form a diaphragm pump. One side of each diaphragm receives blood, while the other side of each diaphragm is operated by positive and negative pneumatic pressure. Alternatively, the blood pump 30 is a peristaltic pump operating with the arterial line 14 or a plurality of peristaltic pumps operating with the arterial line 14 and the venous line 16.

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

[0097] A primary 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 (as well as other sensors in system 10 such as temperature sensors, blood leak detectors, conductivity sensors, pressure sensors, and access disconnect transducers 86, 88) and controls components such as line clamps 18a and 18v, blood pump 30, heparin pump 26, dialysis fluid pumps 64 and 96, and valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98o. Blood exiting the hemofilter 40 via the venous 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 venous line 16.

[0098] In the hemodialysis version of the medical fluid delivery machine 90 shown in Figure 2, the dialysis fluid is pumped along the outside of the membrane of the hemofilter 40, while the blood is pumped through the inside of the hemofilter membrane. The dialysis fluid is prepared starting with water purification via the water purification unit 60. One suitable water purification unit is the "Water Purification System and The method is described in U.S. Patent Publication No. 2011 / 0197971, filed on April 25, 2011, which is incorporated herein by reference and relies upon in its entirety. In one embodiment, the water purification unit includes a filter and other structures for purifying tap water (e.g., removing ions such as pathogens and chlorine) such that the water is below 0.03 endotoxin units / ml ("EU / ml") and below 0.1 colony-forming units / ml ("CFU / ml") in one implementation. The water purification unit 60 may be provided in a housing separate from the housing or chassis of the hemodialysis machine 90, which includes the blood circuit 20 and the dialysis fluid circuit 70.

[0099] The dialysis fluid circuit 70 is again greatly simplified in Figure 2 for the sake of illustration. The actual dialysis fluid circuit 70 may include all of the relevant structures and functions described in the publication incorporated by reference above. Some features of the dialysis fluid circuit 70 are illustrated in Figure 2. In the illustrated embodiment, the dialysis fluid circuit 70 includes a hemofilter-bound dialysis fluid pump 64. In one embodiment, the pump 64 is configured identically to the blood pump 30. Like the pump 30, the pump 64 includes a pair of pump pods 66, each having an inlet valve 68i and an outlet valve 68o, which may again be configured spherically. The two pump pods are operated alternately, like the blood pump 30, so that one pump pod fills with HD dialysis fluid while the other pump pod releases HD dialysis fluid.

[0100] Pump 64 is a hemofilter-bound dialysis fluid pump. There is another double-pod pump chamber 96 that works with valves 98i and 98o located in the discharge line 82 to push out the used dialysis fluid. There is a third pod pump (not shown) for pumping purified water through the bicarbonate cartridge 72. There is a fourth pod pump (not shown) used to pump acid from the acid container 74 into the mixing line 62. The third and fourth pumps, i.e., the concentrate pumps, may be single pod pumps in one embodiment, as continuous pumping is not very important in the mixing line 62 due to a buffer dialysis fluid tank (not shown) between the mixing line 62 and the hemofilter-bound dialysis fluid pump 64.

[0101] A fifth pod pump (not shown), provided in the discharge line 82, is used to remove a known amount of ultrafiltration ("UF") when HD treatment is administered. System 10 tracks the UF pump to control and understand the amount of ultrafiltration removed from the patient. System 10 ensures that the required amount of ultrafiltration is removed from the patient by the end of the procedure.

[0102] Each of the pumps described above may, as an alternative, be a peristaltic pump operating with a pressure pipe. Where applicable, the system valves may still be pneumatically operated in accordance with the features of this disclosure.

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

[0104] Figure 2 also illustrates that the dialysis fluid is pumped along a fresh dialysis fluid line 76 through a heater 78 and an ultrafilter 80 before reaching the hemofilter 40, and then pumped so that the used dialysis fluid is discharged through a discharge line 82. The heater 78 heats the dialysis fluid to body temperature or about 37°C. The ultrafilter 80 further cleans and purifies the dialysis fluid before it reaches the hemofilter 40, filtering out foreign matter and / or contaminants introduced from the dialysis fluid, for example, through a bicarbonate cartridge 72 or an acid container 74.

[0105] The dialysis fluid circuit 70 also includes a sample port 84 in the illustrated embodiment. The dialysis fluid circuit 70 would further include a blood leak detector (not shown, but used to detect whether the fibers of the hemofilter 40 are broken) and other components not shown, such as a balance chamber, a plurality of dialysis fluid valves, and a dialysis fluid holding tank, all of which are incorporated by reference above.

[0106] In the illustrated embodiment, the medical fluid delivery machine 90 is a direct-pass system that pumps dialysis fluid once through a hemofilter and then pumps the used dialysis fluid to discharge it. Both the blood circuit 20 and the dialysis fluid circuit 70 can be disinfected with hot water after each procedure so that the blood circuit 20 and the dialysis fluid circuit 70 can be reused. In one implementation, the blood circuit 20, including the hemofilter 40, is disinfected with hot water and reused daily for about one month, while the dialysis fluid circuit 70 is disinfected with hot water and reused for about six months.

[0107] In an alternative embodiment, for example, for CRRT, multiple bags of sterile dialysis fluid or infusion fluid are bundled together and used sequentially. In such a case, empty supply bags can serve as discharge or depleted fluid bags.

[0108] The medical fluid delivery machine 90 includes an enclosure as shown by the dashed line in Figure 2. The enclosure of the machine 90 varies depending on the type of procedure, whether the procedure is in-center or home-based, and whether the dialysis fluid / infusion supply is batch type (e.g., bagged) or direct-connected.

[0109] Figure 3 illustrates that the machine 90 of Figure 2 may operate with a blood set 100. The blood set 100 includes an arterial line 14, a venous line 16, a heparin vial 24, a heparin pump 26 / blood pump 30, and a hemofilter 40 (e.g., a dialyzer). An air trap 28 may 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 and venous lines 14 and 16, respectively, for operation.

[0110] In Figures 2 and 3, any of the pumps 26, 30 (30a and 30b), 64, 96 (and other pumps not shown) and any of the valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98o, etc., can be pneumatically actuated. In one embodiment, each of the pumps and valves has a fluid side and an air side separated by a flexible membrane. Negative pneumatic pressure may be applied to the air side of the membrane to draw fluid into the pump chamber or to open the valve (or the pump or valve may be opened by venting a positive closing pressure to the atmosphere, allowing the fluid pressure to be released). Positive pneumatic pressure is applied to the air side of the membrane to discharge fluid from the pump chamber or to close the valve.

[0111] Referring now to Figure 4, System 110a of the present disclosure is illustrated. System 110a in the illustrated embodiment operates in conjunction with System 10 described above, which includes a connectivity 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, all of which are illustrated in Figure 4 as part of a cloud environment. Each of the connectivity server 118, the system hub 120, the service portal 130, the enterprise resource planning system 140, the web portal 150, and the business intelligence portal 160 may be part of a cloud environment or reside on one or more dedicated servers.

[0112] Other components of System 10 not shown in Figure 4 may also be part of System 110a. For example, the medical fluid delivery machines 90a and 90b may be located separately within the homes of patients 12a and 12b (illustrated as being outside their homes). Alternatively, the medical fluid delivery machines 90a and 90b may be located within the same clinic 126a-126n or in different locations within the clinics 126a-126n. Clinicians 112a and 112b may be located inside or outside their clinics.

[0113] The medical fluid delivery machines 90a and 90b are connected to the connectivity server 118 via a securely managed connection 116 as described above. To do so, the machines 90a and 90b are connected to the internet 52 via, for example, a modem 102 as discussed above. In one embodiment, the system hub 120 stores middleware software that can be accessed by mobile communication devices 200a and 200b (collectively referred to as device 200 in this specification, or generally referred to as device 200 individually). The mobile communication devices 200a and 200b are, for example, Android TM iOS TM Windows (registered trademark) Phone TM BlackBerry TM Sailfish OS TM TizenTM or Ubuntu Touch TM It can be a smartphone that starts on an operating system. Mobile communication devices 200a and 200b can be the possessions of patients 12a and 12b respectively, and / or can be those of clinicians 112a and 112b respectively. Mobile communication devices 200a and 200b as illustrated in FIG. 4 are also connected to the Internet 52.

[0114] In one embodiment, mobile communication devices 200a and 200b download application software (an "app") from middleware software stored on system hub 120 via their connections to the Internet 52. The app is always updated when there is a change in the state of the corresponding machine 90a or 90b. For example, medical fluid delivery machine 90a may have just completed its automated self-test routine and is currently in a state where it can perform a disinfection procedure. Machine 90a can generate a code identifying this state and send it to the middleware software stored on system hub 120. The middleware software then converts the code into a message such as "self-test completed, can disinfect state" using, for example, a lookup table, and causes the message to be displayed on the app downloaded on mobile communication device 200a of patient 12a or clinician 112a. The app can be programmed to provide a visual identifier such as an icon associated with the specific state in which machine 90a exists, along with the message. The app can also provide any one or more of an audio alert such as a "beeping" sound and / or a tactile alert such as vibration to prompt patient 12a or clinician 112a to view the app and confirm the state change of machine 90.

[0115] In another example, a medical fluid delivery machine 90b may be pre-programmed to begin treatment at 3:00 p.m. The medical fluid delivery machine 90b may require 3 hours for self-testing and disinfection. The patient 12a or clinician 112a therefore needs to be near the machine 90b by noon to begin the pre-treatment. In one embodiment, the patient 12a or clinician 112a makes a setting to the machine 90b regarding how far in advance (e.g., 2 hours) the patient 12a or clinician 112a should be notified or alerted. Thus, in this example, the machine 90b may generate a code at 10:00 a.m. and send the 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 should begin in 2 hours" and displays the message on an app downloaded on the patient 12b or clinician 112b's mobile communication device 200b. The app may again be programmed to provide a visual identifier, such as a countdown timer that counts down from 120 minutes to a timeout at zero, along with the message. The app may also provide one or more audio alerts, such as a “ring” sound and / or haptic alerts, such as vibration, prompting the patient 12b or clinician 112b to view the app and review the treatment preparation notification. The app may also be programmed to repeat the “ring” sound and / or haptic feedback at pre-programmed intervals during the countdown period, for example, every hour and every 30 minutes.

[0116] In addition to providing an application on the user's communication device 200b, or as an alternative, middleware software in the system hub 120 may be used to translate code from machine 90b into messages that are embedded on the device 200's unique task tracking features, such as its calendar application. Most smartphone devices 200 are provided with a calendar that divides each day into time segments, such as hours. Here, the messages translated by the middleware software in the system hub 120 may be programmed to access the calendar on the authorized communication device 200b and populate the appropriate information for the appropriate time segment of the appropriate day. In the example above, for the appropriate day, the unique calendar software application would have its 10:00:00 AM time slot populated with a message such as "Procedure preparations should begin in 2 hours." Audio and / or haptic feedback signals may be provided to notify the patient 12 or clinician 112 about the calendar input.

[0117] It should be understood that machines 90a and 90b, middleware software in the central server 120, and communication devices 200a and 200b may be programmed and operated as described above to provide any desired messages to patients 12a, 12b and / or clinicians 112a, 112b, and / or clinicians 112a, 112b. For example, patients 12a, 12b and / or clinicians 112a, 112b may also be informed, using the accompanying countdown timer, that the procedure needs to be started within the countdown time to avoid the need to re-disinfect machines 90a, 90b at the end of disinfection.

[0118] Referring now to Figure 5, System 110b of the present disclosure is illustrated. In the illustrated embodiment, System 110b operates in conjunction with System 10 described above, which is illustrated in Figure 5 as part of a cloud environment, but alternatively includes a connectivity 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 may reside on one or more dedicated servers. Other components of System 10 not shown in Figure 5 may also be part of System 110a. A single medical fluid delivery machine 90 is illustrated for ease of illustration, however, multiple medical fluid delivery machines 90 may also be connected to System 110b. The medical fluid delivery machine 90 may be located in the home of a patient 12 (illustrated as being outside the home) or in clinics 126a-126n relating to a clinician 112. The medical fluid delivery machine 90, again in the illustrated embodiment, is connected to the connectivity server 118 via a securely managed connection 116 and an Internet 52 connection, for example, using a modem 102.

[0119] In one embodiment, the system hub 120 stores middleware software that can be accessed by a mobile communication device 200 (shown as a single device for ease of use, but multiple devices 200 can also be connected to system 110b). The mobile communication device 200 in Figure 5 includes all the structures, functionalities, and alternatives disclosed with respect to devices 200a and 200b illustrated in Figure 4, including being connected to the Internet 52. In Figure 5, the mobile communication devices 200 may, though not required, download software applications ("apps") from the middleware software stored on the system hub 120 via their connection to the Internet 52. Apps may be operated as described above in relation to Figure 4, which includes middleware software that converts coded messages from machine 90 into a format presentable on the app. Alternatively, or in addition, the middleware software stored on the system hub 120 may be capable of converting codes from machine 90 into messages that are embedded on the mobile communication device 200's specific task tracking features, such as its calendar application, in any of the ways described in Figure 4.

[0120] Alternatively, or in addition, system 110b may include a cellular network 210 that interfaces between middleware software stored in system hub 120 and a mobile communication device 200. The cellular network 210 may include a network of cellular telephone towers operating using radio waves and / or employ satellites. Suitable communication protocols for use with the cellular network 210 of system 110b may be (i) the “Worldwide Interoperability for Microwave Access” (“WiMAX”) protocol and (ii) long-range protocols such as the “Pan-European Digital Mobile Telephone System” (“GSM®”) protocol, which is a wide-ranging long-range wireless protocol that enables data communication to many cellular telephones around the world. Network 210 may, as an alternative or in addition, employ medium-range protocols such as Wireless Local Area Networks ("WLAN"), which may be protocols that are part of the Institute of Electrical and Electronics Engineers ("IEEE") 802.11 standards, 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-Purpose Packet Radio Service ("GPRS"), cdmaOne, CDMA2000, Evolution Data Optimize ("EV-DO"), GSM® Evolutionary High-Speed ​​Data Rate ("EDGE"), Universal Mobile Communications System ("UMTS"), Digital Cordless Telephone Standard ("DECT"), Digital AMPS ("IS-136 / TDMA"), and Integrated Digital Expansion Network ("iDEN").

[0121] The mobile communication device 200 communicates with the cellular network 210 via one of the methods known to those skilled in the art, for example, via the Short Messaging Service ("SMS") or Multimedia Messaging Service ("MMS") protocol. The middleware software in the system hub 120 can communicate with the cellular network 210 in several ways. In one example, the telephone numbers and carriers of users 12, 112 (one or all of patient 12, patient's home care partner, or patient's clinician 112) are associated with a specific machine 90, for example, via a lookup table in the middleware software. When a message / code from a specific machine 90 is received by the middleware, the middleware software may be programmed to send an email to [user phone number]@[carrier].net. For example, if patient 001's telephone number is (555)555-5555 and patient 001's carrier is AT&T TM If so, when patient 001's machine 90 sends a message to middleware software on system hub 120, upon receipt, 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 there are several websites dedicated to informing people how to send emails as text messages and outlining the details required by different carriers.

[0122] The middleware software stores each of the telephone numbers of each mobile communication device 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 looks up the telephone number of the mobile communication device 200 associated with that machine, converts the code into an appropriate message using, for example, a lookup table as described above, and sends the converted message to the called telephone number. It is considered that multiple communication devices 200 may be associated with the same medical fluid delivery machine 90. For example, in any of the clinics 126a-126n, the telephone numbers of multiple doctors, nurses, and / or clinicians may be associated with the same machine 90. In a home setting, the telephone numbers of patient 12 and the patient's clinician and / or caregiver assistant may be associated with the same machine 90.

[0123] Similarly, a telephone number for a mobile communication device 200 may be associated with multiple medical fluid delivery machines 90. For example, in any of the clinics 126a-126n, a single nurse may monitor multiple machines 90. If an event occurs in any of those machines during the nurse's shift, the nurse may be notified via a cellular message sent to the nurse's mobile communication device 200. This scenario is described in detail below in relation to Figure 7-9.

[0124] Cellular messages can convey information about any of the same events discussed above to a software app and calendar update mode that feed information into the mobile communication device 200. For example, a medical fluid delivery machine 90 may have just completed its automated self-test routine and is now ready to perform a disinfection procedure. The machine 90 may generate a code that identifies this state and send it to middleware software stored on the system hub 120. The middleware software then, for example using a lookup table, converts the code into a message such as "Self-test complete, ready to disinfect," and causes a cellular output routine, for example, discussed above, to send a text message to the mobile communication device 200 of the patient 12 or clinician 112, causing the message to be displayed. In an alternative embodiment, the code is not required, and the machine 90 instead sends an actual text string, which the middleware software then forwards to the mobile communication device 200 as a text message via a cellular output routine, for example, discussed above. As is well known, the reception of a text message on the communication device 200 may be accompanied by an audio alert, such as a “ring” sound and / or a tactile alert such as a vibration, prompting the patient 12 or clinician 112 to view the message.

[0125] In another example, the medical fluid delivery machine 90 may be pre-programmed to begin treatment at 3:00 p.m. The medical fluid delivery machine 90 may again require 3 hours for self-testing and disinfection. The patient 12 or clinician 112 therefore needs to be near the machine 90 by noon to begin the pre-treatment. In one embodiment, the patient 12 or clinician 112 makes a setting with the machine 90 regarding how far in advance (e.g., 2 hours) the patient 12 or clinician 112 should be notified or alerted. Here, the machine 90 generates a code at 10:00 a.m. and sends the 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 "Procedure preparations should begin in 2 hours," and causes, for example, the cellular output routine discussed above to send the text message to the patient 12 or clinician 112's mobile communication device 200, displaying the message along with an audio alert, such as a "ringing" sound, and / or a tactile alert, such as vibration, prompting the patient 12 or clinician 112 to view the notification.

[0126] It should be understood that the machine 90, middleware software in the central server 120, and communication device 200 may be programmed and operated as described above to provide any desired messages to the patient 12 and / or clinician 112, either as an alternative or in addition, using the cellular network 210. For example, the patient 12 and / or clinician 112 may also be informed that the procedure needs to be started within a countdown time to avoid the need to re-disinfect the machine 90 at the end of disinfection. It should also be understood that updates to specific task tracking features, such as the calendar application of the communication device 200, may be performed via an internet connection or via the cellular network 210 as illustrated in Figure 5.

[0127] Referring now to Figure 6, System 110c of the present disclosure is illustrated. In the illustrated embodiment, System 110c operates in conjunction with System 10 described above, which is illustrated in Figure 6 as part of a cloud environment, but alternatively includes a connectivity 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 may reside on one or more dedicated servers. Other components of System 10 not shown in Figure 6 may also be part of System 110a. A single medical fluid delivery machine 90 is illustrated for ease of illustration, however, multiple medical fluid delivery machines 90 may also be connected to System 110b. The medical fluid delivery machine 90 may be located in the home of a patient 12 (illustrated as being outside the home) or in clinics 126a-126n relating to a clinician 112. The medical fluid delivery machine 90, again in the illustrated embodiment, is connected to the connectivity server 118 via a securely managed connection 116 and an Internet connection 52, for example, using a modem 102. In Figure 6, the connectivity server 118 and the securely managed connection 116 are used for bidirectional communication.

[0128] In one embodiment, the system hub 120 stores middleware software that can be accessed by a mobile communication device 200 (shown as a single device for ease of use, but multiple devices 200 can also be connected to system 110b). The mobile communication device 200 in Figure 6 includes all the structures, functionalities, and alternatives disclosed with respect to devices 200a and 200b illustrated in Figure 4, including being connected to the Internet 52. In Figure 6, the mobile communication devices 200 may, though not required, download software applications ("apps") from the middleware software stored on the system hub 120 via their connection to the Internet 52. Apps may be operated as strictly described above in relation to Figure 4, which includes middleware software that converts coded messages from machine 90 into a format presentable on the app. Alternatively, or in addition, the middleware software stored on the system hub 120 may be capable of converting codes from machine 90 into messages that are embedded on the mobile communication device 200's specific task tracking features, such as its calendar application, in any of the methods described in Figure 4. The calendar application can, as an alternative, be updated via the cellular network 210 (illustrated as an alternative in Figure 6 via a dashed leader line), which is discussed above in relation to Figure 5.

[0129] Figure 6 illustrates that communication may be bidirectional between the medical fluid delivery machine 90 and the mobile communication device 210. Communication between the mobile communication device 210 and the middleware software in the server computer 120 may be via the internet 52 and / or the cellular network 210. Communication between middleware software in the server computer 120 may be via a connectivity server 118 via a securely managed connection 116, as described in detail above.

[0130] As discussed above, the home treatment machine 90 connects to the connectivity server 118 via its onboard connectivity agent 114, which, in one embodiment, is turned off during treatment (e.g., while the machine 90 and its peripherals are functioning) (it may or may not be turned off during post-treatment disinfection). This prevents the home treatment machine 90 from communicating with any entity and sending or receiving data during treatment and disinfection, or when the machine 90 is operating or started. It is considered that communication via systems 110a-110c is protected in the same manner. For example, suppose a particular machine 90 is configured via middleware software to communicate with both patient 12 and clinician 112. Here, it is assumed that when the patient is being treated by the machine 90, the connectivity agent 114 is shut off, thereby preventing the clinician 112 from receiving notifications from or sending commands to the machine 90 at that time. In an alternative embodiment, the clinician 112 may be able to receive notifications from the machine 90 during treatment.

[0131] Determining when to disconnect the connectivity agent 114 (when there is no communication) may depend on the content or number of machine states that systems 110a-110c wish to communicate with the mobile communication device 200. For example, suppose it is only desired to inform patient 12 or clinician 112 two hours before treatment preparation that they need to return to machine 90 to begin treatment preparation. Here, the connectivity agent 114 may be turned off as soon as patient 12 or clinician 112 begins the first treatment preparation step, for example, when performing a self-test routine.

[0132] In another example, it may be desirable for the machine 90 to automatically perform a self-test routine at a predetermined time before a procedure is set to begin. The machine 90 notifies the patient 12 or clinician 112 when it is time to begin disinfection. Here, the connectivity agent 114 may be disconnected when the patient 12 or clinician 112 begins machine disinfection. In a further example, it may be desirable for the machine 90 to notify the patient 12 when disinfection is complete, so that the patient begins a procedure within a certain amount of time after the completion of disinfection and disinfection does not need to be repeated. Here, the connectivity agent 114 may be disconnected when the patient 12 or clinician 112 begins a procedure, for example, in response to the start of a pre-infusion when the patient is not yet connected to a procedure line, for example, an arterial line 14 or a venous line 16.

[0133] System 110c enables a patient 12 or a clinician 112 to remotely initiate any of the above actions (and others not expressly described herein). The patient 12 or clinician 112 may, for example, select an icon on an app displayed on a mobile communication device 200 to initiate a self-test routine or disinfection procedure. The icon selection is transmitted to middleware software via the internet 52. The middleware software then converts the icon selection into an action code, for example, via a lookup table, which is sent to the machine 90, whose connectivity agent 114 is turned on, via the connectivity server 118 and a securely managed connection 116, enabling the action code relating to the selected action to be sent to the machine's ACPU 50, which then initiates the execution of the selected action.

[0134] In an alternative embodiment, patient 12 or clinician 112 may enter a known code in a text message to select a specific action to be performed in machine 90, for example, a self-test routine or a disinfection procedure. The code may be a suggestive code such as "self-test" or "disinfect." The text message is sent via the cellular network 210 to middleware software in 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 entered by patient 12 or clinician 112 may be an action code that does not require any conversion. In either case, the action code is sent via connectivity server 118 and securely managed connection 116 to machine 90 with its connectivity agent 114 turned on, enabling the action code for the selected action to be sent to the machine's ACPU 50, which then begins to perform the selected action.

[0135] Figure 6 illustrates the following exemplary seven-step sequence. In step 1, the medical fluid delivery machine 90 sends a message to a middleware software application in the system hub 120 indicating that the machine is ready to initiate the machine 90's automated self-test routine, for example, a two-hour routine. In step 2, the middleware software application in the system hub 120 sends a corresponding (e.g., translated) message to the patient's mobile communication device 200 indicating that the machine 90 is ready to initiate the patient's automated self-test routine.

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

[0137] In step 5, the patient's mobile communication device 200 sends a message to the middleware software application in the system hub 120 confirming that the patient's machine 90 wishes to start its automated self-test routine. In step 6, the middleware software application in the system hub 120 sends a message to the machine 90 indicating that the patient 12 has confirmed that the machine 90 should start its automated self-test routine (e.g., convert and send). In step 7, the machine 90 starts and performs its automated self-test routine.

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

[0139] With respect to systems 110a-110c, it is considered that the app on the mobile communication device 200 is programmed to be configurable by the user to select the types of notifications that the user wishes to receive on those devices 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, and the mobile communication device 200 ignores communication types that the user has disabled. In another embodiment, the system hub 120 remembers the user's preferences and sends only information in the selected notification types.

[0140] Referring here to Figure 7-9, one embodiment of a system 110d having a clinician-based downloadable software application ("App") 230 for a mobile communication device 200 of a physician, clinician, or nurse is illustrated on screens 232-236. As discussed above, the mobile communication device 200 may belong to a patient 12 or to a physician / nurse / clinician 112. Screens 232-236 of Figure 7-9 illustrate that the App 230 may be used, for example, in a clinic or hospital 126a-126n in which a nurse is involved with multiple machines 90a-90n. The machines 90a-90n may again be hemodialysis machines, peritoneal dialysis machines, CRRT machines, drug and / or nutritional fluid delivery machines, and combinations thereof.

[0141] Screen 232 illustrates that the app 230 can monitor and, if desired, control multiple machines 90. In the illustrated embodiment, machines 90a-90n are each represented by dedicated icons 190a-190n displayed on screen 232 of the app 230. The icons 190a-190n in the illustrated embodiment are ordered on screens 232-236 in the same order as the machines 90a-90n are ordered within the clinic 126a-126c, to help physicians / nurses / clinicians 112 adapt.

[0142] App 230 operates with the system hub 120 as discussed herein, the system hub 120 is assumed to be remote from a clinic or hospital 126a-126n and maintained, for example, by the manufacturer of one or more of the machines 90a-90n. App 230 may first be developed, for example, in a product development 128 as illustrated in Figure 1. App 230 may then be sent from the product development 128 to the system hub 120 via a service portal 130 as illustrated in Figures 1 and 7. Any nurse, clinician, or physician 112 authorized to download App 230 may do so from the system hub 120. The system hub 120 then maintains middleware software to operate with App 230 in the systems 110a-110c in the manner described above.

[0143] In an alternative embodiment, clinics 126a-126n may each maintain their own local area network, each operating with the local system hub 220. App 230 may again be developed by product development 128 (Figure 1) and delivered via the service portal 130 to the local system hub 220 of clinics 126a-126n, which operate with the entire 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 App 230 in the manner described above with respect to the system hub 120 in systems 110a-110c. In a further alternative embodiment, App 230 may be developed by clinic 126a-126n and stored on its local system hub 220.

[0144] The middleware software of the system hub 120 or local system hub 220 updates the status of each machine 90a-90n. A nurse, clinician, or physician 112 may select icons 190a-190n at any time to check the current status of each machine 90a-90n, for example, “Rest,” “Self-testing,” “Disinfection,” or “Patient Treatment,” as illustrated in screen 234 of Figure 8. Other status markers may be considered and may differ for different types of machines. The nurse, clinician, or physician 112 may then select any of “Rest,” “Self-testing,” “Disinfection,” or “Patient Treatment” to return to the home icon 190a-190n, as illustrated in Figure 9.

[0145] As discussed above, when the machines are running, especially when patient 12 is connected to a machine, it is considered to turn off the connectivity agent 114 of each machine 90. However, it is also considered to allow the connectivity agent 114 of each machine 90a-90n in clinics 126a-126n to remain on until disinfection is complete, so that middleware software in system hub 120 or local system hub 220 can receive status changes to “Patient Treatment” from each machine 90a-90n. In addition, since each machine 90a-90n is aware of its scheduled treatment period, the machine may also send the scheduled duration to the middleware software, which then sends the duration in the form of a countdown timer along with a status change to “Patient Treatment”. Here, when a nurse, clinician, or physician 112 selects “Patient Treatment” in Figure 8, they can see a countdown timer showing the remaining treatment time as illustrated in Figure 9.

[0146] It is considered that the connectivity agent 114 enables machines 90a-90n to send remaining time data to the system hub 120 so that the app 230 can display the actual remaining time for each machine 90 that is undergoing a timed process for the countdown timer. The app 230 takes into account alarms or other delays that machine 90 may experience. During an alarm situation, the corresponding icons 190a-190f may display a message such as “Alarm” or “Safe Mode”. A nurse, clinician, or physician 112 may then select the countdown time in Figure 9 to return to the home icons 190c, 190d, and 190h illustrated in Figure 7.

[0147] A nurse, clinician, or physician 112 may toggle the alert on / off icon 238 to either enable or disable status changes for machines 90a-90n to be alerted visually, audibly, and / or tactilely. When the alert on / off icon 238 is switched to "on", the app 230 on the mobile communication device 200 will provide visual, audible, and / or tactile alerts whenever the status of the machine changes, for example, (i) whenever self-testing is initiated, (ii) whenever self-testing is completed, (iii) whenever disinfection is initiated, (iii) whenever disinfection is completed, (v) whenever a procedure is initiated, and (vi) whenever a procedure is completed. In one embodiment, codes relating to (i)-(v) are transmitted via machines 90a-90n through securely managed connections 116, connectivity servers 118, and system hubs 120 or local system hubs 220, translated by middleware software, and forwarded to app 230, which updates the appropriate icons 190. In various embodiments, "(vi) action completed" can be inferred when (a) a connection agent 114 is activated and transmitted via machines 90a-90n, or (b) a countdown timer for the appropriate icons 190a-190n has finished and the connectivity agent 114 may still be off.

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

[0149] Screens 232–236 illustrate the action buttons 240a–240b (collectively referred to herein as action buttons 240, or generally, individually). Any number of action buttons 240 may be provided for any modality, e.g., hemodialysis, peritoneal dialysis, CRRT, drug and / or nutritional fluid delivery, or any type of pre-treatment action required for such modality. In the illustrated embodiment, action button 240a is for initiating a self-test for machine 90, while action button 240b is for initiating a disinfection sequence for machine 90.

[0150] In one embodiment, when the self-test button 240a is selected, any machines 90a-90n capable of performing a self-test at that time have their corresponding icons 190a-190n highlighted. The nurse, clinician, or physician 112 selects one of the icons 190 for the machine 90 for which the nurse, clinician, or physician 112 wishes to perform a self-test. The selected icon 190 may then transform into a “confirm” button that the nurse, clinician, or physician 112 must press again to have the selected machine 90 perform its self-test. The app 230 on the mobile communication device 200 then sends the corresponding self-test code to middleware software on the system hub 120 or local system hub 220, the middleware software converts the self-test code into a self-test start command if necessary, which is sent to the connectivity agent 114 of the selected machine 90 via a connection 116 securely managed through the connectivity server 118, the connectivity agent 114 forwards the command to the machine's ACPU 50, the ACPU 50 then starts the self-test.

[0151] In the illustrated embodiment, when the disinfection button 240b is selected, any machines 90a-90n capable of performing disinfection at that time are highlighted with their corresponding icons 190a-190n. The nurse, clinician, or physician 112 selects one of the icons 190 for the machine 90 for which the nurse, clinician, or physician 112 wishes to perform disinfection. The selected icon 190 may then change into a “confirm” button, which the nurse, clinician, or physician 112 must press again to have the selected machine 90 perform the disinfection. The app 230 on the mobile communication device 200 then sends the corresponding disinfection code to middleware software on the system hub 120 or local system hub 220, the middleware software converts the disinfection code into a disinfection start command if necessary, which is sent to the connectivity agent 114 of the selected machine 90 via a connection 116 securely managed through the connectivity server 118, the connectivity agent 114 forwards the command to the machine's ACPU 50, the ACPU 50 then starts disinfection.

[0152] The procedure thus described for the action button 240 is also implemented in system 110c and may be implemented for other machine commands which may vary depending on the type of machine 90. It should also be considered that a clinic 126a may determine that it is sufficiently safe to leave the connectivity agent 114 on during a procedure or part of a procedure by one or more nurses, clinicians, or physicians 112 present in the clinic. In such a case, the nurses, clinicians, or physicians 112 may control the in-procedure activities for the machine 90. For example, the nurses, clinicians, or physicians 112 may receive and respond to alarms / alerts via the app 230 on the mobile connectivity device 200, such as starting and stopping the pump and other aspects of the procedure, starting and stopping disinfection, starting and stopping pre-infusion, etc.

[0153] Each of systems 110a-110d operates with a certain form of addressing. As discussed above, the connectivity server 118 is provided in one embodiment to ensure that data is delivered in the appropriate form to the appropriate machine 90 and that data from the machine 90 is delivered in that appropriate form to the appropriate destination. In one embodiment, when machine 90 sends data to the system hub 120 or local system hub 220 for delivery to a mobile communication device 200, the data is then provided with a machine identifier that identifies the machine 90 from which the data was sent. The connectivity server 118 keeps track of each mobile communication device 200 to which data of a particular machine belongs and instructs the system hub 120 or local system hub 220 which communication device 200 should receive the data. The system hub 120 or local system hub 220 may then transform the data as discussed herein. For example, when sending the transformed data, the system hub 120 or local system hub 220 may remove the machine identifier from the data, as it is no longer needed. However, in system 110d, the machine identifier may be delivered, for example, along with the converted data, so that app 230 knows which icons 190a-190n should be populated with new data. Here, app 230 can remove the machine identifier when it is no longer needed.

[0154] In one embodiment, when a mobile communication device 200 transmits data to a system hub 120 or local system hub 220 for delivery to a machine 90, the data is provided with a mobile communication device 200 identifier that identifies the mobile communication device 200 from which the data was transmitted. The system hub 120 or local system hub 220 may or may not convert the data from the mobile communication device 200, as discussed above, but in either case, the mobile communication device 200 identifier is maintained for the connectivity server 118. The connectivity server 118 keeps track of which machine 90 will receive the converted data for each mobile communication device 200, for example, and transmits the converted data to each associated communication device 200. The connectivity server 118 may remove the mobile communication device 200 identifier from the data once it has been delivered to the machine 90, as it is no longer needed.

[0155] The app 230 described above allows a nurse, clinician, or physician 112 to set up, monitor, and possibly control a procedure in the medical fluid delivery machine 90. It is considered to provide similar functionality via the app to a patient 12 or a caregiver for patient 12 at the patient's home (dashed box in Figure 1). The connectivity may be identical to that shown in Figures 7-9. However, the setting is not a clinic 126a-126n, but instead a home or other non-clinical location such as a business or vacation location. In addition, typically only a single machine 90 exists, rather than multiple machines 90a-90n. However, it is possible that a single patient 12 could be treated via multiple machines 90, each of which may be supported by an app as described herein. If patient 12 is at home but away from the machine 90, the app may provide useful information such as the amount of time remaining to start or complete startup procedure tasks, disinfection procedures, or self-test routines. When a patient is being treated by the machine 90, the patient can view information on its user interface 122, which may itself be a tablet as illustrated in Figure 1. However, there may also be a caregiver assisting the patient 12 at home during the treatment, such as a spouse, friend, or home nurse. The caregiver benefits from the home app by receiving information such as status updates, remaining time for the start-up procedure, remaining time for disinfection, remaining time for pre-infusion, remaining treatment time, whether the patient 12 is connected to the machine 90, alerts, alarms, etc. In one embodiment, the app requires the patient to enter a login and password associated with the patient before it can be downloaded to the caregiver's mobile communication device 200, so that only authorized persons can view the patient treatment data.

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

Claims

1. A medical fluid delivery device, wherein the medical fluid delivery device is A blood circuit including a blood filter and a blood pump, A dialysis fluid circuit, the dialysis fluid circuit being fluidically coupled to the hemofilter, and including at least one dialysis fluid pump, Processor and Memory for storing instructions and Equipped with, When the aforementioned instruction is executed by the processor, Receiving disinfection input to initiate the disinfection procedure, The blood pump and the at least one dialysis fluid pump are to be used to perform the disinfection procedure on the blood circuit and the dialysis fluid circuit using a disinfectant fluid. After the aforementioned disinfection procedure is completed, the disinfection timer is started. To enable the dialysis procedure to be performed when a dialysis input is received before the disinfection timer reaches zero, If the disinfection timer reaches zero before the dialysis input is received, the dialysis procedure will not be performed until the disinfection procedure is performed again. A medical fluid delivery device that causes the processor to perform the above-mentioned task.

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

3. The medical fluid delivery device according to claim 2, wherein the disinfection input is received after the processor transmits a message to the mobile communication device via the network, and the message indicates (i) that the disinfection procedure is ready to be performed, or (ii) that there is time to perform the disinfection procedure.

4. The processor is Information indicating the aforementioned disinfection timer, or Information indicating that the aforementioned disinfection procedure has been completed. The medical fluid delivery device according to claim 2, further configured to transmit at least one of the above to the mobile communication device.

5. The medical fluid delivery device according to claim 2, further comprising a connectivity agent communicatively coupled to the processor, wherein the connectivity agent is configured to prevent the processor from communicating with the mobile communication device during the disinfection procedure.

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

7. The medical fluid delivery device according to claim 6, wherein the blood circuit further comprises 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 dialysis fluid circuit is disposable.

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

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

11. The medical fluid delivery device further comprises a graphical user interface which is communicably coupled to the processor, The medical fluid delivery device according to claim 1, wherein the processor is configured to display information indicating the disinfection timer on the graphical user interface.

12. A medical fluid delivery device, wherein the medical fluid delivery device is A dialysis fluid circuit including at least one dialysis fluid pump, Processor and Memory for storing instructions and Equipped with, When the aforementioned instruction is executed by the processor, Receiving disinfection input to initiate the disinfection procedure, The at least one dialysis fluid pump is to perform the disinfection procedure on the dialysis fluid circuit using a disinfectant fluid, After the aforementioned disinfection procedure is completed, the disinfection timer is started. To enable the dialysis procedure to be performed when a dialysis input is received before the disinfection timer reaches zero, If the disinfection timer reaches zero before the dialysis input is received, the dialysis procedure will not be performed until the disinfection procedure is performed again. A medical fluid delivery device that causes the processor to perform the above-mentioned task.

13. The processor is Before receiving the disinfection input, (i) the disinfection procedure is ready to be performed, or (ii) the time to perform the disinfection procedure is determined. (i) or (ii) is transmitted to a mobile communication device. A medical fluid delivery device according to claim 12, further configured to perform the following:

14. The processor is connected to a server so as to be able to communicate via a network, The medical fluid delivery device according to claim 13, wherein the processor transmits the information indicating (i) or (ii) to the mobile communication device via the server and the network, and receives the disinfection input via the server and the network.

15. The processor is Information indicating the aforementioned disinfection timer, or Information indicating that the aforementioned disinfection procedure has been completed. The medical fluid delivery device according to claim 13, further configured to transmit at least one of the above to the mobile communication device.

16. The medical fluid delivery device according to claim 13, further comprising a connectivity agent communicatively coupled to the processor, wherein the connectivity agent is configured to prevent the processor from communicating with the mobile communication device during the disinfection procedure.

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 a Short Message Service ("SMS") or Multimedia Message Service ("MMS") protocol.

19. The medical fluid delivery device further comprises a graphical user interface which is communicably coupled to the processor, The medical fluid delivery device according to claim 12, wherein the processor is configured to display information indicating the disinfection timer on the graphical user interface.

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

Images