Medical fluid delivery system comprising mobile platform for patient participation and treatment compliance

Abstract

The invention relates to a medical fluid delivery system comprising a mobile platform for patient participation and treatment compliance. A patient platform for patient participation and treatment compliance is disclosed. In an example, a processor is configured to obtain medical information from a patient for participation and treatment compliance tracking. In order to obtain medical information, the processor causes a user interface to display a field in which the medical information is to be filled. Upon receiving a selection of the data field, the processor provides an option to input medical information from the image. If the option is selected, the processor receives a recorded image of the medical device or a screen of the medical device, extracts text from the image, enables selection of at least a portion of the text from the image, and writes the selected text from the image into a data field of the user interface as medical information. The processor transmits the medical information to a patient medical record stored in a clinician database.

Description

[0001] This application is a divisional application, and the original application it is targeting is an invention patent application whose applicants are "Baxter International Corporation" and "Baxter Healthcare Co., Ltd.", the application date is September 5, 2019, the invention name is "Medical fluid delivery system including a mobile platform for patient engagement and treatment compliance", and the application number is 201980057821.X. Technical Field

[0002] The present invention relates to a medical fluid delivery system including a mobile platform for patient engagement and treatment compliance. Background Art

[0003] Currently, it is almost impossible to have prolonged contact with patients outside of a medical setting. Many patients typically start out relatively fit, similar to starting a gym membership or purchasing a treadmill. For example, initially, patients are receptive to medical treatments that are self-administered in the patient's home (such as medical fluid delivery therapy). In order to receive treatment, the patient must connect themselves to a medical fluid delivery machine (or a container of renal failure treatment fluid) to clear the toxin buildup in the blood. Part of the treatment may include tasks that the patient must perform, such as weighing themselves, measuring their own blood pressure, and / or recording information related to their own treatment. The information recorded by the patient is typically reviewed by a clinician to ensure that the treatment is being administered as prescribed. Clinicians also review the recorded data to determine if adjustments to the treatment are needed.

[0004] Over time, many patients become less enthusiastic about treatment as it loses its novelty and becomes just another obligation. As one might imagine, patients would rather engage in more exciting, relaxing, or stimulating activities than self-administered medical care. As patients continue in treatment, they sometimes begin to omit performing other tasks associated with treatment. Omitting other tasks and becoming less enthusiastic about treatment can create gaps in the clinical supervision of ongoing treatment. As patients further disengage from treatment, they may begin to skip treatments or abandon treatment altogether, risking their health in the process. Summary of the invention

[0005] Technical issues

[0006] Disclosed herein is a medical fluid data transmission system including a mobile platform. The medical fluid data transmission system is configured to improve engagement and / or treatment compliance with a patient through interactions provided by the patient's portable device (e.g., a cellular phone, a smart phone, a tablet computer, etc.). Specifically, the medical fluid data transmission system provides the patient with enhanced feedback and control (without feeling overwhelmed), which makes the patient feel as if he or she is in control of his or her own treatment rather than following the instructions of a clinician. For example, a personal mobile communication device of the medical fluid data transmission system can display treatment information and / or the patient's vital sign data. The personal mobile communication device can also enable the patient to switch between different prescribed treatments or programs without having to directly program the medical fluid delivery machine. Patients who feel in control are more likely to continue with treatment.

[0007] The example medical fluid data transmission system also reduces the data collection burden on patients by automating the process. For example, a personal mobile communication device enables a patient to capture treatment data or vital sign data for automatic transmission to a centralized clinician database. The patient can enter the data directly into the personal mobile communication device, receive the data electronically from a connected machine, or record the data using a camera. The data is transmitted within the medical fluid data transmission system to a database that stores the data in the patient's medical record.

[0008] In addition, the example medical fluid data transmission system provides a gateway to the clinician to enable the patient to communicate with the clinician in real time regarding any concerns or issues related to the medical fluid delivery therapy. In some embodiments, the medical fluid data transmission system also provides the patient with access to educational or training materials. In this way, the example medical fluid data transmission system is configured to connect the patient to the assistance needed or requested to maintain participation and / or compliance with the therapy.

[0009] The medical fluid data transmission systems and methodologies disclosed herein can be applied to fluid delivery in, for example, plasmapheresis, hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), and continuous renal replacement therapy ("CRRT") treatments. The medical fluid data transmission systems described herein are also applicable to peritoneal dialysis ("PD"), intravenous drug delivery, and nutrient solution delivery. These modalities may be collectively or generally individually referred to herein as medical fluid delivery or treatment.

[0010] The above-mentioned manner can be provided by a medical fluid delivery machine, which contains the components required for delivering medical fluids, such as one or more pumps, valves, heaters (if necessary), online medical fluid generation devices (if necessary), sensors (such as one or more or all of pressure sensors, conductivity sensors, temperature sensors, air detectors, blood leak detectors, etc.), user interfaces and control units, which can use one or more processors and memories to control the above-mentioned devices. The medical fluid delivery machine can also include one or more filters, such as a dialyzer or blood filter for cleaning blood and / or an ultrafilter for purifying water, dialysate or other fluids.

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

[0012] As described in detail below, the medical fluid data transmission system and method of the present disclosure can operate within an encompassing platform system that includes multiple machines, including many different types of equipment, patients, clinicians, doctors, service personnel, electronic medical record ("EMR") databases, websites, resource planning systems that process data generated via patient and clinician communications, and business intelligence. The medical fluid data transmission system and method of the present disclosure operates seamlessly within the entire system and does not violate its rules and protocols.

[0013] Technical Solution

[0014] In view of the disclosure herein and without limiting the disclosure in any way, in a first aspect of the disclosure, unless otherwise specified, it can be combined with any other aspects listed herein, a machine-accessible device having instructions stored on the device, the instructions being configured to, when executed, cause the machine to fill in a patient medical record of a clinical system by: operating a camera to record an image; operating a display interface; operating a connection interface configured to connect to a clinician database, the clinician database being configured to store patient medical records; and operating a processor to obtain medical information. The processor is operated to obtain medical information by: displaying a user interface via the display interface, the user interface having a field to be filled with medical information, and after selecting a data field of the user interface, graphically providing a first option of entering medical information from an image and a second option of entering medical information via text entry via the display interface. If the first option is selected, the processor receives a recorded image from the camera, the recorded image including a medical device or a screen of a medical device, extracts text from the image, enables at least a portion of the text from the image to be selected via the display interface, and writes the text selected from the image as the medical information into the data field of the user interface. If the second option is selected, the processor enables text entry of the data field as medical information via the display interface. The processor is also operated to obtain medical information by transmitting the medical information written to the data field to the patient's medical record stored in the clinician database after receiving a send instruction.

[0015] According to a second aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, and the machine-accessible device further includes instructions stored on the device, which are configured to, when executed, cause the machine to operate the processor to: determine a data template for text extracted from the image; process the extracted text using the data template to group the extracted text into fields; and enable selection of at least one of the fields to write the text selected from the image into the data field of the user interface.

[0016] According to a third aspect of the present disclosure, which may be used in combination with any other aspect listed herein unless otherwise stated, the data template is configured to specify a context for the extracted text in relation to a text location within the image.

[0017] According to a fourth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, the machine-accessible device further includes instructions stored on the device, which are configured to, when executed, cause the machine to operate the processor to determine the data template based on at least one of the following: (i) the type of medical device selected via the user interface, (ii) information scanned from an identifier located on the medical device, and (iii) tags within the extracted text, or (iv) the relative layout of the extracted text.

[0018] According to the fifth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, and the identifier located on the medical device includes at least one of the following: a quick response ("QR") code, a bar code, a serial number or a hardware number located on the housing of the medical device or on the screen of the medical device.

[0019] According to the sixth aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspects listed herein, and the medical device includes at least a renal failure treatment machine, an infusion pump, an oxygen sensor, a respiratory monitor, a blood glucose meter, a blood pressure monitor, an ECG monitor, a weight scale and a heart rate monitor.

[0020] According to the seventh aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, and the data field of the user interface is configured to receive at least one of the following data: blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, subjective data, or consumption data regarding consumables.

[0021] According to the eighth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, and the consumables include at least one of the following: a filter, a blood line set, a dialysate concentrate container, a blood anticoagulant container, a drug container, a disposable box, an adsorbent box and a clean water container.

[0022] According to a ninth aspect of the present disclosure, which may be used in combination with any other aspects listed herein unless otherwise stated, the machine is a personal mobile communication device.

[0023] According to the tenth aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, a method for filling in a patient medical record of a clinical database using a recorded image, comprising: transmitting a first message to a personal device, the first message prompting the patient to use the camera of the personal device to record a first image of a medical device; and receiving the first image from the personal device. The method includes determining, via a processor, first medical information indicating the type or model of the medical device from the first image; determining, via the processor, a data template and a second message associated with the determined type or model of the medical device; and transmitting, via the processor, the second message to the personal device, prompting the patient to use the camera to record a second image of the screen of the medical device. The method further includes receiving the second image from the personal device via the processor; extracting text from the second image via the processor; and processing the extracted text using the data template via the processor to group the extracted text into fields. The method further includes writing at least some of the text in at least one field to the patient medical record via the processor.

[0024] According to the eleventh aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, and the method further includes: determining, via the processor, a correspondence between one of the fields and a record field in the patient medical record; and writing, via the processor, at least some text from the field into the record field in the patient medical record.

[0025] According to the twelfth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, and the method further includes: determining the treatment time from the patient medical record via the processor; and transmitting the first message via the processor before the treatment time.

[0026] According to the thirteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, and the method further includes: in the processor, receiving a treatment message from the personal device indicating that the patient will start treatment; and before starting the treatment, transmitting the first message via the processor.

[0027] According to the fourteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, receiving the first image in the processor via a first text message or a first short message service ("SMS") message, and receiving the second image in the processor via a second text message or a second SMS message.

[0028] According to a fifteenth aspect of the present disclosure, which may be used in combination with any other aspect listed herein unless otherwise stated, the method further includes converting at least some text from at least one field into a Health-Level-7 ("HL7") format via the processor before writing the patient medical record.

[0029] According to the sixteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, and the method further includes: comparing at least some text from at least one field with a predetermined range via the processor; and if at least some text from at least one field is within the predetermined range, writing at least some text from the at least one field via the processor.

[0030] According to the seventeenth aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, a system for transmitting information to a patient, comprising: a home treatment device of the patient, the home treatment device being configured to transmit treatment information; and a clinician database, the clinician database being configured to store medical records and registration files, the registration files identifying the home treatment device and the patient's personal device as registered devices, and identifying whether the personal device has installed an application for viewing the treatment information and the medical information. The system also includes a clinician server, the clinician server being communicatively coupled to the clinician database, the home treatment device, and the personal device. The clinician server is configured to: store the treatment information and the medical information in the medical record; receive an indication that at least some of the treatment information and the medical information will be displayed on the personal device; and determine from the registration file whether the application is installed on the personal device. If the application is installed, the clinician server is configured to convert at least some of the treatment information and the medical information into an application format for display within the application, and to send at least some of the converted treatment information and medical information to the personal device. If the application is not installed, the clinician server is configured to convert at least some of the treatment information and the medical information into a text message or short message service ("SMS") format, and to send at least some of the converted treatment information and medical information to the personal device via one or more text messages or SMS messages.

[0031] According to an eighteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspects listed herein, and the application format includes at least one of an extensible markup language ("XML") format or a hypertext markup language ("HTML") format.

[0032] According to the nineteenth aspect of the present disclosure, unless otherwise stated, it can be used in combination with any other aspect listed herein, and at least some of the treatment information and instructions in the medical information will be displayed on the personal device, including at least one of a message from the application or a text / SMS message from the personal device.

[0033] According to a twentieth aspect of the present disclosure, which may be used in combination with any other aspect listed herein unless otherwise stated, the registration file is included in the medical record.

[0034] According to the twenty-first aspect of the present disclosure, unless otherwise specified, it can be used in combination with any other aspect listed herein, the home therapy device is configured to store a prescription having two programs, each program providing parameters for operating the home therapy device to perform treatment, and the clinician server is configured to: receive a program message indicating a change from a first program to a second program from the personal device; and send a program instruction to the home therapy device to change from the first program to the second program.

[0035] In the twenty-second aspect of the present disclosure, in combination Figures 1 to 33 Any of the disclosed structures and functions may be combined with Figures 1 to 33 Any other combination of structures and functions disclosed.

[0036] Beneficial Effects

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

[0038] Another advantage of the present disclosure is to provide an improved patient lifestyle.

[0039] Another advantage of the present disclosure is to provide improved clinician or caregiver efficiency.

[0040] Another advantage of the present disclosure is to provide improved machine efficiency.

[0041] Yet another advantage of the present disclosure is to provide improved patient compliance.

[0042] Another advantage of the present disclosure is to provide a medical fluid data transmission system and method that can be applied to different types of medical fluid delivery machines.

[0043] Yet another advantage of the present disclosure is to provide a medical fluid data transmission system and method that enables communication between a medical fluid delivery machine and multiple persons, such as a patient and a clinician or a patient and a primary caregiver.

[0044] Additionally, an advantage of the present disclosure is the reduction of waste of disposable kits and other ancillary soft goods due to discarding that typically occurs when a machine timer expires.

[0045] The advantages discussed herein may be found in one or some, but perhaps not all, of the embodiments disclosed herein.Additional features and advantages are described herein and will be apparent from the following detailed description and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0046] Figure 1 is a schematic diagram showing an embodiment of a medical fluid data transmission system according to an embodiment of the present disclosure, which system is combined with the medical fluid delivery machine of the present disclosure so that data can be transmitted between these machines.

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

[0048] Figure 3 The present invention is a diagram showing an embodiment of the present invention. Figure 2 A perspective view of a blood kit for use with one embodiment of a medical fluid delivery machine.

[0049] Figure 4 Schematic diagram of an embodiment of a medical fluid delivery machine and a data transmission system and method disclosed herein.

[0050] Figure 5 Schematic diagram of a second embodiment of a medical fluid delivery machine and a data transmission system and method disclosed in the present invention.

[0051] Figure 6 Schematic diagram of a third embodiment of a medical fluid delivery machine and a data transmission system and method according to the present disclosure.

[0052] Figure 7 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device and data transmission system and method of the present invention with a mobile communication device applied in a first state.

[0053] Figure 8 is a schematic diagram of one embodiment of a hospital or clinical version of the medical fluid delivery device and data transmission system and method of the present invention with a mobile communication device application in a second state.

[0054] Fig. 9 is a schematic diagram of one embodiment of a hospital or clinical version of the disclosed medical fluid delivery device and data transmission system and method with a mobile communication device application in a third state.

[0055] Fig.10A second embodiment of a medical fluid data transfer system is shown.

[0056] Fig.11 The present invention is described in detail according to an embodiment of the present invention. Fig.10 Diagram of the operational modules of an application at a clinician server of a medical fluid data transmission system.

[0057] Fig.12 An exemplary embodiment according to the present disclosure is shown. Fig.10 and 11 Diagram of the communication between a home therapy device, a personal mobile communication device, and a clinician server.

[0058] Fig.13 The storage device according to an exemplary embodiment of the present disclosure is shown. Fig.10 Example patient data structure on a clinician database of a medical fluid data transmission system.

[0059] Fig.14 and 15 An example embodiment according to the present disclosure is shown. Fig.11 A diagram of the user interface of an application.

[0060] Fig.16 According to an exemplary embodiment of the present disclosure Fig.10 and 11 Schematic diagram of a personal mobile communications device.

[0061] Fig.17 A schematic diagram illustrating a data template according to an example embodiment of the present disclosure.

[0062] Fig.18 An example embodiment according to the present disclosure is shown. Fig.14 A diagram of the written data fields of the user interface.

[0063] Fig.19 According to an exemplary embodiment of the present disclosure, Fig.10 and 11 A flowchart of an example process for inputting medical information from images using a personal mobile communication device.

[0064] Fig. 20 It is shown that according to an example embodiment of the present disclosure, Fig.10 and 11 An example of a user interface displayed by an application on a personal mobile communication device to enable a patient to provide an image for recording.

[0065] Fig.21 An example embodiment according to the present disclosure is shown. Fig.10 and 11Schematic diagram of a patient medical template that a clinician server uses to populate the data fields of a patient's medical record.

[0066] Fig. 22 According to an exemplary embodiment of the present disclosure Fig.11 Schematic diagram of the data acquisition module of the clinician server.

[0067] Fig.23 and 24 According to an exemplary embodiment of the present disclosure, using Fig.10 and 11 images recorded by a personal mobile communications device (and / or from Fig.10 and 11 to fill in the form of text messages received on a personal mobile communication device Fig.21 A flowchart of an example process for creating a medical device template.

[0068] Fig.25 An example embodiment according to the present disclosure is shown. Fig.10 and 11 Image of a personal mobile communications device, a diagram of a clinician's server hosting a website or file transfer site to receive medical information.

[0069] Figure 26 to Figure 29 An example embodiment according to the present disclosure is shown. Fig.10 and 11 Diagram of a personal mobile communication device providing medical information to a clinician server.

[0070] Fig.30 The example embodiment according to the present disclosure shows a method for prompting a patient to enter medical information. Fig.10 and 11 Figure 1. Illustration of a personal mobile communications device.

[0071] Fig.31 A method of providing a patient with a procedure for medical treatment is shown according to an exemplary embodiment of the present disclosure. Fig.10 and 11 Figure 1. Illustration of a personal mobile communications device.

[0072] Fig.32 A method of providing educational content to a patient according to an exemplary embodiment of the present disclosure is shown. Fig.10 and 11 Figure 1. Illustration of a personal mobile communications device.

[0073] Fig.33 An example embodiment of the present disclosure provides a method for providing a video chat session between a patient and a clinician. Fig.10 and 11 Figure 1. Illustration of a personal mobile communications device. DETAILED DESCRIPTION

[0074] Medical fluid delivery systems are disclosed herein. Example medical fluid delivery systems are configured to improve patient engagement in medical treatments such as medical fluid delivery treatments. The medical fluid delivery systems are configured to provide patients with more transparency about their treatments and at least some control to guide their treatments, while providing resources to educate or otherwise assist patients throughout the treatment process. Example medical fluid delivery systems are configured to provide patient engagement regardless of the type or feature set of the medical device associated with the patient's treatment or personal mobile communication device. Such a configuration makes the disclosed medical fluid delivery system compatible with virtually any patient condition.

[0075] In some embodiments, a medical fluid delivery system includes a personal mobile communication device, a medical fluid delivery machine, and a clinician server / database. The example personal mobile communication device and medical fluid delivery machine are located at a patient's home and / or in a self-service medical facility. The clinician server is communicatively coupled to the personal mobile communication device and / or the medical fluid delivery machine via a wide area network (i.e., the Internet). The clinician server is configured as a hub that enables the personal mobile communication device to provide functionality designed for a patient to participate in a medical fluid delivery treatment.

[0076] As disclosed herein, an example clinician server receives medical fluid delivery data (e.g., treatment information) from a medical fluid delivery machine, which is stored in one or more patient records in a clinician database. The clinician server provides access to the medical fluid delivery data to a personal mobile communication device so that the patient can track the progress of the treatment. In addition, the patient can use the personal mobile communication device to change the treatment program (or request a change in the treatment program). The request is sent by the clinician server to verify that the change is appropriate before being transmitted to the medical fluid delivery machine.

[0077] An example clinician server operates in conjunction with a personal mobile communication device to enable a patient to effortlessly provide medical information, such as vital sign data, medical device data, etc. The personal mobile communication device is configured to enable the patient to manually enter data, record a picture including the data, and / or wirelessly receive data from a connected medical device (such as a weight scale, a blood pressure monitor, a thermometer, a blood glucose meter, etc.). The collected data is stored in the patient's medical record. In some embodiments, the clinician server and / or the personal mobile communication device can use a template to determine how to automatically fill in the patient's medical record with the received data.

[0078] As disclosed herein, a personal mobile communication device may include a feature-rich smart device, such as a smartphone or tablet computer. The smart device may operate a dedicated application (e.g., an "app") defined by instructions stored in a memory. Execution of the stored instructions causes the smart device to run a process for the application, which is configured to increase the patient's involvement in medical care. In some cases, the personal mobile communication device may include a traditional cellular phone with reduced functionality that contains significantly less processing power and functionality than the smart device. The cellular device may operate using text messaging and / or a dedicated application (e.g., an App) defined by instructions stored in a memory. Applications for the reduced functionality device may have fewer features than applications for the smart device.

[0079] The following disclosure is divided into two parts. The first part discloses embodiments of a medical fluid delivery system. The second part discloses features that enable the medical fluid delivery system to increase patient engagement and / or compliance with medical treatment.

[0080] I. Medical Fluid Delivery System Embodiments

[0081] An example medical fluid delivery system includes one or more medical fluid delivery machines. An example of a medical fluid delivery machine is a renal failure treatment machine. With respect to a renal failure treatment machine, a patient's renal system may fail due to a variety of reasons. Renal failure causes several physiological abnormalities. It is no longer possible to balance water and minerals or excrete the daily metabolic load. Toxic end products of nitrogen metabolism (urea, creatinine, uric acid, etc.) accumulate in the blood and tissues.

[0082] Kidney failure and decreased kidney function are treated with dialysis. Dialysis removes waste products, toxins, and excess water from the body that normally functioning kidneys would remove. Dialysis therapy to replace kidney function is vital for many people because it can be life-saving.

[0083] One type of renal failure treatment is hemodialysis ("HD"), which typically uses diffusion to remove waste products from a patient's blood. Diffusion is caused by a diffusion gradient across a semipermeable dialyzer between the blood and an electrolyte solution called dialysate.

[0084] Hemofiltration ("HF") is an alternative renal replacement therapy that relies on the convective transport of toxins from the patient's blood. HF is achieved by adding a replacement or substitution fluid (typically 10 to 90 liters of such fluid) to the extracorporeal circuit during treatment. During HF treatment, the replacement fluid and the patient's fluid accumulated between treatments are ultrafiltered, providing a convective transport mechanism that is particularly beneficial for the removal of medium and large molecules (in hemodialysis, small amounts of waste products are removed as well as fluid obtained between dialysis sessions, however, the solute resistance of the ultrafiltrate is insufficient to provide convective clearance).

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

[0086] Most HD (HF, HDF) treatments occur in-center. Today, there is a trend toward home hemodialysis ("HHD"), in part because HHD can be performed daily, which offers therapeutic advantages over in-center hemodialysis treatments, which are typically performed every two or three weeks. Studies have shown that more frequent treatments remove more toxins and waste products than patients who receive less frequent but potentially longer treatments. Patients who receive more frequent treatments do not experience as many down cycles compared to patients who receive in-center treatments, who have two to three days of toxin accumulation prior to treatment. In some areas, the nearest dialysis center may be several miles from the patient's home, resulting in home treatment times consuming a large portion of the day. HHD may occur at night or during the day when the patient is resting, working, or otherwise productive.

[0087] Another treatment for kidney failure is peritoneal dialysis, which infuses a dialysis solution (also called dialysate) into the patient's peritoneal cavity via a catheter. The dialysate contacts the peritoneum of the peritoneal cavity. Due to diffusion and osmosis, waste products, toxins, and excess water flow from the patient's blood through the peritoneum and into the dialysate, i.e., an osmotic gradient occurs across the membrane. The osmotic agent in dialysis provides the osmotic gradient. The used or spent dialysate is drained from the patient's body, removing waste products, toxins, and excess water from the patient's body. This cycle is repeated, for example, multiple times.

[0088] There are several types of peritoneal dialysis treatments, including continuous ambulatory peritoneal dialysis (“CAPD”), automated peritoneal dialysis (“APD”), and tidal flow dialysis and continuous flow peritoneal dialysis (“CFPD”). CAPD is a manual dialysis treatment. Here, the patient manually connects an implanted catheter to a drain to allow used or waste dialysate to drain from the peritoneal cavity. The patient then connects the catheter to a bag of fresh dialysate to infuse fresh dialysate into the patient through the catheter. The patient disconnects the catheter from the bag of fresh dialysate and allows the dialysate to remain in the peritoneal cavity, where the transfer of waste products, toxins, and excess water occurs. After a period of residence, the patient repeats the manual dialysis process, for example four times a day, with each treatment lasting about an hour. Manual peritoneal dialysis requires a significant amount of patient time and effort, so there is ample room for improvement.

[0089] Automated peritoneal dialysis ("APD") is similar to CAPD in that dialysis treatment includes drain, fill, and dwell cycles. However, an APD machine typically performs the cycles automatically while the patient is asleep. An APD machine relieves the patient from having to manually perform treatment cycles or have supplies delivered during the day. The APD machine is fluidly connected to an implanted catheter, a source or bag of fresh dialysate, and a drain. The APD machine pumps fresh dialysate from a source of dialysate through the catheter into the patient's peritoneal cavity. The APD machine also allows the dialysate to remain in the cavity and performs the transfer of waste, toxins, and excess water. The source can include multiple sterile dialysate bags.

[0090] The APD machine pumps used or spent dialysate from the peritoneal cavity through a catheter to a drain. As with the manual process, several empty, fill, and dwell cycles occur during dialysis. The "last fill" occurs at the end of the APD and remains in the patient's peritoneal cavity until the next treatment.

[0091] Any of the above modalities performed by the machine may run on a schedule and may require a start-up process. For example, dialysis patients typically undergo treatment on a schedule, such as every other day, every day, etc. Blood treatment machines typically require a certain amount of time to set up before treatment, such as running a disinfection process. Patients receiving the above modalities may have busy lives and projects to perform or tasks scheduled to be completed on the day of treatment.

[0092] Much of the appeal of home treatment to patients revolves around the lifestyle flexibility provided by allowing the patient to perform treatment in his or her home, largely on his or her own schedule. However, a home medical fluid delivery machine may include a software timer that instructs and constrains the user or patient. A home hemodialysis system may, for example, require the patient to be in close proximity to the home hemodialysis machine to initiate a pre-treatment, during-treatment, and post-treatment sequence.

[0093] In one specific example, the home therapeutic device can reuse certain components by sterilizing certain components between treatments. The machine can employ one or more sterilization timers that require the patient or caregiver to use the machine to begin treatment before the sterilization timer expires. Otherwise, the patient will have to wait until another sterilization procedure is completed before treatment can begin. In an embodiment, the home therapeutic device communicates a treatment start time limit via the machine's graphical user interface, which requires the patient to approach the machine to access the start time limit and respond accordingly.

[0094] It should be understood that the present disclosure is applicable to any type of disinfection, such as hot water disinfection and chemical disinfection. In this regard, the present disclosure is not limited to home treatment devices, for example, machines in centers are typically chemically disinfected and treatment start time limits can be set after such disinfection. In addition, the present disclosure is not limited to start time limits based on disinfection, and can also be applied to other start time limits, such as start time limits based on perfusion completion. Further, the present disclosure is not limited to the initial start time limit. For example, most machines will allow the patient to temporarily stop treatment and disconnect from the machine to perform some type of necessary action away from the machine. For blood treatments, the machine will typically flush the blood back to the patient and may or may not circulate the dialysate for a period of time. In either case, the time that the patient can be temporarily disconnected from the machine is not unlimited, and it can be expected that the present disclosure also applies to the return time limit.

[0095] In one embodiment, the system of the present disclosure provides a software application ("app") installed on a patient's and / or caregiver's personal mobile communication device (e.g., a smart phone). In one embodiment, the app is provided via a middleware software application, examples of which are discussed in detail below. In an alternative embodiment, the software is configured to communicate directly with the patient's and / or caregiver's personal mobile communication device (e.g., a smart phone) using text messaging capabilities through the middleware software application. In either case, in one embodiment, the app or text message is constructed to remind the patient of any upcoming deadlines and allow the patient and / or caregiver to keep track of when treatment needs to begin without tying the patient to a machine.

[0096] It is contemplated that the communication software may alternatively or additionally be configured to automatically program reminders on a user's mobile communication device, such as on a native task tracking function of the device, such as a calendar application. Most smartphones are equipped with a calendar that divides each day into multiple time periods, such as hours. The software of the disclosed systems and methods may be programmed to access the smartphone calendar of an authorized patient and / or caregiver and fill in the appropriate time period of the appropriate day with the appropriate information, e.g., the time period during which the machine should start or complete disinfection.

[0097] In one embodiment, the communication from the software system and method of the present disclosure is unidirectional. For example, the communication can be from a medical fluid delivery machine (which may be a home machine) to a patient or caregiver's mobile communication device. In an alternative embodiment, the software system and method of the present disclosure enable two-way communication between the medical fluid delivery machine and the patient's or caregiver's mobile communication device. In one example, two-way communication can allow a patient or caregiver to remotely start certain machine routines using their mobile communication device. An example routine is an automated self-test routine that can be performed without any user interaction with the system, except for the initialization or startup sequence. The remote startup sequence can benefit the patient or caregiver, for example, by providing additional time for the patient or caregiver who is away from the machine to perform other tasks. When the machine initializes the communication by indicating that the machine is ready to perform the self-test routine, the communication becomes two-way. The patient or caregiver responds to the machine via the software system and method of the present disclosure at the desired time to initialize the sequence.

[0098] For the software of the systems and methods of the present disclosure, it is contemplated that communications between the patient and / or caregiver and the machine are inhibited as long as the machine is in the "patient connected" software state. For example, if a clinician attempts to send a command to a machine that is currently treating a patient, the command may be intercepted by the middleware software application so that the command is not transmitted to the machine. The middleware software application may then communicate back to the clinician that the machine is busy and will not accept communications.

[0099] The examples described herein are applicable to any medical fluid delivery system for delivering medical fluids such as blood, dialysate, replacement fluids, or / and intravenous medications ("IV"). These examples are particularly suitable for renal failure treatments, such as all forms of hemodialysis ("HD"), hemofiltration ("HF"), hemodiafiltration ("HDF"), continuous renal replacement therapy ("CRRT"), and peritoneal dialysis ("PD"), which are collectively or generally referred to herein as renal failure treatments. The medical fluid delivery machine may alternatively be a drug delivery or nutritional fluid delivery device, such as a large volume peristaltic pump or syringe pump. The machines described herein may be used in a home setting. For example, a machine operating with the data transmission scheme of the present disclosure may be used with a home HD machine, which may be run, for example, at night while the patient is sleeping. The medical fluid data transmission systems and methods of the present disclosure may alternatively be used to assist clinicians or nurses in hospitals and / or clinics.

[0100] Referring now to the drawings, and in particular to Figure 1, shows a medical fluid data transfer system 10 operating within a medical fluid delivery machine 90. The system 10 includes a number of medical fluid delivery machines 90 (one of which will be discussed in detail below). The machines 90 of the data transfer system 10 can be of the same type (e.g., all HD machines) or of different types (e.g., a mix of HD, PD, CRRT, and medical or nutritional fluid delivery).

[0101] Although a single medical fluid delivery device 90 is shown communicating with the connection server 118, the system 10 oversees the operation of multiple medical fluid delivery systems and machines of the same or different types listed above. For example, there may be M hemodialysis machines 90, N hemofiltration machines 90, O CRRT machines 90, P peritoneal dialysis machines 90, Q home medication delivery machines 90, and R nutrition or drug delivery machines 90 connected to the server 118 and operating with the system 10. The numbers M through R may be the same or different numbers and may be 0, 1, or greater than 1. Figure 1 In FIG. 1 , the medical fluid delivery machine 90 is shown as a home treatment device 90 (home use is indicated by dashed lines).

[0102] The home therapeutic device 90 can receive purified water at its front end from the water treatment device 60 as described above. In one embodiment, the water treatment device 60 is connected to the home therapeutic device 90 via an Ethernet cable. The home therapeutic device 90 in the illustrated embodiment operates with other devices in addition to the water treatment device 60, such as a blood pressure monitor 104, a weight scale (e.g., a wireless weight scale 106), and a user interface (such as a wireless tablet user interface 122). In one embodiment, the home therapeutic device 90 is wirelessly connected to a server 118 via a modem 102. Each of these components can (but is not required to) be located in the patient's home, such as Figure 1 . Any one or more or all of the components 60, 104, 106 and 122 can communicate with the home treatment device 90 by wire or wirelessly. Wireless communication can be via Bluetooth™, WiFi™, Zigbee®, Z-Wave®, wireless universal serial bus ("USB"), infrared or any other suitable wireless communication technology. Alternatively, any one or more or all of the components 60, 104, 106 and 122 can communicate with the home treatment device 90 via wired communication.

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

[0104] An electronic medical record ("EMR") database at a clinic or hospital 126a to 126n stores electronic information about the patient. The system hub 120 can send data collected from the log files of the machine 90 to the hospital or clinic database 126a to 126n to merge or supplement the patient's medical record. The database of the clinic or hospital 126a to 126n may contain treatment and prescription data specific to the patient, so access to such databases may be strictly restricted. The enterprise resource planning system 140 obtains and compiles data generated via patient and clinician website access, such as complaints, billing information, and life cycle management information. The web portal 150 enables patients and clinics 152a to 152h that treat patients to access websites that are publicly available to users of the medical fluid delivery machine 90. The business intelligence portal 160 collects data from the system hub 120 and provides the data to marketing 162, research and development 164, and quality / pharmacovigilance 166.

[0105] It should be appreciated that the systems, methods, and processes described herein may be implemented using one or more computer programs or components. The program of the component may be provided as a series 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 storage, or other storage media), which instructions may be configured to be executed by a processor, which, when executing the series of computer instructions, performs or facilitates the execution of all or part of the disclosed methods and processes.

[0106] In one embodiment, the home therapy device 90 performs home therapy, such as home hemodialysis, to a patient in the patient's home and then reports the results of the therapy to clinicians, doctors, and nurses responsible for managing the patient's health and well-being.

[0107] In one embodiment, the home treatment device 90 uses, for example, Linux TMThe operating system writes a log file. The log file records the data of the relevant home therapeutic device 90, including peripheral device data. The log file may include any one or more of an extensible markup language ("XML"), a comma separated value ("CSV"), or a text file. The log file is placed in the file server box of the software of the home therapeutic device 90. It is also envisioned that data not sent to the machine 90 is stored in a peripheral device (such as a water treatment device 60). Such data can be obtained in other ways via a wired or wireless connection to the peripheral device, or can be downloaded through other data connections or storage media. For example, a service person can access additional data, for example, via an Ethernet connection, via a laptop computer connected to the water treatment device 60 or a wireless weight scale 106. Alternatively, the home therapeutic device 90 used as a data transmission liaison between the peripheral device and the authorized client of the medical fluid data transmission system can be used to remotely retrieve additional data from the peripheral device.

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

[0109] The connection agent 114 allows the home treatment device 90 to connect to the connection server 118 and transfer data to and from the connection server 118. The connection service, which operates via the agent 114 and the server 118, ensures that the connection to the machine 90 is secure, ensures that data passes through the firewall of the machine 90 correctly, checks for data or system corruption, and ensures that the connection server 118 is communicating with the correct home treatment device 90.

[0110] In one embodiment, the home treatment device 90 can connect to the connection server 118 only when the connection agent 114 is turned on or activated. During treatment and post-treatment disinfection, while the machine 90 and its peripherals are operating normally, in one embodiment, the connection agent 114 is turned off, preventing the home treatment device 90 from communicating with any entity and sending or receiving data during treatment and disinfection or when the machine 90 is running or is running. In one embodiment, when the home treatment device 90 is idle, for example, after treatment and post-disinfection are completed, the ACPU 50 turns on the connection agent 114. In an embodiment, the connection agent 114 is turned off during treatment and possibly during pre-treatment. After treatment, the connection agent 114 retrieves log files from the home treatment device 90 and transmits the data to the connection server 118 using the connection service. In one embodiment, the connection service routes the data packets to their appropriate destinations, but does not modify, access or encrypt the data.

[0111] exist Figure 1 In the medical fluid data transmission system 10 system, the connection service via the connection server 118 can transmit data to various places via the system hub 120 such as the service portal 130, the clinic or hospital 126a to 126n and the web portal 150. The connection server 118 allows the service personnel 132a to 132h and / or the clinician to track and retrieve various assets, such as the appropriate home treatment device 90 and the 3G, 4G or 5G modem 102, and their related information, including the machine or modem serial number, through the network. The connection server 118 can also be used to receive firmware upgrades approved by the supervisor of the service personnel 134 and obtained remotely via the service portal 130, and provide them to the authorized home treatment device 90 and related peripherals, such as the water treatment device 60.

[0112] A. Example Medical Fluid Delivery Machine

[0113] Reference now Figure 2 , shows an example of an HD flow diagram for a medical fluid delivery machine 90. Figure 2 The HD system is relatively complex, so Figure 2 The discussion thereof also provides support for any of the renal failure treatment modalities discussed above, as well as IV, drug delivery, or nutrient fluid delivery machines. Generally, the medical fluid delivery machine 90 shown has a simplified form of a dialysate or process fluid delivery circuit. The blood circuit is also simplified, but not to the extent that the dialysate circuit is simplified. It should be recognized that the circuit has been simplified to facilitate description of the present disclosure, and if the system is implemented, it will have additional structure and functionality such as found in the publications incorporated by reference above.

[0114] Figure 2The medical fluid delivery machine 90 includes a blood circuit 20. The blood circuit 20 draws blood from the patient 12 and returns the blood to the patient 12. Blood is drawn from the patient 12 via the arterial line 14 and returned to the patient via the venous line 16. The arterial line 14 includes an arterial line connector 14a connected to an arterial needle 14b, which is connected to the patient 12 for blood collection. The venous line 16 includes a venous line connector 16a connected to a venous needle 16b, which is connected to the patient's blood return. The arterial and venous lines 14 and 16 also include line clamps 18a and 18v, which can be spring-loaded fail-safe mechanical compression clamps. In one embodiment, in an emergency, the line clamps 18a and 18v close automatically.

[0115] The arterial and venous lines 14 and 16 also include air or bubble detectors 22a and 22v, respectively, which may be ultrasonic air detectors. The air or bubble detectors 22a and 22v look for air in the arterial and venous lines 14 and 16, respectively. If one of the air detectors 22a and 22v detects air, the system 10 closes the line clamps 18a and 18v, pauses the blood pump and the dialysate pump, and provides instructions to the patient to clear the air so that treatment can resume.

[0116] In the illustrated embodiment, the blood pump 30 is located in the arterial line 14. In the illustrated embodiment, the blood pump 30 includes a first blood pump compartment 30a and a second blood pump compartment 30b. The blood pump compartment 30a operates with an inlet valve 32i and an outlet valve 32o. The blood pump compartment 30b operates with an inlet valve 34i and an outlet valve 34o. In one embodiment, the blood pump compartments 30a and 30b are blood receivers, respectively, which include a hard shell, such as a spherical shape, with a flexible diaphragm inside the shell, thereby forming a diaphragm pump. One side of each diaphragm receives blood, while the other side of each diaphragm is operated by negative and positive air pressure. The blood pump 30 can alternatively be a peristaltic pump that operates with the arterial line 14 or a plurality of peristaltic pumps that operate with the arterial line 14 and the venous line 16.

[0117] In the illustrated embodiment, heparin vials 24 and heparin pump 26 are located between blood pump 30 and blood filter 40 (e.g., dialyzer). Heparin pump 26 can be a pneumatic pump or a syringe pump (e.g., a syringe pump driven by a stepper motor). Providing heparin upstream of blood filter 40 helps prevent clotting of the filter membrane.

[0118] The main control processor ("ACPU") or control unit 50 includes one or more processors and memory. The control unit 50 receives air detection signals from the air detectors 22a and 22v (as well as other sensors of the system 10, such as temperature sensors, blood leak detectors, conductivity sensors, pressure sensors, and on-off transducers 86, 88) and controls components such as line clamps 18a and 18v, blood pump 30, heparin pump 26, dialysate pumps 64 and 96, and valves 32i, 32o, 34i, 34o, 68i, 68o, 98i, and 98o. Blood leaving the blood filter 40 via the 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.

[0119] for Figure 2 In a hemodialysis version of a medical fluid delivery machine 90, dialysate is pumped along the outside of the membrane of a blood filter 40, while blood is pumped through the inside of the blood filter membrane. The dialysate is first prepared by purifying water via a water purification unit 60. A suitable water purification unit is described in U.S. Patent Publication No. 2011 / 0197971, entitled "Water Purification System and Method," filed on April 25, 2011, the entire contents of which are incorporated herein by reference. In one embodiment, the water purification unit includes a filter and other structures to purify tap water (e.g., to remove pathogens and ions, such as chlorine) so that, in one embodiment, the water has an endotoxin unit of less than 0.03 milliliters ("EU / ml") and a colony forming unit of less than 0.1 ml ("CFU / ml"). The water purification unit 60 can be disposed in a housing separate from the housing or chassis of the hemodialysis machine 90, the housing including a blood circuit 20 and a dialysate circuit 70.

[0120] exist Figure 2 The dialysate circuit 70 is again highly simplified in order to simplify the illustration. In fact, the dialysate circuit 70 may include all relevant structures and functions set forth in the publications incorporated by reference above. Certain features of the dialysate circuit 70 are described in Figure 2 . In the illustrated embodiment, the dialysate circuit 70 includes a blood filter dialysate 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 chambers 66, each having an inlet valve 68i and an outlet valve 68o, which may also be spherical. Like the blood pump 30, the two pump chambers are operated alternately so that one pump chamber is filled with HD dialysate while the other pump chamber is drained of HD dialysate.

[0121] Pump 64 is the hemofilter dialysate pump. There is another dual compartment pump chamber 96 that operates with valves 98i and 98o located in the drain line 82 to push the spent dialysate out. There is a third compartment pump (not shown) for pumping pump purified water through the bicarbonate cartridge 72. There is a fourth compartment pump (not shown) for pumping acid from the acid container 74 into the mixing line 62. The third and fourth pumps, i.e., the concentrate pumps, can be single compartment pumps because, in one embodiment, it is not important to pump continuously in the mixing line 62 because there is a buffer dialysate tank (not shown) between the mixing line 62 and the hemofilter dialysate fluid pump 64.

[0122] When providing HD therapy, a fifth chamber pump (not shown) disposed in the discharge line 82 is used to remove a known amount of ultrafiltrate ("UF"). The system 10 tracks the UF pump to control and understand how much ultrafiltrate has been removed from the patient. The system 10 ensures that the necessary amount of ultrafiltrate is removed from the patient at the end of treatment.

[0123] Each of the above-mentioned pumps may alternatively be a peristaltic pump working with a pump tube. If so, according to the features of the present disclosure, the system valves may still be pneumatically actuated.

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

[0125] Figure 2 Also shown is that the dialysate is pumped along fresh dialysate line 76 through heater 78 and ultrafilter 80 before reaching the blood filter 40, after which the used dialysate is pumped out via drain line 82. Heater 78 heats the dialysate to body temperature or about 37° C. Ultrafilter 80 further clarifies and purifies the dialysate before reaching the blood filter 40, filtering out foreign matter and / or contaminants introduced from the dialysate via, for example, bicarbonate cartridge 72 or acid container 74.

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

[0127] In the illustrated embodiment, the medical fluid delivery machine 90 is an in-line, straight-through system that pumps the dialysate once through the blood filter and then pumps the spent dialysate to drain. After each treatment, the blood circuit 20 and the dialysate circuit 70 can be hot water sterilized so that the blood circuit 20 and the dialysate circuit 70 can be reused. In one embodiment, the blood circuit 20 including the blood filter 40 is hot water sterilized every day and reused for about one month, while the dialysate circuit 70 is hot water sterilized and reused for about six months.

[0128] In alternative embodiments, for example, for CRRT, multiple bags of sterile dialysate or infusate are combined and used one after another. In this case, the emptied supply bag can be used as a drain bag or a waste bag.

[0129] The medical fluid delivery machine 90 includes Figure 2 The housing of the machine 90 varies depending on the type of treatment, whether the treatment is in-center or home treatment, and whether the dialysate / infusate replenishment is intermittent (e.g., bagged) or online.

[0130] Figure 3 Shows Figure 2 The machine 90 can 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 blood filter 40 (e.g., a dialyzer). An air trap 28 can be located in the venous line 16 to remove air from the blood before returning the blood to the patient 12. Air detectors 22a and 22v contact the arterial and venous lines 14 and 16, respectively, for operation.

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

[0132] B. Example Medical Fluid Delivery System Connectivity Embodiments

[0133] Reference now Figure 4, showing a system 110a of the present disclosure. The system 110a in the illustrated embodiment operates together with the above-described system 10, and includes a connection server 118, a system hub 120, a service portal 130, an enterprise resource planning system 140, a web portal 150, and a business intelligence portal 160, which are Figure 4 The connection 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 each be part of a cloud environment or located on one or more dedicated servers.

[0134] exist Figure 4 Other components of the system 10 not shown in the figure may also be part of the system 110a. For example, the medical fluid delivery machines 90a and 90b may be separately located in the homes of the patients 12a and 12b (shown as not at home). Alternatively, the medical fluid delivery machines 90a and 90b may be located in the same clinic 126a to 126n or in different clinics 126a to 126n. The clinicians 112a and 112b may live in or outside the clinic.

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

[0136] In one embodiment, the mobile communication devices 200a and 200b download application software ("app") from the middleware software stored on the system hub 120 via their connection to the Internet 52. The app is updated whenever the state of the corresponding machine 90a or 90b changes. For example, the medical fluid delivery machine 90a may have just completed its automatic self-test routine and is now ready to run a sterilization process. The machine 90a can generate a code identifying this state and send it to the middleware software stored on the system hub 120. The middleware software then converts the code into a message, such as "Self-test complete, ready for sterilization", using, for example, a lookup table, and causes the application downloaded to the mobile communication device 200a of the patient 12a or clinician 112a to display the message. The application can be programmed to provide a visual identifier along with the message, such as an icon associated with the specific state that the machine 90a is in. The app may also provide any one or more of an audio alert (such as a "ding") and / or a tactile alert (such as a vibration) that would prompt the patient 12a or clinician 112a to check the app and understand the change in status of the machine 90.

[0137] In another example, the medical fluid delivery machine 90b may have been preprogrammed to start treatment at 3:00 p.m. The medical fluid delivery machine 90b may take three hours to perform self-tests and disinfection. Therefore, the patient 12a or clinician 112a needs to be at the machine 90b before noon to start pre-treatment. In one embodiment, the patient 12a or clinician 112a makes settings on the machine 90b regarding how long (e.g., 2 hours) before the three-hour preparation time should be notified or reminded of the patient 12a or clinician 112a. Therefore, in this example, the machine 90b can generate a code at 10:00 a.m. and send the code to the middleware software stored on the system hub 120. Then, the middleware software, for example, uses a lookup table to convert the code into a message, such as "need to start treatment preparation within two hours", and causes the application downloaded to the mobile communication device 200b of the patient 12b or clinician 112b to display the message. The application can again be programmed to provide a visual identifier with the message, such as a countdown timer that counts down from one hundred and twenty minutes to zero timeout. The app may also provide any one or more of an audio alert (such as a "ding") and / or a tactile alert (such as a vibration) to prompt the patient 12b or clinician 112b to check the app and understand the treatment preparation notification. The app may also be programmed to repeat the "ding" and / or tactile feedback process at pre-programmed intervals (e.g., at one hour and thirty minutes) during the countdown.

[0138] In addition to or in lieu of providing an application on the user's communication device 200b, it is also envisioned that the middleware software at the system hub 120 converts the code from the machine 90b into a message that is stored on the native task tracking function of the device 200, such as its calendar application. For example, most smart phone devices 200 are provided with a calendar that divides each day into time periods, such as hours. Here, the message converted by the middleware software of the system hub 120 can be programmed to access the calendar of the authorized communication device 200b and fill in the appropriate time period for the appropriate date with the appropriate information. In the above example, for the appropriate date, the native calendar software application will fill in the time slot of 10:00:00 am, such as "need to start treatment preparation in two hours". Audio and / or tactile feedback signals can be provided to inform the patient 12 or clinician 112 of the calendar entry.

[0139] It should be appreciated that the machines 90a and 90b, the middleware software at the central server 120, and the communication devices 200a and 200b can be programmed and operated as described above to provide any desired messages to the patients 12a, 12b and / or clinicians 112a, 112b, and are not limited to the messages described herein. For example, the patient 12a, 12b and / or clinician 112a, 112b can also be informed by an attached countdown timer at the end of the sterilization that the treatment needs to be started within the countdown time to avoid having to sterilize the machine 90a, 90b again.

[0140] Reference now Figure 5 , showing the system 110b of the present disclosure. The system 110b in the illustrated embodiment operates together with the above-mentioned system 10, including a connection server 118, a system hub 120, a service portal 130, an enterprise resource planning system 140, a web portal 150 and a business intelligence portal 160, which are Figure 5 is shown as being part of a cloud environment, but may alternatively be located on one or more dedicated servers. Figure 5 Other components of the system 10 not shown in the figure may also be part of the system 110a. For ease of description, a single medical fluid delivery machine 90 is shown, however, multiple medical fluid delivery machines 90 may be similarly connected to the system 110b. The medical fluid delivery machine 90 may be located at the home of the patient 12 (shown as not at home) or in the clinic 126a to 126n of the clinician 112. In the illustrated embodiment, the medical fluid delivery machine 90 is connected to the connection server 118 again via the secure management connection 116 and the Internet 52 connection using, for example, a modem 102.

[0141] In one embodiment, the system hub 120 stores middleware software that is accessible by the mobile communication device 200 (shown as a single device for convenience, although multiple devices 200 may also be similarly connected to the system 110b). Figure 5 The mobile communication device 200 includes Figure 4 All structures, functions and alternatives disclosed for the devices 200a and 200b shown in FIG, including connection to the Internet 52. Figure 5 In the example of FIG. 1 , the mobile communication devices 200 may, but need not, download software applications (“apps”) from the middleware software stored on the system hub 120 via their connection to the Internet 52. The applications may be combined with Figure 4 The middleware software stored on the system hub 120 can be used to perform operations including converting the encoded message from the machine 90 into a format that can be presented on the application. Alternatively or additionally, the middleware software stored on the system hub 120 can be used to Figure 4 In any of the ways described in , the code from the machine 90 is converted into a message, which is stored on the native task tracking function of the mobile communication device 200 (such as its calendar application).

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

[0143] The mobile communication device 200 communicates with the cellular network 210 via any means known to those skilled in the art, for example, via a short message service ("SMS") or multimedia message service ("MMS") protocol. The middleware software at the system hub 120 can communicate with the cellular network 210 in a variety of ways. In one example, the telephone number and carrier of a user 12, 112 (any or all of the patient 12, the patient at a home care partner, the patient's clinician 112) is associated with a particular machine 90, for example, via a lookup table at the middleware software. When a message / code from a particular machine 90 is received by the middleware, the middleware software can be programmed to send an email to [user phone number]@[carrier].net. For example, if patient 001's phone number is (555) 555-5555, and patient 001's carrier is AT&T TM , then when patient 001's machine 90 sends a message to the middleware software of system hub 120, upon receipt of the message, the middleware software 120 is programmed to relay the email to 5555555555@att.net, which is received as a text message by patient 001's mobile communication device 200. Those skilled in the art will appreciate that there are multiple websites dedicated to informing how to send text messages via email, outlining the details required by different carriers.

[0144] The middleware software stores each of the telephone numbers of each mobile communication device 200 and matches each telephone number with a machine 90. As described above, when an event code is sent from a machine 90 to the middleware software, the middleware software locates the telephone number of the mobile communication device 200 associated with the machine, e.g., using a lookup table as described above, converts the code to an appropriate message, and sends the converted message to the called telephone number. It is contemplated that multiple communication devices 200 may be associated with the same medical fluid delivery machine 90. For example, in any of the clinics 126a to 126n, the telephone numbers of multiple doctors, nurses, and / or clinicians may be associated with the same machine 90. In a home environment, the telephone numbers of the patient 12 and their clinician and / or caregiver assistant may be associated with the same machine 90.

[0145] Likewise, a phone 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 to 126n, a single nurse may monitor multiple machines 90. If an event occurs at any of these machines during the nurse's shift, the nurse may be notified via a cellular message sent to the nurse's mobile communication device 200. Figures 7 to 9 Describe the scenario in detail.

[0146] The cellular message may convey information about any of the same events used to populate the software app and calendar update modes of the mobile communication device 200 with information as described above. For example, the medical fluid delivery machine 90 may have just completed its automatic self-test procedure and is preparing to run a sterilization process. The machine 90a may generate a code identifying this state and send it to the middleware software stored on the system hub 120. The middleware software then converts the code into a message, such as "Self-test complete, ready for sterilization", using, for example, a lookup table, and causes, for example, the cellular output routine described above, to send a text message to the mobile communication device 200 of the patient 12 or clinician 112 to display the message. In an alternative embodiment, the code is not required, and the machine 90 instead sends an actual text string, which the middleware software forwards to the mobile communication device 200 as a text message via, for example, the cellular output routine discussed above. As is well known, receiving a text message on the communication device 200 may be accompanied by an audio, such as a "ding" sound and / or a tactile alarm, such as a vibration, which prompts the patient 12 or clinician 112 to check the message.

[0147] In another example, the medical fluid delivery machine 90 may have been preprogrammed to start treatment at 3:00 p.m. The medical fluid delivery machine 90 may again require three hours for self-testing and disinfection. Therefore, the patient 12 or clinician 112 needs to be at the machine 90 before noon to start pretreatment. In an embodiment, the patient 12 or clinician 112 makes settings on the machine 90 regarding how long (e.g., 2 hours) before the three-hour preparation time should be notified or reminded of the patient 12 or clinician 112. Here, the machine 90 generates a code at 10:00 a.m. and sends the code to the middleware software stored on the system hub 120. The middleware software then converts the code into a message, such as "need to start treatment preparation within two hours" using a lookup table, for example, and causes the cellular output routine described above to send a text message to the mobile communication device 20 of the patient 12 or clinician 112 to display the message, for example, with an audio alarm (such as a "ding" sound) and / or a tactile alarm (such as a vibration), prompting the patient 12 or clinician 112 to view the notification.

[0148] It should be appreciated that the machine 90, the middleware software at the central server 120, and the communication device 200 may be programmed and operated as described above to provide any desired messages to the patient 12 and / or clinician 112 using the cellular network 210, alternatively or additionally. For example, at the end of sterilization, the patient 12 and / or clinician 112 may also be notified that treatment needs to begin within a countdown time to avoid having to re-sterilize the machine 90. It should also be appreciated that the machine 90 may be connected via an Internet connection or via a cellular network 210. Figure 5The cellular network 210 is shown to accomplish updating of native task tracking features such as a calendar application of the communication device 200 .

[0149] Reference now Figure 6 , showing a system 110c of the present disclosure. The system 110c in the illustrated embodiment operates together with the above-described system 10, including Figure 6 The connection server 118, system hub 120, service portal 130, enterprise resource planning system 140, web portal 150 and business intelligence portal 160 are shown in FIG. Figure 6 is shown as part of a cloud environment, but may alternatively be located on one or more dedicated servers. Figure 6 Other components of the system 10 not shown in the figure may also be part of the system 110a. For ease of description, a single medical fluid delivery machine 90 is shown, however, multiple medical fluid delivery machines 90 may be similarly connected to the system 110b. The medical fluid delivery machine 90 may be located at the home of the patient 12 (shown as not at home) or in the clinic 126a to 126n of the clinician 112. In the illustrated embodiment, the medical fluid delivery machine 90 is again connected to the connection server 118 via a secure management connection 116 and the Internet 52 using, for example, a modem 102. In Figure 6 In the example, connection server 118 and secure management connection 116 are used for two-way communication.

[0150] In one embodiment, the system hub 120 stores middleware software that is accessible by the mobile communication device 200 (shown as a single device for convenience, although multiple devices 200 may also be similarly connected to the system 110b). Figure 6 The mobile communication device 200 includes Figure 4 All structures, functions and alternatives disclosed by the devices 200a and 200b shown include connection to the Internet 52. Figure 6 In the example of FIG. 1 , the mobile communication devices 200 may, but need not, download software applications (“apps”) from the middleware software stored on the system hub 120 via their connection to the Internet 52. The applications may be combined with the Figure 4 The middleware software may be capable of performing operations including converting the encoded message from the machine 90 into a format that can be presented on the application. Alternatively or additionally, the middleware software stored on the system hub 120 may be capable of Figure 4 In any of the above described ways, the code from the machine 90 is converted into a message, which is stored on the native task tracking function component of the mobile communication device 200 (such as its calendar application). The calendar application can alternatively be connected via the above combination Figure 5 The cellular network 210 discussed (via Figure 6The dashed line leader in the figure shows an alternative solution).

[0151] Figure 6 It is shown that the communication between the medical fluid delivery machine 90 and the mobile communication device 210 can be bidirectional. The communication between the mobile communication device 210 and the middleware software at the server computer 120 can be carried out via the Internet 52 and / or the cellular network 210. As described in detail above, the communication between the middleware software at the server computer 120 can be carried out via the secure management connection 116, via the connection server 118.

[0152] As described above, the home treatment device 90 is connected to the connection server 118 via its onboard connection agent 114. In one embodiment, during treatment, for example, when the machine 90 and its peripherals are running, the onboard connection agent 114 is turned off (the onboard connection agent 114 may or may not be turned off during the post-treatment disinfection). This prevents the home treatment device 90 from communicating with any entity and sending or receiving data during treatment and disinfection or when the machine 90 is in an active or running state. It is conceivable that the communication via the systems 110a to 110c is protected in the same manner. For example, it is assumed that a specific machine 90 is set up via middleware software to communicate with both the patient 12 and the clinician 112. Here, if the patient is being treated by the machine 90, it is conceivable to cut off the connection agent 114 so that the clinician 112 cannot receive notifications from the machine 90 or send commands to the machine 90 at this time. In an alternative embodiment, the clinician 112 may be able to receive notifications from the machine 90 during treatment.

[0153] Determining when to disconnect the connection agent 114 (no communication) may depend on what the machine-stated systems 110a to 110c expect to communicate with the mobile communication device 200, or how many machine-stated systems 110a to 110c expect to communicate with the mobile communication device 200. For example, suppose that the patient 12 or clinician 112 is only expected to be notified two hours before treatment preparation, and the patient 12 or clinician 112 needs to return to the machine 90 to start treatment preparation. Here, once the patient 12 or clinician 112 begins the first treatment preparation step, such as running a self-check routine, the connection agent 114 may be turned off.

[0154] In another example, it may be desirable for the machine 90 to automatically run a self-check routine at a preset time before starting treatment. The machine 90 notifies the patient 12 or clinician 112 when disinfection is started. Here, once the patient 12 or clinician 112 starts machine disinfection, the connection agent 114 can be disconnected. In another example, it may be desirable for the machine 90 to notify the patient 12 when disinfection is complete so that the patient can start treatment within a certain time from the end of disinfection, thereby eliminating the need for repeated disinfection. Here, once the patient 12 or clinician 112 starts treatment, such as in the early stages of the start when the patient still needs to be connected to a treatment line (e.g., arterial line 14 or venous line 16), the connection agent 114 can be disconnected.

[0155] The system 110c allows the patient 12 or clinician 112 to remotely initiate any of the above actions (as well as other actions not explicitly described herein). The patient 12 or clinician 112 can, for example, select an icon of an application displayed on the mobile communication device 200 to initiate, for example, a self-test routine or a disinfection process. The selection of the icon is transmitted to the middleware software via the Internet 52. The middleware software can then convert the icon selection into an action code, for example via a lookup table, which is sent to the machine 90 with the connection agent 114 in an open state via the connection server 118 and the secure management connection 116, thereby allowing the action code for the selected action to be sent to the ACPU 50 of the machine, which begins executing the selected action.

[0156] In an alternative embodiment, the patient 12 or clinician 112 may enter a known code, for example in a text message, to select a specific action to be performed at the machine 90, such as a self-test routine or a disinfection process. The code may be a prompting code, such as "self-test" or "disinfection". The text message is sent to the middleware software at the system hub 120 via the cellular network 210. The middleware software converts the text code to an action code for the selected action, for example via a lookup table. Alternatively, the code entered by the patient 12 or clinician 112 may be an action code, so that no conversion is required. In either case, the action code is sent to the machine 90 with the connection agent 114 in an open state via the connection server 118 and the secure management connection 116, thereby allowing the action code for the selected action to be sent to the ACPU 50 of the machine, thereby initiating execution of the selected action.

[0157] Figure 6The following example seven step sequence is shown. In step 1, the medical fluid delivery machine 90 sends a message to the middleware software application of the system hub 120 indicating that the machine is ready for the patient 12 to initiate the start-up of the machine 90, such as a two-hour automatic self-test routine. In step 2, the middleware software application at the system hub 120 sends a corresponding message (e.g., a converted message) to the patient's mobile communication device 200 indicating that the machine 90 is ready for the patient 12 to initiate the start-up of the automatic self-test routine.

[0158] In step 3, the customized application downloaded to the patient's mobile communication device 200 reminds the patient 12 via audio, visual and / or tactile reminders and related messages that the machine 90 of the patient 12 is ready for the patient to initiate the start of the automatic self-test program, for example, in two hours. In step 4, the patient 12 uses the customized application on the mobile communication device 200 to confirm that the machine 90 should start its automatic self-test routine.

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

[0160] Once the self-check is performed, it is contemplated that the system 110c performs the same steps 1 through 7 described above, except that the action is now a disinfection procedure rather than an automatic self-check routine. Here, a custom application downloaded to the patient's mobile communication device 200 can display a countdown timer to the patient 12, reminding the patient how long he or she must return to the machine 90 to initiate treatment. It should be appreciated that different types of medical fluid delivery machines may have different one, two, three, or more actions that the patient 12 or clinician 112 may perform before treatment begins.

[0161] With respect to systems 110a to 110c, it is contemplated that an application on a mobile communication device 200 may be programmed to be configurable by a user to select what notifications the user wishes to receive on their device 200, such as via the application itself, via text messages, and / or via calendar notifications. In one embodiment, the system hub 120 may send all notification types, wherein the mobile communication device 200 ignores communication types that the user has disabled. In another embodiment, the system hub 120 stores the user's preferences and only sends information in the selected notification types.

[0162] C. Clinician Device / Server Embodiment

[0163] Reference now Figures 7 to 9 , one embodiment of a system 110d having a clinician-based downloadable software application ("app") 230 for a doctor, clinician, or nurse's mobile communication device or server 200 is shown on screens 232 to 236. As described above, the mobile communication device 200 can be a mobile communication device of the patient 12 or a mobile communication device of the doctor / nurse / clinician 112. Figures 7 to 9 Screens 232 to 236 of show that the application 230 can be used in a clinic or hospital 126a to 126n, where a nurse, for example, is responsible for multiple machines 90a to 90n. The machines 90a to 90n can again be hemodialysis machines, peritoneal dialysis machines, CRRT machines, drug and / or nutrient solution delivery machines, and combinations thereof.

[0164] Screen 232 shows that the application 230 can monitor and, if necessary, control multiple machines 90. In the illustrated embodiment, the machines 90a to 90n are represented by dedicated icons 190a to 190n, respectively, displayed on the screen 232 of the application 230. In the illustrated embodiment, the order of the icons 190a to 190n on the screens 232 to 236 is the same as the order of the machines 90a to 90n in the clinics 126a to 126c to help orient the doctor / nurse / clinician 112.

[0165] It is contemplated that the application 230 operates with the system hub 120 as already discussed herein, wherein the system hub 120 is remote from the clinic or hospital 126a to 126n and maintained, for example, by the manufacturer of one or more of the machines 90a to 90n. Figure 1 The product development 128 shown develops the application 230. Then the Figure 1 and 7 As shown, the application 230 is sent from product development 128 to the system hub 120 via the service portal 130. Any nurse, clinician, or doctor 112 who is authorized to download the application 230 can download it from the system hub 120. Thereafter, the system hub 120 maintains the middleware software to operate with the application 230 in the systems 110a to 110c in the manner described above.

[0166] In an alternative embodiment, clinics 126a to 126n may maintain their own local area networks, each operating with a local system hub 220. Application 230 may again be developed by product development 128 ( Figure 1) and transmitted via the service portal 130 to the local system hub 220 of the clinic 126a to 126n that operates with the entire system 10. Each nurse, clinician, or doctor 112 who is authorized to download the application 230 downloads it from the local system hub 220. Thereafter, the local system hub 220 maintains the middleware software to operate with the application 230 in the manner described above for the system hub 120 in the systems 110a to 110c. In another alternative embodiment, the application 230 can be developed by the clinic 126a to 126n and stored on its local system hub 220.

[0167] The middleware software of the system hub 120 or the local system hub 220 updates the status of each machine 90a to 90n. The nurse, clinician or doctor 112 can select the icon 190a to 190n at any time to view the current status of each machine 90a to 90n, such as "resting", "self-checking", "disinfection" or "treating patient", as shown in FIG. Figure 8 Other status indicia are contemplated and may vary for different types of machines. The nurse, clinician, or doctor 112 may then select any of "rest," "self-check," "disinfect," or "treat patient" to return to the status screen 234. Fig. 9 Home icons 190a to 190n are shown.

[0168] As described above, it is conceivable that the connection agent 114 of each machine 90 is turned off when the machine is running, especially when the patient 12 is connected to the machine. However, it is also conceivable to allow the connection agent 114 of each machine 90a to 90n of the clinic 126a to 126n to remain on until the disinfection is completed, so that the middleware software at the system hub 120 or the local system hub 220 can receive the status change of "treating patient" from each machine 90a to 90n. In addition, because each machine 90a to 90n knows its planned treatment duration, the machine can also send the planned duration to the middleware software, which then sends the duration in the form of a countdown timer together with the status change of "treating patient". Then, here, when the nurse, clinician or doctor 112 is Figure 8 When they select Treat Patient, they will see a countdown timer showing the remaining treatment time, such as Fig. 9 shown.

[0169] It is contemplated that for a countdown timer, the connection agent 114 allows the machines 90a to 90n to send remaining time data to the system hub 120 so that the application 230 can display the actual remaining time for each machine 90 undergoing the timed process. The application 230 takes into account alarms or other delays that the machines 90 may experience. During an alarm condition, the corresponding icon 190a to 190f may display a message such as "alarm" or "safe mode". The nurse, clinician, or doctor 112 can then select Fig. 9 The countdown time in Figure 7 Home icons 190c, 190d and 190h are shown.

[0170] The nurse, clinician or doctor 112 may also toggle the alarm on / off icon 238 to allow or not allow the machine 90a to 90n to be visually, audibly and / or tactilely alerted of changes in the state of the machine 90a to 90n. If the alarm on / off icon 238 is toggled to "on", the application 230 of the mobile communication device 200 provides visual, audible and / or tactile alerts each time the machine state changes, such as: (i) self-test started, (ii) self-test completed, (iii) disinfection started, (iv) disinfection completed, (v) treatment started, (vi) treatment completed. In an embodiment, the codes (i) to (v) are sent via the machine 90a to 90n, through the secure management connection 116, the connection server 118 and the system hub 120 or the local system hub 220, to be converted and forwarded by the middleware software to the application 230, which updates the appropriate icon 190. In various embodiments, "(vi) treatment complete" may be (a) sent via a machine 90a to 90n with the connection agent 114 activated, or (b) inferred when a countdown timer on the appropriate icon 190a to 190n expires and while the connection agent 114 is still closed.

[0171] If the alarm on / off icon 238 is turned off, for example, if the nurse, clinician or doctor 112 does not wish to be disturbed at a given moment, the icons 190a to 190n are still updated as described above, but the audible and / or tactile alarms are not provided. However, the nurse, clinician or doctor 112 can still actively view the status of each machine 90a to 90n by selecting the relevant icon 190a to 190n.

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

[0173] In one embodiment, when the self-test button 240a is selected, any machine 90a to 90n that is now capable of performing a self-test has its corresponding icon 190a to 190n highlighted. The nurse, clinician or doctor 112 selects any one of the icons 190 of the machine 90 that the nurse, clinician or doctor 112 wishes to perform a self-test on. The selected icon 190 may then become a "confirm" button that the nurse, clinician or doctor 112 must press again to cause the selected machine 90 to perform its self-test. The application 230 of the mobile communication device 200 then sends the corresponding self-test code to the middleware software at the system hub 120 or the local system hub 220, which, if necessary, converts the self-test code into a self-test initialization command and sends the command to the connection agent 114 of the selected machine 90 via the connection server 118 through the secure management connection 116, which transmits the command to the ACPU 50 of the machine, which in turn initializes the self-test.

[0174] In the illustrated embodiment, when the sterilize button 240b is selected, any machine 90a to 90n that is now capable of performing sterilization has its corresponding icon 190a to 190n highlighted. The nurse, clinician or doctor 112 selects any of the icons 190 that the nurse, clinician or doctor 112 wishes to perform sterilization on. The selected icon 190 may again become a "confirm" button that the nurse, clinician or doctor 112 must press again to cause the selected machine 90 to perform its sterilization. The application 230 of the mobile communication device 200 then sends the corresponding sterilization code to the middleware software at the system hub 120 or local system hub 220, which, if necessary, converts the sterilization code into a sterilization initiation command that is sent via the connection server 118 to the connection agent 114 of the selected machine 90 over the secure management connection 116, which transmits the command to the ACPU 50 of the machine, which in turn initiates the sterilization.

[0175] The process just described for the action button 240 may also be implemented in the system 110c and may be implemented for other machine commands, which may vary depending on the type of machine 90. It is also contemplated that the clinic 126a may determine that it is sufficiently safe to keep the connection agent 114 open during treatment or a portion of treatment in the presence of one or more nurses, clinicians, or doctors 112 at the clinic. In this case, the nurse, clinician, or doctor 112 may control the in-treatment activities of the machine 90. For example, the nurse, clinician, or doctor 112 may receive and respond to alarms / alerts, start and stop pumps and other treatment aspects, start and stop sterilization, start and stop priming, etc. via the application 230 at the mobile connection device 200.

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

[0177] In one embodiment, when a mobile communication device 200 sends data to a system hub 120 or a local system hub 220 for transmission to a machine 90, the data is provided with an identifier of the mobile communication device 200 that identifies the mobile communication device 200 from which the data was sent. As described above, the system hub 120 or the local system hub 220 may or may not transform the data from the mobile communication device 200, but in either case, the mobile communication device 200 identifier is maintained for the connection server 118. The connection server 118 knows which machine 90 will receive the transformed data, e.g., for each mobile communication device 200, and sends the transformed data, e.g., to each associated communication device 200. Once transmitted to the machine 90, the connection server 118 may strip the identifier of the mobile communication device 200 from the data, since it is no longer needed.

[0178] The application 230 described above allows a nurse, clinician or doctor 112 to set up, monitor and possibly control treatment at the medical fluid delivery machine 90. It is contemplated that the application may be provided to the patient 12 or the patient's home ( Figure 1 The connectivity can be similar to that of the patient 12 in the dashed box in FIG. Figures 7 to 9 . However, the setting is not a clinic 126a to 126n, but rather a home or other non-clinical location, such as a business or vacation location. In addition, there is typically only a single machine 90, rather than multiple machines 90a to 90n. However, a single patient 12 may be treated via multiple machines 90, which may each be supported by an application as described herein. If the patient 12 is at home but away from the machine 90, the application may provide valuable information, such as the amount of time left to start or complete a startup process task, a disinfection process, or a self-test routine. While the machine 90 is treating the patient, he / she may see information on its user interface 122, which itself may be as described herein. Figure 1 The tablet computer shown. However, it may also be a caregiver, such as a spouse, friend, or home nurse, who assists the patient 12 at home. The caregiver benefits from the home application by receiving status updates, remaining start-up process time, remaining disinfection time, remaining priming time, remaining treatment time, information about whether the patient 12 is connected to the machine 90, reminders, alarms, etc. In one embodiment, the application requires entry of a login name and password associated with the patient before it can be downloaded to the caregiver's mobile communication device 200 so that only authorized personnel can view patient treatment data or information.

[0179] II. Patient Participation Examples

[0180] Combination of the above Figures 1 to 9The disclosed example medical fluid data transmission system 10 is configured to improve patient participation in medical fluid delivery therapy, such as dialysis therapy, renal failure therapy, and / or peritoneal therapy. Fig.10 According to an example embodiment of the present disclosure, an example medical fluid data transmission system 1000 is shown, which is similar to a system incorporating Figures 1 to 9 Medical fluid data transmission system 10 discussed. The example medical fluid data transmission system 1000 (e.g., mobile platform) is configured to improve patient engagement and / or compliance with treatment by increasing treatment transparency, providing patient features to control and report information related to treatment, and / or providing access to educational materials and / or real-time assistance from clinicians.

[0181] The exemplary medical fluid data transmission system 1000 includes, for example, a personal mobile communication device 200a operated by a patient. The medical fluid data transmission system 1000 also includes a blood pressure monitor 104, a weight scale 106, and a home therapy device 90, which are similar to the above combined Figures 1 to 9 The personal mobile communication device 200a, the home therapy device 90, the blood pressure monitor 104 and the weight scale 106 may be located, for example, in a patient's home, a self-help clinic and / or a service medical clinic.

[0182] The home therapeutic apparatus 90 may include any type of hemodialysis machine, peritoneal dialysis machine, CRRT machine, drug and / or nutrient solution delivery machine, and combinations thereof. The home therapeutic apparatus 90 may provide, for example, continuous cycle peritoneal dialysis ("CCPD"), tidal flow automated peritoneal dialysis ("APD"), and continuous flow peritoneal dialysis ("CFPD"). The home therapeutic apparatus 90 may automatically perform drain, fill, and dwell cycles, typically while the patient is sleeping.

[0183] The peritoneal dialysis dialysate may include a solution or mixture containing 0.5% to 10% dextrose (or more generally glucose), preferably 1.5% to 4.25%. The peritoneal dialysis dialysate may include, for example, the Dianeal®, Physioneal®, Nutrineal®, and Extraneal® dialysates sold by the assignee of the present disclosure. The dialysate may additionally or alternatively include a percentage of icodextrin.

[0184] In both hemodialysis and peritoneal dialysis, "sorbent" technology is used to remove uremic toxins from spent dialysate, reinfuse therapeutic agents (e.g., ions and / or glucose) into the treated fluid, and then reuse that fluid to continue dialysis for the patient. A commonly used sorbent is made of zirconium phosphate and is used to remove ammonia produced by the hydrolysis of urea. Typically, large amounts of sorbent are required to remove the ammonia produced during dialysis treatment.

[0185] Example weighing scale 106 includes any device configured to measure the mass of a patient or treatment component. For example, weighing scale 106 can measure patient weight before, during and / or after renal failure treatment. Additionally or alternatively, weighing scale 106 can measure a supply or drainage bag for tracking renal failure treatment. Specifically, weighing scale 106 can be used to measure the amount of UF removed or the amount of fluid provided to the patient. Weighing scale 106 can display a digital value indicating weight. Alternatively, weighing scale 106 can display a physical scale or dial aligned with a mark to indicate the measured weight. In some embodiments, weighing scale 106 can store weight values ​​before, during and / or after treatment in a separate window, so that when recording medical information, patient input is required to view all values.

[0186] The example blood pressure monitor 104 includes any device configured to measure the patient's blood pressure and / or pulse. For example, the blood pressure monitor 104 can measure the patient's blood pressure before, during and / or after the treatment of renal failure. The blood pressure monitor 104 can display a digital value indicating the patient's blood pressure. Alternatively, the blood pressure monitor 104 can display a physical scale using a dial aligned with the numerical value to indicate the measured blood pressure. In some embodiments, the blood pressure monitor 104 can store the blood pressure values ​​before, during and / or after the treatment in a separate window, so that when recording medical information, the patient needs to enter to view all values. The blood pressure monitor 104 can be integrated with the home treatment device 90. In another embodiment, the blood pressure monitor 104 may include a wearable sensor, such as a smart watch or a fitness tracking device.

[0187] In addition to obtaining medical information (eg, medical device data) from the medical devices 90 , 104 , and 106 , the example personal mobile communication device 200a may also obtain medical information from the patient and / or therapeutic consumables 1006 . Fig.10 An example of consumables 1006 is shown, which includes, for example, renal failure treatment medical device filters, disposable boxes, blood pipeline sets, drug delivery pipeline sets, and containers (e.g., dialysate concentrate containers, blood anticoagulant containers, drug containers, and / or clean water containers). Consumables 1006 may also include sorbent boxes or any other disposable or material supplies for medical treatment. Consumables may include identifiers 1008, which are configured to provide medical information in the form of consumption information or consumption data. For example, identifiers 1008 may include information identifying the type of consumables, serial numbers, and / or properties of consumables. In some cases, consumables 1006 may also include labels containing medical information (such as chemical composition properties). Patients or clinicians use personal mobile communication devices 200a to record images of identifiers 1008, images of labels on consumables 1006, and / or images of consumables 1006 themselves to record materials used during treatment.

[0188] The personal mobile communication device 200a can be communicatively coupled to the home therapy device 90, the blood pressure monitor 104, and / or the weight scale 106 via a wired connection (e.g., a USB connection) or a wireless connection (e.g., Bluetooth™, WiFi™, Zigbee®, Z-Wave®, wireless USB, or a wireless local area network (“WLAN”)). In other examples, the personal mobile communication device 200a is not communicatively coupled to any of the home therapy device 90, the blood pressure monitor 104, and / or the weight scale 106. In these other examples, the patient can manually enter the data displayed by the home therapy device 90, the blood pressure monitor 104, and / or the weight scale 106 into the personal mobile communication device 200a. Additionally or alternatively, in these other examples, the patient can use the camera 1004 of the personal mobile communication device 200a to record one or more images of the data (or identifiers placed thereon) displayed by the home therapy device 90, the blood pressure monitor 104, and / or the weight scale 106.

[0189] The blood pressure monitor 104 and the weight scale 106 are collectively referred to as medical devices. It should be appreciated that the medical fluid data transmission system 1000 may include additional medical devices, such as an infusion pump (e.g., a syringe pump, a linear peristaltic pump, a large volume pump ("LVP"), an ambulatory pump, a multi-channel pump), an oxygen sensor, a respiratory monitor, a blood glucose meter, a blood pressure monitor, an electrocardiogram ("ECG") monitor, a weight scale, and / or a heart rate monitor. In other examples, the medical fluid data transmission system 1000 may include fewer medical devices and / or integrated medical devices (e.g., a blood pressure monitor 104 integrated with a home therapy device 90).

[0190] In some embodiments, the personal mobile communication device 200a is configured to record, display and / or fill in a patient's medical record with medical information or data. As disclosed herein, medical information or data includes medical device data and patient data, which may refer to data or information created, generated or otherwise associated with a medical device, a patient and / or consumables used by a medical device. For example, medical information includes prescription or programming information used by a medical device to manage treatment. Medical information also includes sensed data such as fluid pressure, flow rate, conductivity, concentration, temperature and patient data. As provided herein, patient data (e.g., vital signs data) includes sensed patient physiological information such as patient blood pressure, weight, heart rate, etc. Medical information may also include subjective information, such as information about the patient's feelings (e.g., tiredness, fatigue, happiness, excitement, etc.). Medical information may be displayed on a screen of a medical device, provided by a physical dial or display of a medical device, or printed on an attached label or medical device. Therefore, medical device data or medical information includes medical device settings, medical device readings and / or patient readings.

[0191] Medical information also refers to information contained on an identifier on a patient or treatment consumable. Specifically, medical information may include information conveyed by a patient identifier provided on a patient wristband for identifying the patient. Medical information also includes information about consumables, which may identify the type of consumable, the model of the consumable, and / or the properties of the consumable, such as the glucose level in a supply bag of a renal failure treatment solution.

[0192] Treatment Data or Treatment Information means Figures 1 to 10 The data generated and / or sent by the home therapeutic device 90. The therapeutic information may include the amount of fluid injected, the amount of ultrafiltration UF removed from the patient and / or the treatment time. The therapeutic information may also include alarms, reminders and / or diagnostic information generated by the home therapeutic device 90. Typically, the therapeutic information is transmitted from the home therapeutic device 90 to the clinician server 200b. In some embodiments, the therapeutic information may be recorded in the personal mobile communication device 200a. In these embodiments, the therapeutic information may be referred to as and / or included / processed as medical information.

[0193] like Fig.10 As shown, some of all medical devices 90, 104, and 106 may include an identifier 1012 configured to store a unique identification number. The identifier 1012 may encode, for example, a designated device number, serial number, hardware number, model, and / or device type of each medical device 90, 104, and 106. For example, the identifier 1012b of the home treatment device 90 may store a designated device number. The personal mobile communication device 200a reads the identifier 1012b to determine, for example, the type of medical device for subsequent analysis and identification of medical information in images recorded from the screen of the machine 90. In some embodiments, the identifier 1012 may more generally indicate the model or type of the medical device. For example, the identifier 1012c may indicate that the device 106 is a weight scale and / or indicate the model of the weight scale.

[0194] The identifier 1012 may include a machine-readable mark, such as a barcode or a quick response ("QR") code. The identifier 1012 may also include human-readable text, such as a serial number, an asset number, or a hardware number. In some embodiments, the identifier 1012 may be printed on an item physically attached to the housing of the corresponding medical device 90, 104, and 106, such as the identifier 1012b shown for the home treatment device 90. Additionally or alternatively, the identifier 1012 may be displayed on the screen of some of all medical devices 90, 104, and 106. For example, a clinician may select a control interface to cause the home treatment device 90 to display a window with the identifier 1012b on the screen. In other embodiments, the identifier 1012 may be included in a radio frequency ("RF") microchip, such as an RFID chip or an NFC chip.

[0195] The example medical devices 90, 104 and 106 may also include one or more control interfaces for providing control instructions. For example, the home treatment device 90 includes a control interface 1014. The control interface may include a button, a control panel or a touch screen. The control interface may be configured to enable a user to navigate to a certain window or user interface on the screen of the corresponding medical device 90, 104 and 106. The control interface may also provide instructions for operating or controlling the corresponding medical device 90, 104 and 106.

[0196] like Fig.10 As shown, the exemplary fluid data transmission system 1000 includes a Web portal 150, a system hub 120, and a clinician server 200b (similar to the combination of Figures 1 to 9 The web portal 150, system hub 120 and / or clinician server 200b transmit medical information from the patient's medical record (stored in the clinician database 1010) to the personal mobile communication device 200a. In addition, the web portal 150, system hub 120 and / or clinician server 200b can provide access to educational materials or a live help session with a clinician to the personal mobile communication device 200a. The example web portal 150, system hub 120 and / or clinician server 200b are also configured to enable the personal mobile communication device 200a to provide medical information for filling out the patient's medical record.

[0197] Fig.10 The example fluid data transmission system 1000 further includes a connection server 118, which is communicatively coupled to the home treatment device 90. Figures 1 to 9As discussed, the connection server 118 provides two-way communication between the home therapy device 90 and the clinician server 200b and / or the clinician database 1010. The home therapy device 90 may connect to the connection server 118 via the Internet.

[0198] exist Fig.10 In the illustrated example, the example personal mobile communication device 200a includes a processor 1016 in communication with a memory 1018 storing instructions. At least some of the instructions define or specify an application 1002 that, when executed by the processor 1016, causes the processor 1016 to provide features that improve patient engagement and / or compliance with treatment. The processor 1016 may include digital and analog circuits configured as a microprocessor, an application specific integrated circuit ("ASIC"), a controller, etc. The memory 1018 includes volatile or non-volatile storage media. In addition, the memory 1018 may include any solid-state or disk storage media.

[0199] As discussed in more detail below, features of application 1002 include displaying treatment progress information, controlling which treatment programs are run by the home treatment device 90, recording medical information, displaying teaching materials, and / or initiating a help session with a clinician. Application 1002 can be feature-rich or feature-reduced. Feature-rich applications are configured for smartphones that utilize native graphics, touch screens, and processing capabilities of personal mobile communication devices 200a. Reduced-function applications are configured to run on cell phones with relatively less complex graphics and reduced processing capabilities. Cell phones may also not include a touch screen, or may have a touch screen with limited functionality.

[0200] In some embodiments, the personal mobile communication device 200a may not include the application 1002. Instead, the personal mobile communication device 200a may use a native or other installed application to communicate with the clinician server 200b. For example, the personal mobile communication device 200a may use a text, SMS or email program to communicate with the clinician server 1020.

[0201] The example clinician server 200b includes an application 1020, such as a Figures 1 to 9The application 230 described. The application 1020 is configured to communicate with the personal mobile communication device 200a to provide improved patient engagement and / or compliance. In some embodiments, the example application 1020 is configured to facilitate storage of medical information (recorded by the personal mobile communication device 200a) to one or more medical records in the database 1010. The application 1020 may also include one or more interfaces or application programming interfaces ("APIs") to provide treatment progress data and / or medical information to the application 1002 for display on a display interface 1022 (e.g., a touch screen) of the personal mobile communication device 200a. The application 1020 on the clinician server 200b may also provide educational materials upon receiving a request from the application 1002, and / or facilitate a communication session between the personal mobile communication device 200a and the clinician device 152.

[0202] In some cases, the application 1002 on the personal mobile communication device 200a and / or the application 1020 on the clinician server 200b is configured to convert medical information, or otherwise provide medical information to the clinician database 1010 of other devices in the medical fluid data transmission system 1000 that conforms to the Health Level 7 ("HL7") standard (e.g., a medical standard). This conversion enables the medical information to be stored in the HL7 format, regardless of the format in which it was entered on the personal mobile communication device 200a. When there are gaps in the network or device connection, the application 1002 and / or the application 1020 can be used as a network conduit to seamlessly propagate relevant medical information from the medical device to the patient's medical record.

[0203] Fig.11 The embodiment according to the present disclosure is shown Fig.10 FIG. 1020 is a diagram of the operation modules of the application 1020 at the clinician server 200b. The application 1020 may include a registration module 1102 configured to register a patient medical record stored in a specific patient and / or clinician database 1010 with the home treatment device 90 and / or the personal mobile communication device 200a. Fig.12 In more detail, registration may include determining the type of personal mobile communication device 200a that is formatted for subsequent communications.

[0204] The application 1020 may also include a data acquisition module 1104 configured to receive treatment and / or medical information from a registered home treatment device 90 and / or a personal mobile communication device 200a. In addition, the application 1020 may include a data access module 1106 to send or otherwise provide access to medical information stored in one or more medical records associated with the patient. The application 1020 may also include an education module 1108 configured to provide the patient with access to educational materials or help documents about the patient's treatment and / or the operation of the home treatment device 90. In addition, the application 1020 may include a treatment control module 1110 that enables the patient (or clinician) to change (or modify) the treatment program performed by the home treatment device 90. The application 1020 may additionally include an auxiliary module 1112 that creates a real-time communication session between the personal mobile communication device 200a and the clinician device 152.

[0205] Each of the example modules 1102 to 1112 is configured to improve patient engagement in medical fluid delivery therapy, thereby increasing patient compliance with prescribed therapy. It should be appreciated that although modules 1102 to 1112 are shown, the example application 1020 may include fewer or additional modules. For example, in some embodiments, the education module 1108 and the auxiliary module 1112 may be omitted. The following sections provide further descriptions of each of the modules 1102 to 1112.

[0206] As described below, each of the modules 1102 to 1112 is configured to communicate with the personal mobile communication device 200a and / or the clinician device 152. In some embodiments, communications from the personal mobile communication device 200a can be addressed to the clinician server 200b, the web portal 150, the connection server 118, and / or the system hub 120. Messages can be internally routed to different modules 1102 to 1112 based on content and / or identifiers. For example, the application 1002 can provide an identifier in a header to specify which module in the modules 1102 to 1112 receives the message. For text-based messages, a router at the clinician server 200b can determine the destination module 1102 to 1112 based on the message content or a previous message. For example, the router can determine that the received message corresponds to a message previously sent by the data acquisition module 1104. Based on the correspondence, the router sends the received message via the data acquisition module 1104 for processing.

[0207] A. Registration module implementation

[0208] The example registration module 1102 is configured to register the personal mobile communication device 200a and / or the home treatment device 90 with the patient's medical records stored in the clinician server 200b and / or the database 1010. The example registration module 1102 is configured to provide different types of registrations, which are used by the data access module 1106 to determine how to display information to the patient based on what type of device is registered. In addition, the data acquisition module 1104 determines how to obtain treatment and / or medical information based on the registration information.

[0209] The registration module 1102 is configured to store the registration information in a registration file stored in the clinician database 1010. The registration file may specify, for each patient or patient activation code ("PAC"), information indicating a registered personal mobile communication device 200a, information indicating a registered home therapy device 90, and / or an indication of whether the application 1002 is installed on the personal mobile communication device 200a. In some embodiments, the registration file (or information from the registration file) may be included in the patient's medical record.

[0210] In some embodiments, there are different registration scenarios. For example, a patient can register a personal mobile communication device 200a by downloading the application 1002, while also registering a home treatment device 90. In this case, the registration module 1102 records that the patient has installed the application 1002 on the personal mobile communication device 200a, and has registered the home treatment device 90 (alone or through the application 1002). Based on the registration, the data acquisition module 1104 determines that the application 1002 installed on the registered personal mobile communication device 200a will guide or otherwise prompt the patient to obtain medical information. In addition, the data acquisition module 1104 determines that the treatment information will be received from the home treatment device 90 instead of via the personal mobile communication device 200a. Therefore, the data acquisition module 1104 can send a message to the application 1002 to disable the user interface for obtaining treatment information from the home treatment device 90 (but still enable the user interface for manual exchange, if so specified for the patient). If the home treatment device 90 is not registered, the data acquisition module 1104 causes the application 1002 to display a user interface to obtain treatment information from the home treatment device 90 in the application 1002. By registering, the data access module 1106 determines that the information will be displayed by the application 1002, and accordingly uses the API and / or other data to read components that are compatible with or configured for the application 1002.

[0211] If the patient registers without downloading and / or installing the application 1002, the data acquisition module 1104 determines that data acquisition will be prompted or guided. For example, the data acquisition module 1104 can send a text message and / or email to the registered personal mobile communication device 200a, prompting the patient for certain medical information and / or treatment information (if the home treatment device 90 has not yet been registered). The information in the message specifies which data is needed from the patient. Although this remote guidance can be used for a streamlined personal mobile communication device 200a, it can also be used for a smartphone where the patient does not want to download or install the application 1002 on a feature-rich device.

[0212] If the application 1002 is not installed, the data access module 1106 can also be configured to display information from the patient's medical record differently. For example, in addition to sending data inserted into a well-defined, feature-rich user interface, the data access module 1106 can render the data in a picture that is transmitted to the personal mobile communication device 200a via text for viewing. Additionally or alternatively, the data access module 1106 can transmit the stored medical record information as text to the personal mobile communication device 200a. Therefore, even if the application 1002 is not installed, the application 1020 on the clinician server 200b is configured to provide the patient with access to the data using the native application on the personal mobile communication device 200a.

[0213] Fig.12 An exemplary embodiment according to the present disclosure is shown. Fig.10 and 11 FIG. 1 is a diagram of the communication between the home treatment device 90, the personal mobile communication device 200a and the clinician server 200b. First, the home treatment device 90 is connected to the clinician server 200b via Fig.11 The registration module 1102 of the clinician server 200b is registered with the clinician server 200b. Otherwise, the clinician server 200b will not have information about which medical record data from the home treatment device 90 is to be stored. In some embodiments, the home treatment device 90 is pre-programmed with destination address information for connecting to the server 118, the system hub 120 and / or the clinician server 200b. The destination address may include an Internet Protocol ("IP") address and / or a Hypertext Transfer (or Transport) Protocol ("HTTP") address.

[0214] During setup, the patient (or clinician) enters a patient activation code ("PAC") into the home therapeutic device 90. The PAC is initially generated and stored at the clinician server 200b and is provided to the patient when the patient receives the home therapeutic device 90. The PAC may include a patient identifier or other unique code for the patient. The registration module 1102 at the clinician server 200b stores the generated PAC to one or more medical records and / or registration files associated with the patient. After entering the PAC, the home therapeutic device 90 generates and transmits a message 1202 including the PAC. The message may also include a hardware identifier of the home therapeutic device 90 and / or an IP address assigned to the home therapeutic device 90. The home therapeutic device 90 sends the message 1202 to a preprogrammed address, in this case the connection server 118. The example connection server 118 relays the message 1202 to the system hub 120, which routes the message to the clinician server 200b. The registration module 1102 at the clinician server 200b registers the home therapeutic device 90 with the patient using the PAC. Registration includes, for example, associating an identifier of the home treatment device 90 with the patient's medical record. Registration may also include the clinician server 200b storing the IP address of the home treatment device 90 so that messages can be transmitted to the home treatment device 90. After registration, the data acquisition module 1104 of the clinician server 200b stores the treatment information received from the home treatment device 90 to one or more medical records associated with the patient.

[0215] The example personal mobile communication device 200a is also configured to register with the clinician server 200b via the registration module 1102. In order to register, the personal mobile communication device 200a can download or otherwise receive the application 1002 from the clinician server 200b (or a third-party application store) via one or more messages 1204. In an embodiment, during the registration of the home treatment device 90, the patient (or clinician) can provide the phone number of the personal mobile communication device 200a. The registration module 1102 uses the phone number to transmit the message 1204 as a text message. The message may include a hyperlink to a location (e.g., a database 1010 or a third-party website) that provides the application 1002 for downloading to the personal mobile communication device 200a. In other cases, the message 1204 may include an attachment that, when executed, installs the application 1002 on the personal mobile communication device 200a. In addition to providing a phone number, the patient may provide an email address during the registration of the home treatment device 90. Accordingly, the message 1204 includes an email message with a file or hyperlink for installing the application 1002 on the personal mobile communication device 200a.

[0216] In another embodiment, message 1204 can enable the patient to register in two different ways according to the capabilities and / or personal preferences of personal mobile communication device 200a. Message 1204 includes text, which prompts the patient to respond to the text if they wish to register their personal mobile communication device 200a as a streamlined device. A reply to message 1204 is provided via text message 1206, which is routed to registration module 1102. Then, registration module 1102 registers personal mobile communication device 200a using an indication that application 1002 is not installed. In some cases, message 1204 may also include text or hyperlinks to prompt the patient to select a hyperlink, or if it is desired to obtain an application in other ways. Message 1204 may also provide prompts or options to select a device type, such as an Apple® device or an Android® device. During the registration process, registration module 1102 registers personal mobile communication device 200a based on information provided by the patient and / or information read from personal mobile communication device 200a.

[0217] After installing the application 1002, the patient can register the personal mobile communication device 200a. In an embodiment, to register, the patient completes a registration form or field provided by the application 1002. The form or field is configured to accept the patient's PAC. The form or field may also include prompts for the patient's name, email address, home address, phone number, etc. The information from the form or field is sent to the web portal 150 in one or more messages 1206, which transmit the message 1206 to the system hub 120 for routing to the clinician server 200b. The message 1206 may also include device type information of the personal mobile communication device 200a (as determined by the application 1002).

[0218] In some cases, the application 1002 may be configured with a destination address of the web portal 150, which is used to transmit the message. In other examples, the message 1206 may be provided to an API at the web portal 150 for registering the application 1002 at the clinician server 200b. In other cases, the application 1002 sends the message 1206 as one or more text messages or email messages to the web portal 150 (wherein the web portal 150 is assigned a phone number, IP address, email address, or other address). The example registration module 1102 uses the PAC within the message 1206 to register the personal mobile communication device 200a with the medical record and / or registration file stored in the database 1010. At this point, both the home treatment device 90 and the personal mobile communication device 200a are registered to the same patient at the clinician server 200b.

[0219] As described above, in some embodiments, the personal mobile communication device 200a may not include an application. In these embodiments, the personal mobile communication device 200a may communicate with the clinician server 200b via a text message or through a web browser. Accordingly, the registration module 1102 of the clinician server 200b may send a text message to the personal mobile communication device 200a, which has a hyperlink to a database or web page to complete the registration. Alternatively, the text message may include a prompt for the patient to respond with his PAC. Providing a PAC via any of these registration processes enables the registration module 1102 to associate the personal mobile communication device 200a (e.g., a phone number, a hardware address, or an IP address) with an appropriate patient medical record and / or registration file.

[0220] B. Data Acquisition Module Embodiment

[0221] Fig.12 Also shown is data communication between the home therapy device 90, the personal mobile communication device 200a, and the clinician server 200b. During operation, the home therapy device 90 generates treatment information and status information (e.g., medical information). Figures 1 to 9 As discussed, treatment information includes the amount of fluid injected, the amount of ultrafiltration ("UF") removed from the patient, and / or treatment time. Status information includes alarms, reminders, or diagnostic information. Before and after treatment, the home treatment device 90 generates one or more messages 1208 with medical information, which are transmitted to the connection server 118. In turn, the connection server 118 routes the message 1208 to the system hub 120, which routes the message 1208 to the data acquisition module 1104 of the clinician server 200b. Upon receipt, the data acquisition module 1104 stores the medical information in the patient's medical record (e.g., Fig.13 The message 1208 may include an identifier or address of the home treatment device 90, which is used by the data acquisition module 1104 to locate the appropriate medical record in the database 1010.

[0222] The example home therapy device 90 can be configured to use metadata or other data identification techniques to encode, tag, or otherwise identify the medical information being transmitted. The encoding or tagging enables the data acquisition module 1104 (or the interface at the server 200b) to determine the context of the medical information to write the medical information to the appropriate field of the medical record. Additionally or alternatively, the encoding or tagging can also be stored in the record, which is then used to search and display the medical information.

[0223] Fig.12It is also shown that the personal mobile communication device 200a transmits medical information or transmits medical information to the clinician server 200b. As described in more detail below, the personal mobile communication device 200a is configured to obtain medical information from devices including devices 90, 104 and 106. Acquiring medical information may include receiving information manually input by the patient via a wired or wireless connection, and / or processing images recorded by the camera 1004 of the personal mobile communication device 200a. The acquired medical information is packaged into one or more messages 1210 and transmitted to the web portal 150 by the personal mobile communication device 200a. The message 1210 can be a text message, an email message, or a web-based message (e.g., an HTTP message, an extensible markup language ("XML") message, a JavaScript object notation ("JSON") payload, etc.). In some embodiments, the personal mobile communication device 200a can format the acquired medical information into one or more data fields before transmission. Typically, the structure of the medical information acquired in the personal mobile communication device 200a is less than the structure of the medical information generated by the home treatment device 90. Thus, the data acquisition module of the personal mobile communication device 200a and / or the clinician server 200b performs at least some processing of the medical information to provide the appropriate context or structure for inclusion within the patient medical record. Examples of the processing performed are described in further detail below.

[0224] Fig.13 According to an example embodiment of the present disclosure, the Fig.10 1010. The patient data structure 1300 includes separate medical records for different patients. In the example shown, the data structure 1300 includes a patient medical record 1302 for a patient associated with an identifier "DCM31913" and a patient medical record 1304 for a patient associated with an identifier "GAM41215". The data structure 1300 may include additional patient medical records.

[0225] like Fig.13As shown, each medical record 1302 and 1304 includes data fields that identify the patient, the personal mobile communication device 200a, and the home treatment device 90. For example, the medical records 1302 and 1304 include data fields for the patient identifier, the type of personal mobile communication device 200a, the type of home treatment device 90, and the home treatment device identifier (received via registration). The patient identifier may correspond to the PAC assigned to the patient. The medical records 1302 and 1304 may include additional fields for the patient's name, address, gender, date of birth, etc. The medical records 1302 and 1304 may further include fields for the network address of the personal mobile communication device 200a and / or the home treatment device 90. In some embodiments, the data access module 1106 of the application 1020 uses the information in the device type field to determine how to present and / or send treatment information and medical information to the personal mobile communication device 200a.

[0226] Likewise Fig.13 As shown, medical records 1302 and 1304 include fields for treatment and medical information. The data acquisition module 1104 stores the treatment information in the medical records 1302 and 1304 received from the corresponding home treatment device 90. In addition, the data acquisition module 1104 stores the medical information in the medical records 1302 and 1304 received from the corresponding personal mobile communication device 200a. In some embodiments, the data field is further divided into separate fields for data types. For example, medical records 1302 and 1304 may include treatment information fields for the amount of fluid injected, the amount of ultrafiltration ("UF") removed from the patient, and / or the treatment time. Medical records 1302 and 1304 may also include data fields for reminders or alarms generated during treatment, and / or data fields for alarms or reminders determined in the clinician server 200b based on treatment information and / or medical information. Medical records 1302 and 1304 may further include medical information of the patient's weight and / or blood pressure recorded before, during, and / or after treatment.

[0227] Treatments and / or medical devices may be organized by treatment, date / time of generation, and / or date / time of receipt. In some embodiments, medical records 1302 and 1304 may store communications from patients. Communications may include pictures or videos related to treatments or questions about treatments recorded by personal mobile communication device 200a. Communications may also include text messages, emails, etc. about treatment assistance sent from personal mobile communication device 200a. In addition, communications may include information related to requests to change or modify treatments from personal mobile communication device 200a and / or clinician device 152. Typically, medical records 1302 and 1304 are configured to store information that improves patient participation in treatment in addition to archiving treatment results and information related to patient participation in treatment through clinician server 200b.

[0228] The data received by the example data acquisition module 1104 varies based on the source. For example, the treatment information received from the home treatment device 90 is usually constructed. In other words, the home treatment device 90 is configured to transmit treatment information, which is formatted for direct entry into one or more fields of the patient's medical record. In some embodiments, the home treatment device 90 formats the message for transmission through the API of the data acquisition module 1104 (or accesses one or more APIs) to fill the treatment information into the appropriate data fields. In contrast, the medical information recorded by the patient's personal mobile communication device 200a may not initially be structured to be included in the patient's medical record. The application 1002 of the personal mobile communication device 200a and / or the data acquisition module 1104 of the clinician server 200b can use different technologies to process and / or format the medical information to fill it into the medical record, as described in more detail below.

[0229] 1. Manually input medical information into the application example

[0230] To receive structured information, in some embodiments, the example application 1002 of the personal mobile communication device 200a is configured to display a prompt indicating what medical information is needed to be filled out by the patient in the patient's medical record. The example application 1002 may include a routine or algorithm that specifies which fields are to be displayed to prompt for medical information from the patient. In some embodiments, the fields or screens displaying the fields are arranged and / or sorted in relation to the medical fluid delivery treatment. The display of the fields informs the patient what medical information is needed regarding the medical record.

[0231] Fig.14 and 15 A diagram illustrating a user interface of an application 1002 is shown that enables a patient to input medical information for transmission to a data acquisition module 1104. Specifically, Fig.14 The user interface 1400 prompts the patient with blood pressure information, and Fig.15 The user interface 1500 of the personal mobile communication device 200a prompts the patient about medical fluid delivery information (e.g., treatment information). It should be appreciated that the application 1002 of the personal mobile communication device 200a can display other user interface screens that enable the patient to manually enter medical information. For example, the application 1002 can display user interface screens for blood glucose level, patient temperature, patient weight, etc.

[0232] In some embodiments, the patient may manually enter some medical information in the user interface 1400 or 1500 while wirelessly acquiring other medical information or recording some medical information via images. In these configurations, the application 1002 may be configured to enable the patient to select a source for information input. The patient may manually enter medical information after selecting a manual source from a menu of available data input methods or by default.

[0233] After receiving the medical information manually entered by the patient, the example application 1002 transmits the medical information to the data acquisition module 1104 to be filled into the patient's medical record. The application 1002 and the user interfaces 1400 and 1500 are configured so that the data fields for receiving the medical information are aligned with the data fields in one or more medical records. In some examples, the data fields can correspond to one or more APIs at the data acquisition module 1104 for writing the medical information directly into the designed data fields of the patient's medical record. Accordingly, the user interfaces 1400 and 1500 of the application prompt the patient for the medical information in a structured manner so that the medical information does not need to be identified or formatted.

[0234] In some embodiments, the application 1002 may be configured to display the user interfaces 1400 and 1500 at a designed time. For example, the application 1002 may include a calendar that includes the time / date for scheduling treatment. At a designed time (e.g., 5 minutes, 15 minutes, 30 minutes, etc.) before treatment, the example application 1002 is configured to cause the personal mobile communication device 200a to display the user interface 1400, prompting the patient with blood pressure medical information. The prompt informs the patient that a blood pressure measurement is required before treatment begins. Accordingly, the patient uses the blood pressure monitor 104 to measure blood pressure. The patient then enters the measurement into the user interface 1400 before treatment begins.

[0235] In the illustrated embodiment, the user interface 1400 includes a systolic data field 1402, a diastolic data field 1404, and a pulse data field 1406. The patient can select a corresponding data field 1402, 1404, or 1406 to cause the application 1002 to display a text input function to enter a value. The user interface 1400 also includes a field 1408 that enables the patient to specify whether the blood pressure measurement is taken while standing or sitting. In addition, the user interface 1400 includes a data field 1410 that enables the user to specify the date / time at which the blood pressure measurement is to be performed.

[0236] In some examples, the patient can select any of fields 1402 to 1410 to receive more information about performing the corresponding measurement. For example, the patient can select the systolic blood pressure data field 1402, which causes the application 1002 to display a tutorial instructing the patient how to perform a blood pressure measurement and identify the systolic blood pressure measurement value. The tutorial can include text, text / pictures, audio recordings, animations, and / or videos. The tutorial can be stored locally as part of the application 1002 or stored on the clinician server 200b for remote access or streaming.

[0237] Fig.15 The user interface 1500 is configured to be displayed by the application 1002 when a patient is scheduled to perform a manual exchange therapy, and / or if the home therapy device 90 is not registered with the clinician server 200b. Manual renal failure exchange therapy requires the patient to connect a dialysate container to their peritoneal cavity for a sustained period of time, without the aid of a machine, before allowing the spent dialysate to drain. For manual therapy, the patient is required to enter their manual exchange medical information so that their medical records can reflect accurate treatment information.

[0238] The example application 1002 can also be configured to display the user interface 1500 when the patient has not registered the home treatment device 90. During registration, the registration module 1102 can send a message to the application 1002 indicating whether the home treatment device 90 has been registered. If the home treatment device has not been registered, the application 1002 can be configured to display the user interface 1500 and / or other user interfaces to obtain treatment information that can generally be transmitted by the home treatment device 90.

[0239] In the example shown, the user interface 1500 includes a progression of treatment, including a solution phase, a drain phase, a fill phase, a UF or dwell phase, and a summary phase. The application 1002 can display a separate user interface for each phase, prompting the patient to enter the corresponding or requested treatment information. The example user interface 1500 corresponds to the UF phase, as shown by the highlighted box 1502. The user interface 1500 includes a drain volume field 1504, a UF field 1506, and a fill volume field 1508. In the example shown, the user interface 1500 prompts the patient to enter the drain volume into the data field 1504 during the drain phase, and prompts the patient to enter the fill volume into the data field 1508 during the fill phase. The user interface 1500 can calculate a UF value for the UF data field 1506, or prompt the patient for the value.

[0240] In addition to displaying user interfaces 1400 and 1500 at a designed time, application 1002 may cause an alert to be displayed on the personal mobile communication device 200a. The alert may identify which medical information is needed, or include a link to either of user interfaces 1400 or 1500. The alert may include a pop-up window displayed by the personal mobile communication device 200a. The alert may also include an icon displayed adjacent to the icon of application 1002 on the home screen of the personal mobile communication device 200a. In other embodiments, application 1002 may not notify the patient which medical information is needed. Instead, application 1002 may enable the patient to navigate to the desired user interface to enter medical device data and / or treatment information.

[0241] In some embodiments, the application 1002 may identify at least some of the data fields of one or more user interfaces as required to be entered, while other data fields are optional. The application 1002 may outline or otherwise graphically indicate which data fields are required (e.g., displaying a red box around the systolic blood pressure data field 1402). If the required data fields are not completed or are not completed within a certain time, the application 1002 may cause the personal mobile communication device 200a to display a reminder message. In some embodiments, the application 1002 may prevent the patient from navigating to another user interface until all required fields are filled in for the currently viewed user interface.

[0242] After the patient enters the medical information into one or more of the interfaces 1400 and 1500, the application 1002 transmits the medical information to the data acquisition module 1104 of the clinician server 200b for entry into the patient's medical record. The application 1002 is configured to transmit the medical information after the patient completes the data fields in the user interface or otherwise presses a send button on the interface. In other cases, the application 1002 can transmit the medical information at a predetermined time, such as before and after treatment.

[0243] 2. Wireless input of medical information into application examples

[0244] In some embodiments, the patient may choose to enter medical information wirelessly in their personal mobile communication device 200a. The medical information may be received in the personal mobile communication device 200a via, for example, a Bluetooth® connection, a Zigbee® connection, a Z-Wave® connection, a wireless USB connection, a wireless RF connection, an NFC connection, an infrared connection, or any other suitable wireless communication technology. In some cases, the patient may have to wirelessly pair the personal mobile communication device 200a with a medical device (such as a blood pressure monitor 104 and / or a weight scale 106). In other embodiments, the patient activates a connection application (e.g., an NFC application) that wirelessly reads the medical information from the medical device.

[0245] In an example, a patient may pair their personal mobile communication device 200a with the blood pressure monitor 104. To input blood pressure medical information into Fig.14 In the user interface 1400 of FIG. 1402 , the user selects, for example, the systolic blood pressure data field 1402. The selection of field 1402 causes the application 1002 to display a prompt asking the patient to select a data entry method (e.g., manual, wireless, photo, etc.). After selecting the wireless option, the application 1002 displays a menu of available wireless connection options and / or a list of paired Bluetooth® devices. The patient selects a blood pressure monitor 104 from the list, which causes a menu of available medical information to be displayed. The patient selects systolic blood pressure, which causes the systolic blood pressure value to be populated into the systolic blood pressure data field 1402. In some embodiments, the application 1002 is configured to read the medical information from the blood pressure monitor 104 after the patient selects the device. The application 1002 can use data tags or metadata to determine which of fields 1402 to 1410 to populate with medical information from the blood pressure monitor 104.

[0246] In some embodiments, the application 1002 is configured to enable the patient to establish a permanent or semi-permanent connection with the medical device. During the setup operation, the application 1002 prompts the patient to select a data field from the user interface 1400. After the selection, the application 1002 prompts the patient to select a paired wireless medical device (and / or select a data type from a menu associated with the medical device). The patient's selection configures the application 1002 to automatically read medical information from the blood pressure monitor 104, for example, when new medical information is available. In other words, the application 1002 is configured to automatically wirelessly access a remote medical device to read certain medical information to fill in one or more data fields. For example, after the patient uses the blood pressure monitor 104 to take a blood pressure measurement, the monitor 104 sends a check or status message indicating that new data is available to the application 1002. Alternatively, the application 1002 can poll or otherwise check the blood pressure monitor 104 to determine whether new data is available. Then, the application 1002 reads the new data into one or more fields in the data fields 1402 to 1410 to automatically fill in the user interface 1400. The application 1002 then sends the medical information to the data acquisition module 1104 of the clinician server 200b to automatically update the patient's medical record.

[0247] 3. Enter medical information images into the application implementation example

[0248] The example application 1002 on the personal mobile communication device 200a is configured to enable the patient to enter medical information and / or treatment information by recording an image of a medical device or a screen of a medical device. The personal mobile communication device 200a uses a camera 1004 to record one or more images. The application 1002 uses optical character recognition ("OCR") to extract text from the recorded image. The extracted text is filled in one or more data fields of the user interface of the application 1002. Using images can reduce data entry errors from patients or clinicians.

[0249] In some embodiments, application 1002 uses rules or data templates to identify which text from the image can be selected as relevant medical information for the data field. Otherwise, simply using the OCR function makes all displayed text selectable. In this way, the patient still has to copy and paste the text from the image into the data field. In contrast, rules or data templates can group or identify the text in the image as fields, which allows the patient to easily select or automatically select to fill in the data field in the user interface.

[0250] The data templates or rules of application 1002 are configured to organize or otherwise decode text extracted from the image. Application 1002 determines or otherwise selects one or more data templates for establishing the context of the medical information based on, for example, the location of the medical information within the image and / or the tags / keywords included within the medical information. In order to determine the data template, the example application 1002 may prompt the patient to specify the type of medical device from which the image was recorded. Additionally or alternatively, application 1002 enables the patient to select a medical device template. In other embodiments, the patient may first record an image of an identifier 1012 (e.g., an identifier image), which application 1002 uses to determine the type, model, etc. of the corresponding medical device. Then, application 1002 selects a data template or rule corresponding to the type, model, screen, etc. of the medical device.

[0251] The data template defines or specifies data fields for certain medical information contained in the image. Typically, the image includes extracted text consisting of medical information. In some cases, not all of the extracted medical information is required or necessary. Instead, only certain medical information in the recorded image needs to be entered into the data fields of the user interface or patient's medical record. Related medical information or related medical information refers to medical device data or medical information identified or selected for filling into the data fields of the user interface of application 1002, or more generally, for filling into the patient's medical record.

[0252] Fig.16A schematic diagram of a personal mobile communication device 200a for recording and processing images for medical information extraction according to an example embodiment of the present disclosure is shown. The illustration of the personal mobile communication device 200a is exemplary, and some blocks may be combined, further divided, or removed. In addition, in some embodiments, the personal mobile communication device 200a may include additional blocks such as a memory 1018 storing instructions that, when executed by the data processor 1602 (or more generally, the processor 1016), cause the application 1002 to process the image to extract medical information.

[0253] The example data processor 1602 can be configured to manage the acquisition of medical information from one or more images. Such management includes displaying one or more camera messages via the screen 1002 that provide information prompting a clinician or patient (e.g., an operator) to record certain images. Alternatively, the data processor 1602 can initialize the image processing mode after the patient has selected to enter medical information into one or more data fields of the application 1002 using an image entry method. After selecting the image entry method, the data processor 1602 is configured to acquire one or more images.

[0254] In some embodiments, the data processor 1602 causes the personal mobile communication device 200a to open a camera application to enable the patient to record one or more images. The patient can select which recorded image will be further processed or discarded. The selected image is analyzed to identify text (as medical information) for data fields that may be filled in one or more user interfaces of the application 1002.

[0255] In other embodiments, the data processor 1602 can guide the patient through one or more steps for acquiring images. The data processor 1602 can execute a workflow or routine based on which data fields the patient has selected. For example, the data processor 1602 executes a blood pressure workflow for acquiring images from a blood pressure monitor based on the patient selecting the systolic blood pressure data field 1402.

[0256] In the example, Fig.16The data processor 1602 is configured to display a camera message that identifies the medical device, the user interface window of the medical device, and / or an identifier on the medical device to be recorded. The data processor 1602 may also display a navigation message specifying the user interface window of the medical device for imaging. In addition, if an image is not recorded within a predetermined time period (e.g., five minutes), the data processor 1602 may display a reminder message. The message may include text that provides instructions and / or identifies the intended target for imaging. The message may also include instructions on how to navigate to a certain user interface window of the medical device using the control interface of the medical device. The message may further include graphical elements, such as exemplary illustrations of the medical device, consumables, identifiers 1012, and / or user interface windows whose images are to be recorded.

[0257] It should be appreciated that in some embodiments, the data processor 1602 does not display a message. Instead, the data processor 1602 reacts to the image recorded by the patient to determine relevant medical information. For example, upon receiving an indication to record an image, the data processor 1602 operates a workflow in which the application 1002 prompts the clinician to identify a medical device from which the image has been recorded. The prompt may include a drop-down menu of available or common medical devices. In other examples, the data processor 1602 automatically identifies medical information using one or more data templates or data tags to determine which extracted medical information will be filled in or written into a data field in a user interface or medical record.

[0258] To record an image, the example data processor 1602 and image processor 1604 (more generally, processor 1016) provide operation of the application 1002 in conjunction with the camera 1004. The patient provides an indication via a camera user interface 1606 (e.g., a touch screen or button on the personal mobile communication device 200a) to record an image. For example, the patient activates the camera user interface 1606 when the camera is focused on the medical device user interface window or identifier 1012. The data processor 1602 receives the indication and instructs the camera 1004 to record an image. The recorded image is transmitted from the camera 1004 to the image processor 1604. In addition, a copy of the image is displayed by the data processor 1602 on the display interface 1022 of the personal mobile communication device 200a.

[0259] In some embodiments, the data processor 1602 can cause a ghost to appear on the display interface 1022, which illustrates the image to be recorded. In preview mode, the ghost is provided on top of the image stream provided by the camera 1004. The purpose of the ghost is to provide assistance to the clinician or patient to confirm that the image to be recorded contains the required medical information and is recorded at an appropriate distance. For example, the data processor 1602 can display a ghost of a given identifier on a given medical device. The patient aligns the personal mobile communication device 200a so that the image stream of the identifier 1012a is aligned with the ghost in position. The patient can then record the image of the identifier 1012a. In some cases, the data processor 1602 uses image analysis to determine the increment between the ghost and the image stream. The data processor 1602 can cause an instruction to be displayed, which prompts the patient to move the personal mobile communication device 200a in a certain direction to reduce the determined increment. The data processor 1602 can determine when the increment is below a threshold to indicate that the image is aligned. Once the images are substantially aligned, data processor 1602 may provide a graphical indication on display interface 1022 indicating the images that may be recorded or automatically cause the images to be recorded without input from the patient.

[0260] The data processor 1602 may provide a prompt asking the patient to accept the image. After receiving the acceptance indication via the camera user interface 1606, the image processor 1604 may analyze the image to identify or otherwise extract text. In some cases, the data processor 1602 may not prompt the clinician to accept the image. Instead, the patient may provide an indication via the camera user interface 1606 to delete the image. Before deleting the image, the image processor 1604 performs analysis to identify the text.

[0261] In order to recognize text, the image processor 1604 uses, for example, OCR. In addition, the image processor 1604 can determine the location or position of the text relative to the center or origin of the image. In some cases, the image processor 1604 can assign two-dimensional coordinates to each character or character group. The position text information can be stored in the image file of the image as metadata. The image processor 1604 can also use the clock of the personal mobile communication device 200a to attach the date / time (corresponding to the time when the image was recorded) to the metadata associated with the image.

[0262] In addition to performing OCR to recognize text, the image processor 1604 can also be configured to use image analysis to identify patients, medical devices, and / or consumables. For example, the image processor 1604 can access a medical device image library to identify the medical device within the image. In this example, the image processor 104 can use an image matching routine to determine a match. This comparison can be performed instead of a medical device with an identifier 1012. The image processor 1604 can use a similar routine and / or algorithm to identify consumables 1006.

[0263] The example data processor 1602 is configured to decode the identifier 1012 to determine the type of medical device of the consumable. Decoding may include associating the position and thickness of the line and / or rectangle with relevant medical information. The encoded lines and rectangles may correspond to a sequence of letters and / or numbers. For example, the data processor 1602 may use the line or rectangle of the identifier 1012 to determine the device model, medical device type, asset code, etc. The decoded identifier 1012 may provide relevant medical information for filling in one or more data fields of the user interface of the application 1002. Additionally or alternatively, the decoded identifier may be used by the data processor 1602 to select a workflow for acquiring images and / or determining a data template from a medical device or consumable.

[0264] Fig.16 The example image processor 1604 transmits the image with the extracted or otherwise identified text and / or medical information to the data processor 1602. The example data processor 1602 uses one or more data templates, for example, from a data template database 1608 to identify relevant medical information from the extracted text. In some examples, the data processor 1602 receives the data templates from the clinician server 200b, which can then be stored in the database 1608. In other examples, the data processor 1602 maintains a database 1608 with data templates.

[0265] Fig.17 A schematic diagram of a data template 1700 according to an example embodiment of the present disclosure is shown. The image processor 1604 (e.g., application 1002) uses the example data template 1700 to identify the extracted text as relevant medical information. Typically, the screen of a medical device displays medical information. Some of the information is related to the content of the data fields of the user interface of application 1002. Other data may be less relevant or unrelated. In addition, depending on the model of the medical device, the medical information may be located in different locations or have different labels. The data template 1700 is configured to specify the location and name of the relevant medical information for a specific home treatment device 90.

[0266] The data template 1700 is stored in the database 1608 along with a plurality of other data templates for different types and / or models of medical devices and / or consumables. After receiving the identifier 1012 of the medical device (or the specification or data field of the patient's medical device), the image processor 1604 selects the corresponding data template 1700. Additionally or alternatively, the image processor 1604 may use image processing to select the data template that best matches the recorded image using, for example, information tags or text locations.

[0267] Fig.17 The example data template 1700 includes device data (or text) fields 1702, 1704, 1706, and 1708, which specify that certain medical information is located on a specific user interface window of a medical device. In some examples, the data template 1700 is graphical, so that image analysis is performed to align the fields 1702 to 1708 with the extracted text in the image. In other examples, the data template 1700 includes a file (or other data structure) with coordinates or positions of each of the device data fields 1702 to 1708 relative to an origin. The image processor 1604 uses the extracted text to identify the origin in the image based on a substantial match with the position in the data template 1700, and identifies the text for each of the data fields 1702 to 1708. In some examples, the image processor 1604 can scale the image to match the size or coordinate space of the data template 1700.

[0268] In addition to coordinates and / or locations, some of the data fields 1702 to 1708 shown may also include label text. For example, device data field 1702 includes the label text "Ultra Filter Window", while device data field 1704a includes the label text "UF Vol". The image processor 1604 matches the label text with similar text extracted from the image. In some cases, the match between the label text is used only to identify the device data field, rather than using location or image analysis.

[0269] The match between label text, including label text for non-related device data fields, can be used to confirm that the image is from the correct window or screen of the medical device. For example, the image processor 1604 can match the label text "ultrafiltration window" with the corresponding extracted text, which is in the same relatively position of the recorded image. The match confirms that the image is recorded from the ultrafiltration window of the medical device for treating renal failure. However, the extracted text is not relevant medical information for the patient's medical record. If the label text does not match the extracted text, the image processor 1604 can display a message prompting the patient to record an image of the ultrafiltration window of the medical device for treating renal failure.

[0270] The label text associated with the device data fields 1706 and 1708 can be used to confirm that the recorded image is current, or was recorded within a determined time period. For example, some windows of a medical device display the current date and time. This information can be extracted by the image processor 1604 and identified using the device data fields 1706 and 1708. The image processor 1604 compares the extracted date / time with the date / time rules or restrictions associated with the device data fields 1706 to 1708 to determine whether the recorded image is current. For example, if the date does not match or the time is not within a predetermined threshold (e.g., 5 minutes, 15 minutes, 60 minutes, 3 hours, etc.) of the current time on the personal mobile communication device 200a, the image processor 1604 can determine that another image needs to be recorded.

[0271] Application 1002 use Fig.17 The example device data fields 1704a and 1704b of the application 1002 can be used to identify relevant medical information. In some cases, the application 1002 can display a flag or metadata indicating that the device data fields 1704a and 1704b are related to the selected data field of the user interface (e.g., user interface 1400 or 1500). By comparison, the device data fields 1702, 1706, and 1708 can include a flag or metadata indicating that the corresponding extracted data is not relevant. Fig.17 In the example shown, the image processor 1604 uses the label text of the data field 1704a to locate the corresponding extracted text in the image. The image processor 1604 then uses the positional relationship between the device data fields 1704a and 1704b or the text value labels to identify the extracted medical information corresponding to the value of the ultrafiltration amount from the image. The image processor 1604 copies the extracted medical information associated with field 1704b from the image to fill in, for example, Fig.14 The systolic blood pressure data field 1402.

[0272] As above combined Fig.17 As discussed, Fig.16The data processor 1602 can use the known positional relationship of the text in the image and the text label to determine which of the extracted text corresponds to the relevant medical information. In some embodiments, the data processor 1602 selects the data template based on an indication of the model or type of the medical device and / or consumable. The indication can be determined by a previous image of the identifier 1012, which is received from the patient via the camera user interface 1606, and / or specified by selecting a data field of the user interface for the application 1002 to fill in the medical information. In other examples, the data processor 1602 compares the data template in the database 1608 with the image with the extracted text to find a match. In these other examples, the data processor 1602 uses the text label and the text position between the image and the data template to determine the match.

[0273] The example data processor 1602 is configured to write or otherwise fill in the relevant medical information into one or more data fields of the user interface of the application 1002 after identifying the relevant medical information. In some embodiments, the data processor 1602 is configured to automatically fill in the data fields of the user interface of the application 1002 using a data template. In order to automatically fill in the medical information, the data processor 1602 compares the text, labels, and / or metadata associated with the fields of the data template with the text, labels, metadata, and / or other data field information of one or more user interfaces of the application 1002. If at least some of the text, labels, and / or metadata match, the data processor 1602 identifies certain text (e.g., a numerical value) corresponding to the matching fields of the data template. The identified text is written to the corresponding matching data fields of the user interface of the application 1002.

[0274] In other embodiments, the data processor 1602 is configured to prompt the patient to select one or more fields of a data template to fill in one or more data fields of a user interface of the application 1002 . Fig.18 A diagram showing a patient filling out data fields 1402 to 1406 of a user interface 1400 is shown according to an example embodiment of the present disclosure. In the example shown, the user interface 1400 is opened on a personal mobile communication device 200a. To enter medical information into the data fields 1402 to 1406, the patient selects each data field sequentially or together. For each selection, the application 1002 displays a prompt asking the patient how to enter the data. After the patient selects the photo entry method, the application 1002 opens a camera application to enable the patient to record an image 1800 of the screen of the blood pressure monitor 104 using the personal mobile communication device 200a. In some embodiments, as described above, the application 1002 can display text or graphics to help the patient acquire the image.

[0275] After recording the image 1800, the application 1002 performs an OCR operation to extract the text. Then, the application 1002 determines the data template 1801 corresponding to the extracted text. In some embodiments, the application 1002 matches the position of the text and / or label within the image with the text and / or label position in the data template to find a matching data template. In other examples, the patient can specify an indication of the blood pressure monitor 104, which allows the application 1002 to locate the corresponding data template 1801. In other examples, the application 1002 can first prompt the patient to record an image of the identifier 1012a of the blood pressure monitor 104. The data from the identifier is used by the application 1002 to select the data template. Regardless of how the data template 1801 is identified, the application 1002 applies the data template 1801 to the extracted text in the image 1800. The process includes the application 1002 identifying groups or fields of similar text. In some cases, the application 1002 can identify groups or fields of similar text based on the spacing between letters and / or words.

[0276] exist Fig.18 In the illustrated example of FIG. 14 , the application 1002 provides fields 1802, 1804a, 1804b, 1806, 1808, and 1810 for different sets of text. The patient selects a field whose data will be filled into the selected data field of the user interface 1400. For example, to fill in the systolic blood pressure data field 1402, the patient selects field 1804a. The patient's selection causes the application 1002 to copy at least some data from field 1804a to the data field 1402. The data field 1402 may include a rule specifying that only integer values ​​can be accepted. The application 1002 reads the text from the selected field 1804a to obtain an integer value (i.e., "145"). The application 1002 then fills the identified integer value into the systolic blood pressure data field 1402. The patient can continue with the other fields 1404 to 1410 of the user interface 1400 using the image 1800. In each case, the patient can choose between entering data manually, wirelessly, or via an image. If a second image is needed (e.g., prompted by the application 1002 or determined by the patient), the application 1002 enables the patient to record and view multiple images. The application 1002 applies the appropriate data template to each recorded image. Accordingly, the application 1002 enables the patient to enter information into the user interface 1400 using one or more recorded images, just as if the patient were manually entering values.

[0277] In some embodiments, the application 1002, and more specifically, the data processor 1602, performs checks on the extracted data selected by the user to ensure that the values ​​are within a predetermined range and / or are of a specified type. The application 1002 can perform similar checks on data manually entered by the patient or data wirelessly received from a medical device. Each data template and / or data field of the user interface can include metadata or rules for certain fields that provide thresholds or acceptable ranges of values. For example, metadata or rules for a weight data field can specify that a predetermined acceptable range of values ​​is between 20kg and 200kg. For values ​​that exceed the predetermined range, the application 1002 can display an error on the display interface 1022, or prompt the patient to record another image or modify the value.

[0278] Fig.19 A flow chart of an example process 1900 for inputting medical information from an image using an application 1002 of a personal mobile communication device 200a is shown according to an example embodiment of the present disclosure. Fig.19 The illustrated flowchart describes the process 1900, but it should be appreciated that many other methods of performing the steps associated with the process 1900 may be used. For example, the order of many of the blocks may be changed, certain blocks may be combined with other blocks, and many of the blocks described may be optional. Additionally, the example process 1900 may include an optional block for prompting the patient to record an image of the screen and / or identifier 1012 of the medical device.

[0279] In one embodiment, the example process 1900 begins when the application 1002 is launched on the personal mobile communication device 200a and operates with the processor 1016 to establish a wired and / or wireless connection with the clinician server 200b (block 1902). Establishing the connection may include, for example, transmitting and / or receiving one or more messages 1903 that provide a device address, patient identifier, device identifier, network address, and / or protocol information for accessing and / or writing to a patient's medical record. After opening the application 1002, the patient navigates or otherwise accesses a user interface for entering medical information (e.g., Fig.14 and 15 User interface 1400 or 1500) (box 1904).

[0280] Prior to box 1906, the patient uses application 1002 to select data fields and selects to provide medical information via photo entry. In box 1906, the personal mobile communication device 200a records an image 1907 of a medical device, consumables, patient, etc. The image may include an identifier and / or screen of the medical device. The personal mobile communication device 200a then determines or recognizes text within the recorded image (box 1908). For example, the personal mobile communication device 200a can perform an OCR routine on the image. In the event that the image includes a barcode and / or QR code, the personal mobile communication device 200a decodes the barcode and / or QR code. The imaged or encoded data is converted into texture or American Standard Code for Information Interchange ("ASCII") characters. In some embodiments, the personal mobile communication device 200a may also determine a data field for the identified text (box 1910). The data field may be determined using, for example, a data template. As described above in conjunction with Fig.17 and 18 As described, the data template can specify the location of certain text and / or specify the label of certain text, which is used to operably place the data field on the recognized text within the recorded image. In some cases, the data field and / or data template can be selected by the patient and / or determined by the identifier 1012 of the medical device. Alternatively, in addition to using a template, the process 1900 can provide an indication that the recently recorded image has relevant medical information for extraction, selection and / or transmission.

[0281] In one embodiment, the example process 1900 continues by determining whether there are additional images to be recorded (decision block 1912). In an example, the process 1900 may access a list of images that need to be recorded for a particular therapy or treatment. The process 1900, via the personal mobile communication device 200a, may guide the patient through a sequence to obtain all required images, or provide prompts to obtain images containing medical information that is determined to be required or missing. In other cases, the patient may determine which images are required. If additional images are to be recorded, the process 1900 returns to block 1906.

[0282] If no additional images are needed, as determined at decision block 1912, the patient begins the process of filling in the data fields of the user interface with the relevant medical information. The process in the illustrated embodiment includes enabling the patient to select an image from which the relevant medical information is to be transferred. Selection of an image causes the personal mobile communication device 200a to display the image on the display interface 1022 (block 1914). It should be appreciated that the selected image includes recognized text and optionally a data field. The patient may also specify a data field (or location in a data field) of the user interface into which the data is to be filled.

[0283] The personal mobile communication device 200a receives a selection of relevant medical information and / or a data field having relevant medical information for filling it into a designed data field of the user interface of the application 1002. The selection may be performed by the patient pressing an area of ​​the touch screen 1002 of the personal mobile communication device 200a corresponding to the medical information to be filled in. In an embodiment, the selection of relevant medical information and / or fields causes the personal mobile communication device 200a to automatically fill in at least a portion of the selected text (block 1916).

[0284] After the selected text has been filled in, the personal mobile communication device 200a determines whether additional related medical information will be filled in based on the selection of additional data fields of the user interface (decision box 1918). In some examples, the personal mobile communication device 200a operates a sequence or routine that provides prompts for the patient to select appropriate text and / or images for filling in the data fields. If there is other related medical information as determined by decision box 1918, the process 1900 returns to boxes 1914 and 1916, where the patient fills in the specified image and / or related medical information for the image field. If there is no other related medical information for filling in as determined by decision box 1918, the example process 1900 ends.

[0285] 4. Image / text attachment application examples

[0286] In some embodiments, the example application 1002 and the clinician server 200b are configured to enable the patient to provide an image or text as an attachment or appendix to his medical record. In the above sections, the application 1002 provides a data field of the user interface as a prompt for the required information. However, in some cases, the patient or clinician may wish to provide additional information. Additionally or alternatively, one or more user interfaces of the application 1002 may include a data field for free text input, a prompt for the patient to enter text (e.g., "how do you feel today"), or a functional component that enables a photo or image to be incorporated into a part of the record. For example, the user interface 1400 may include a photo icon adjacent to a prompt for an image connected to the patient's abdominal fluid, which, when selected, will open a camera application so that the patient can attach an image for transmission with medical information. The image can be stored in a design field in an appropriate patient's medical record.

[0287] The example application 1002 on the personal mobile communication device 200a is configured to accept images and / or text provided by the patient. In an embodiment, the application 1002 is configured to enable the patient to choose between text or photo entry. If the patient selects text entry, the application 1002 displays a text box. The patient enters information into the text box, which is stored by the application 1002. Then, the application 1002 can transmit the information in one or more messages to the clinician server 200b. The application 1020 on the clinician server 200b determines the appropriate patient medical record in the database 1010 and locates the "note" or free text field. The application 1020 stores the text provided by the patient in this field. In some cases, the application 1020 can also include a time / date stamp with the entered text. This information provides the clinician with additional information from the patient, including feedback on treatment.

[0288] Fig. 20 An example of a user interface 2000 that can be displayed by an application 1002 on a personal mobile communication device 200a, according to an example embodiment of the present disclosure, is shown, which enables a patient to provide a recorded image. The example user interface 2000 includes an image title field 2002, which can be edited by the patient. The user interface 2000 also includes one or more recorded images 2004, or a preview of the recorded image. The application 1002 is configured to enable the patient to browse a gallery folder of recorded images to select which images to transfer. The date field 2006 and the time field 2008 provide information in the user interface 2000 indicating the date / time of recording the displayed image. The patient can select a "trash can" button to discard the image 2004, or can select an "upload" button to transfer the image 2004 from the application 1002 to the clinician server 200b. The example photo capture function component of the application 1002 enables the patient to archive the fluid line connection with the home treatment device 90 or the physiological condition related to the treatment. The application 1020 at the clinician server 200b is configured to attach or otherwise link the received image 2004 to the patient's medical record.

[0289] 5. Manual / wireless / image entry of medical information via text

[0290] In some embodiments, Figures 10 to 12The personal mobile communication device 200a may not be able to install or operate the application 1002, or the patient may decide not to install the application 1002. However, the clinician server 200b still registers the personal mobile communication device 200a during the registration process. In addition to receiving medical information via the application 1002, the data acquisition module 1104 of the clinician server 200b determines that a routine or algorithm is to be executed to prompt or otherwise obtain medical information from the patient via the personal mobile communication device 200a. The example data acquisition module 1104 can read the patient's registration file and / or medical records to determine that the personal mobile communication device 200a has been registered but the application 1002 is not installed.

[0291] In some embodiments, the data acquisition module 1104 is configured to obtain medical information from the patient via one or more text messages. For example, at a designed time corresponding to the time of a prescribed treatment, the data acquisition module 1104 may transmit one or more text messages prompting the patient to respond with medical information using a registered personal mobile communication device 200a. In other cases, the data acquisition module 1104 is configured to respond to a text from the patient to begin a sequence or routine for obtaining medical information. In other cases, the patient may send a text message with medical information and / or images to the data acquisition module without a prompting message.

[0292] Fig.11 The example data acquisition module 1104 is configured to format or otherwise structure the received information for filling into one or more data fields of the patient's medical record. Typically, the medical information received from the text message is unstructured. In other words, the text message does not provide an explicit association or reference to the designed fields of the patient's medical record. Instead, the data acquisition module 1104 is configured to determine the appropriate fields for the medical information received in the text message.

[0293] In some embodiments, the data acquisition module 1104 uses the context of the text message received from the personal mobile communication device 200a to determine the data field. For example, a patient can send a message including the text "systolic blood pressure 145". The data acquisition module 1104 compares at least some of the text (e.g., one or more words in a string) with field data tags, keywords, and / or metadata. If at least some of the words match, the data acquisition module 1104 is configured to identify the numerical value in the content of the text message and write the identified numerical value into the data field of the patient's medical record corresponding to the matching text. In some embodiments, the data acquisition module 1104 can compare the value with an acceptable range of values ​​before writing the value. If the value is outside the acceptable range, the data acquisition module 1104 can send a message indicating an error or a message prompting the patient to re-enter the value to the personal mobile communication device 200a.

[0294] In these embodiments, the data acquisition module 1104 can be configured to send a follow-up text to the patient if the text from the received text message cannot be properly placed into the data field. For example, the data acquisition module 1104 can receive a message with text including "blood pressure 145". The data acquisition module 1104 determines that the message can correspond to a "systolic" or "diastolic" blood pressure data field based on the matching text. Therefore, the data acquisition module 1104 sends a message to the personal mobile communication device 200a with text asking the patient whether the value is "systolic" or "diastolic".

[0295] In other embodiments, the data acquisition module 1104 prompts the patient to provide certain medical information through a series of messages (which may be defined by a routine or algorithm). The order of the sequence is known or defined and corresponds to a data field in the medical record. In this way, the data acquisition module 1104 automatically determines that the response to a prompt corresponds to the data field of the medical record associated with the prompt. For example, the data acquisition module 1104 sends a text message prompting the patient to take a "systolic blood pressure measurement." The data acquisition module 1104 determines that the response to the text contains a value for "systolic blood pressure measurement." The data acquisition module 1104 can analyze the received message to identify the numerical value in other text and / or compare the value to an acceptable range. After confirming that the patient has provided an acceptable response with medical information, the data acquisition module 1104 determines the subsequent message to be sent to the personal mobile communication device 200a based on the message sequence.

[0296] In addition to receiving messages with text, the data acquisition module 1104 can also receive messages with photo attachments. Figures 16 to 19 In the process described above, the data acquisition module 1104 is configured to process the image to extract text and identify relevant medical device data for one or more data fields of the medical record. In addition, although the above disclosure describes the use of text messages, the data acquisition module 1104 can additionally or alternatively receive medical information and / or photos via other communication media such as email, instant messaging or web-based messaging, social media posts, etc.

[0297] Fig.21 A schematic diagram of a patient medical template 2100 that can be used by the data acquisition module 1104 of the clinician server 200b to fill in the data fields of a patient's medical record according to an example embodiment of the present disclosure is shown. The fields of the template 2100 can correspond to or otherwise be linked or referenced to the data fields of the patient's medical record. In other embodiments, a copy of the completed template 2100 can be stored in the medical record or as the medical record itself. In some embodiments, the patient medical template 2100 can be part of or otherwise integrated with the patient's medical record.

[0298] The example template 2100 includes predefined fields 2102, 2104, 2106, 2108, 2110, 2112, 2114, 2116, 2118, and 2120 that correspond to a renal failure treatment ("RFT"). The example data acquisition processor 1104 may select the template 2100 based on the treatment prescribed for the patient. Although the RFT template 2100 is shown, the example data acquisition module 1104 may select other templates specifically configured for pre-treatment data acquisition, post-treatment data acquisition, etc. For example, a pre-treatment acquisition template may include data fields for blood pressure, pulse, and weight.

[0299] It should be appreciated that in other embodiments, the patient medical template 2100 may include more or fewer fields. For example, the template 2100 may additionally include data fields for pre-treatment patient weight and post-treatment patient weight, patient glucose level, and / or patient date of birth. In another example, the template 2100 may include fields for fill rate, residence time, drainage or fluid removal rate, blood flow rate, outflow dose, ultrafiltration removal rate, dialysate removal rate, total dialysate infusion injected, dialysate flow rate, pre-change flow rate, post-change flow rate, patient weight balance, return pressure, excess patient fluid, filtration fraction, remaining time, dialysate concentration, dialysate name, patient identifier, room identifier, care area identifier, timestamp indicating when data was generated, alarm conditions, reminder conditions, and / or events.

[0300] In some embodiments, the data acquisition module 1104 is configured to select a template 2100 based on a prompt from the patient. For example, the patient may send a message including the text "manual exchange" to the data acquisition module 1104. In response, the data acquisition module 1104 identifies and selects a template 2100 for manual exchange. In another example, the patient may send a message including the text "before treatment" or "start treatment" to the data acquisition module 1104 via the personal mobile communication device 200a. In response, the data acquisition module 1104 identifies and selects a template for acquiring medical information required before treatment begins.

[0301] exist Fig.21In the example shown, the example data fields include a field 2102 for patient name, a field 2104 for patient identifier, a field 2106 for patient weight, a field 2108 for patient blood pressure, a field 2110 for treatment date, a field 2112 for UF amount removed, a field 2114 for total fluid amount provided to the patient, a field 2116 for glucose level, a field 2118 for treatment prescription identifier, and a field 2120 for disposable cartridge identifier. In the case where the renal treatment machine 90 is registered with the clinician server 200b, the data acquisition module 1104 can remove at least fields 2112 to 2120 (or choose to omit a separate template with fields 2112 to 2120) because this information is already provided by the machine 90. However, if the patient is reporting manual replacement, fields 2112 to 2120 can be used in the template. In addition, the template 2100 can omit fields 2102 and 2104 based on at least some of the patient information that has already been registered.

[0302] The example data fields of the patient medical template 2100 may be populated from one or more different sources of medical information (including device information, patient information, and / or consumables information). For example, the patient name field 2102 and the patient identifier field 2104 may be populated from an image recorded by the personal mobile communication device 200a of the patient's identifier 1012 (or an identifier 1012 worn by the patient). The blood pressure field 2108 may be populated from an image recorded by the personal mobile communication device 200a of the screen of the blood pressure monitor 104, while the weight field 2106 may be populated from an image recorded by the personal mobile communication device 200a of the screen of the scale 106. The date field 2110, the UF removal field 2112, and the fluid fill field 2114 may be populated from an image recorded by the personal mobile communication device 200a of the screen of the home treatment device 90 (showing the treatment status window). Similarly, the D-glucose level field 2116 may be populated from an image recorded by the personal mobile communication device 200a of the screen of the home therapeutic device 90 (settings window shown), while the prescription identifier field 2118 may be populated from an image recorded by the personal mobile communication device 200a of the screen of the home therapeutic device 90 (prescription window shown). Finally, the cartridge identifier field 2120 may be populated from an image recorded by the personal mobile communication device 200a of the identifier 1008 of the disposable cartridge consumable 1006. As described above, the data acquisition module 1104 may receive one or more messages having text for the fields 2102 through 2120 in addition to receiving images containing medical information.

[0303] Fig.21 The patient medical template 2100 is configured to be stored on the clinician database 1010 and to be used by Fig.10 and 11The clinician server 200b shown is accessed. Upon receiving a request to fill out a template for a patient, the clinician server 200b is configured to make a copy of the template 2100 or create an instance of the template 2100. The medical information received from the personal mobile communication device 200a is input by the data acquisition module 1104 into the appropriate data fields 2102 to 2120 of the copy or instance of the template 2100. Once completed, the copy or instance is stored as the patient's medical record in the clinician database 1010 repository.

[0304] In some embodiments, the data acquisition module 1104 operates routine 2150 in conjunction with or in place of the example patient medical template 2100. In some embodiments, the routine 2150 can be programmed as metadata or computer executable code for each data field 2102 to 2120. In other examples, the routine 2150 can be stored in the clinician database 1010 in association with the patient medical template 2100. In addition, in these other examples, selecting the template 2100 causes the routine 2150 to be executed. The example routine 2150 includes routine modules 2152 to 2164, which provide an association between the data fields 2102 to 2120 and the corresponding medical devices, identifiers 1012 and / or consumables 1006.

[0305] At least some of the routine modules 2152 to 2164 may be associated with a data template (e.g., Fig.17 1700) is associated or otherwise related to the data template 1700 of the blood pressure monitor 104. The data acquisition module 1104 is configured to access the data template for the corresponding routine module 2152 to 2164 when the patient provides an image and / or text in the message. For example, while executing the routine module 2156 for blood pressure, the data acquisition module 1104 sends a message prompting the personal mobile communication device 200a to take a "systolic blood pressure measurement." The patient responds with a text message that includes an image of the screen or dial of the blood pressure monitor 104. The data acquisition module 1104 is configured to access the data template corresponding to or referencing the routine module 1156 for blood pressure measurement. The data acquisition module 1104 then applies the data template to use the above in conjunction with Figures 16 to 19 The process described is used to extract text from the image to identify relevant systolic blood pressure medical information for filling in the blood pressure data field 2108 of the template 2100.

[0306] The example routine 2150 may be configured to start upon a request from a patient based on one or more messages received by the data acquisition module 1104. For example, the data acquisition module 1104 may receive a message having text including "start," "start," and / or "pre-processing." Receiving the message causes the data acquisition module 1104 to determine and start the routine 2150 to fill in the data fields 2102 to 2120 of the template 2100. In other examples, the data acquisition module 1104 sends a first message specified by the routine 2150 to the patient at a predetermined time related to treatment. After receiving a response message with appropriate medical information from the personal mobile communication device 200a, the data acquisition module 1104 sequentially sends the messages specified by the routine 2150. In this manner, the data acquisition module 1104 controls the acquisition of medical information from the patient according to a predetermined sequence. Until an appropriate response message is received from the personal mobile communication device 200a (and the medical information is filled in the designated data fields 2102 to 2120 of the template 2100), the data acquisition module 1104 sends the next message in the sequence defined by the routine 2150.

[0307] In the example shown, the patient ring module 2152 may include metadata or a preformatted message instructing the patient to record an image of the patient's wristband. The patient ring module 2152 may also include a character validation check to ensure that the received medical information complies with the text requirements for the patient name and / or patient identifier. For example, the patient ring module 2152 may reject or discard medical information that includes a patient name that is numeric.

[0308] The weight scale module 2154 may include an image indicating the patient record identifier 1012c and Fig.10 The weight scale module 2154 may also include a character validation check to ensure that the received medical information is within an acceptable range of values ​​and / or the correct unit type. In some cases, the weight scale module 2154 may use the medical information from the identifier 1012c to confirm that the medical information from the screen of the weight scale 106 is the patient's weight medical information. In other cases, the medical information from the identifier 1012c is used to select a data template based on, for example, the model or type of the weight scale 106. The data acquisition module 1104 uses the data template to identify the relevant weight scale medical information extracted from the image of the screen of the weight scale 106.

[0309] With respect to the blood pressure monitor 104, the blood pressure module 2156 is similar to the weight scale module 2154. The renal failure treatment ("RFT") modules 2158 to 2162 are also similar to the weight scale module 2154. However, for each different window from which medical information is required, multiple modules 2158 to 2162 are used for the home treatment device 90 (or manually exchanged). For example, module 2158 provides a message for obtaining an image of the identifier 1012 of the home treatment device 90 and a first window showing the treatment status window, while module 2160 provides one or more messages for obtaining an image of the setting window of the home treatment device 90, and module 2162 provides one or more messages for obtaining an image of the prescription window of the home treatment device 90.

[0310] The box module 2164 may include metadata or a preformatted message indicating an image of the clinician or patient record identifier 1008, the disposable box consumable 1006, and / or a label on the packaging or box consumable itself. It should be appreciated that if the patient medical template 2100 includes additional data fields, the routine 2150 may include additional modules, or if the template 2100 includes fewer fields, the routine 2150 may include fewer modules.

[0311] Once the medical information is received using the routine 2150, the data acquisition module 1104 of the application 1020 uses data validation checks to ensure that the data is within acceptable ranges, is properly formatted, and / or is in the appropriate units. In some cases, the modules of the routine 2150 may include conversion or formatting instructions that are used by the data acquisition module 1104 to prepare the medical information to be included in the template 2100 and / or the corresponding fields of the patient's medical record. Once the data is in the appropriate format and units, the data acquisition module 1104 writes the medical information to the template 2100 and / or the corresponding fields of the patient's medical record.

[0312] In an alternative embodiment, the patient medical template 2100 may not have an associated routine. Fig.11 The data acquisition module 1104 is configured to read the data fields 2102 to 2120 of the patient medical template 2100 to determine, for example, incomplete data fields. In these alternative embodiments, the data acquisition module 1104 identifies the missing data and transmits one or more messages to the personal mobile communication device 200a to alert the patient of the missing data.

[0313] To fill in the data fields, in some embodiments, the data acquisition module 1104 can read the names of the data fields 2102 to 2120 (and any corresponding metadata) to create and send a message to the patient to prompt the patient to record certain images. In the example, the weight data field 2106 includes metadata identifying the weight scale as a related medical device. The data acquisition module 1104 determines that the data field 2106 is not filled in, reads the corresponding metadata, and constructs a message that instructs the patient of the personal mobile communication device 200a to record an image of the screen of the weight scale. In the illustrated embodiment, the data acquisition module 1104 can sequentially search for the unfilled data fields in the template 2100 (or the patient's medical record) and accordingly request medical information from the patient via a message displayed by the personal mobile communication device 200a. Alternatively, the data acquisition module 1104 can go through the template 2100 according to a predetermined order or sequence. For example, the data acquisition module 1104 can first search the data fields associated with the patient's wristband, and then search the data fields for the weight scale medical device, the data fields for the blood pressure medical device, and the data fields for the renal failure treatment medical device.

[0314] Fig. 22 According to an exemplary embodiment of the present disclosure Fig.11 Schematic diagram of the data acquisition module 1104 of the clinician server 200b. It should be appreciated that the illustration of the data acquisition module 1104 is exemplary, and some boxes can be combined, further divided or removed. In addition, in some embodiments, the data acquisition module 1104 can include additional boxes, such as boxes for user interfaces.

[0315] The example data acquisition module 1104 (and more generally, the clinician server 200b) includes an interface 2202 that provides connectivity with the personal mobile communication device 200a. The interface 2202 may include, for example, an Internet port or connection. In one embodiment, the interface 2202 is configured to receive messages from the personal mobile communication device 200a and convert them into a format compatible with internal processing. For example, the interface 2202 can convert SMS or text messages into HL7 or ASCII format. The example interface 2202 is also configured to format or convert messages for transmission to the personal mobile communication device 200a. In some cases, the interface 2202 can encrypt messages for transmission and / or decrypt received messages.

[0316] The example data acquisition module 1104 includes a template processor 2204 that is configured to manage the writing or filling of medical information from the personal mobile communication device 200a to the patient medical template 2100 or medical record. For example, upon a request from a patient or clinician, or automatically, the template processor 2204 selects a template from a patient medical template database 2206. The template processor 2204 uses the selected template (e.g., Fig.21 template 2100 ) to operate a routine (eg, routine 2150 ) (if available or configured) to obtain medical information from the personal mobile communication device 200 a .

[0317] The example template processor 2204 is configured to identify messages from a module of a routine (e.g., routine 2150) for transmission to the personal mobile communication device 200a. In some cases, the messages may be transmitted in a predetermined order to guide or direct a clinician or patient through the process of filling out a patient medical template. For example, the template processor 2204 may read Fig.21 The template processor 2204 may be configured to wait until medical information associated with the identifier 1012c (for filling in the form) is received before identifying the message to be transmitted from the routine module 2156. Fig.21 In other cases, the template processor 2204 selects a message to send based on a message received from the personal mobile communication device 200a. For example, the processor 2204 may receive medical information associated with the identifier 1012c of the weight scale 106. In response to the received medical information, the template processor 2204 may determine that the module 2154 corresponds to the received data and therefore select a message prompting the patient to record an image of the screen of the weight scale 104. Fig. 22 As shown, the personal mobile communication device 200a displays a text message from the template processor 2204 instructing the patient to record an image of the screen 2220 of the weight scale 106.

[0318] In addition to sending messages, the template processor 2204 can be configured to select a data template. In the illustrated embodiment, the data templates are stored in a data template database 2208. The template processor 2204 selects the data template based on the type or model of the medical device indicated in the medical information corresponding to the identifier 1012. In some cases, the patient can specify the model and / or type of the medical device type to the template processor 2204 via a message. In addition, as described above, the template processor 2204 can receive an image from the personal mobile communication device 200a, extract text from the image, and select an appropriate data template from the database 2208 to identify relevant medical information from the image(s) as described above.

[0319] In some embodiments, the template processor 2204 can receive a message stream from the personal mobile communication device 200a, the message stream containing substantially all of the medical information for the patient medical template 2100 or the patient's medical record. In these embodiments, the template processor 2204 reads the tags, metadata, and / or device data field information provided with the data to determine the data fields of the template 2100 to which the data will be filled or written. For example, the template processor 2204 matches the metadata or information of the module (or the data fields 2102 to 2120 themselves) with the tags, metadata, and / or device data field information provided with the medical information to determine the appropriate data fields of the template 2100.

[0320] After filling out or otherwise completing the Patient Medical Form, Fig. 22 The template processor 2204 is configured to store the completed template to the clinician database 1010. This may include filling out the patient's medical record using the template 2100, wherein the fields in the template correspond to, link to, or reference fields in the patient's medical record. In other examples, writing to the medical record may include storing the completed template in the patient's medical record or storing the template 2100 as the medical record itself.

[0321] Fig.23 and 24 According to an exemplary embodiment of the present disclosure, using Figures 10 to 12 as well as Fig. 22 The image recorded by the personal mobile communication device 200a (and / or the text message received therefrom), fill in Fig.21 Flowcharts of example processes 2300 and 2350 of the medical device template 2100. Although reference Fig.23 and 24The flowcharts shown describe processes 2300 and 2350, but it should be appreciated that many other methods of performing the steps associated with processes 2300 and 2350 may be used. For example, the order of many of the boxes may be changed, certain boxes may be combined with other boxes, and many of the boxes described may be optional. In an embodiment, if there is no permanent connection between the clinician server 200b and the personal mobile communication device 200a, the order of the boxes may be modified. Conversely, in an embodiment, the personal mobile communication device 200a may first acquire and queue substantially all relevant medical information for the patient medical template until a connection with the clinician server 200b is available (or as designed). The actions described in processes 2300 and 2350 may be performed between multiple devices including, for example, a personal mobile communication device 200a and a clinician server 200b.

[0322] when Figures 10 to 12 and Fig. 22 When the clinician server 200b receives the message 2301 from the personal mobile communication device 200a, the example process 2300 Fig.23 Message 2301 indicates a treatment to be performed on a patient or a request to initiate the sending of medical information. Clinician server 200b then determines a patient medical template (e.g., Fig.21 Message 2301 may indicate a request to begin filling out a blank template in the event that clinician server 200b only provides templates for completing one type (e.g., a template for renal failure treatment). In response to message 2301, clinician server 200b creates a copy of the patient medical template for filling out.

[0323] After providing the patient medical template for filling out, the clinician server 200b determines at least one medical device from which medical information is needed (using a routine associated with the template or reading the template itself) and transmits a first camera message 2305 to the personal mobile communication device 200a accordingly (box 2306). The first camera message 2305 includes instructions indicating that an image of, for example, the identifier 1012 of the medical device is to be recorded. Some time later, the clinician server 200b receives a message 2307 that includes medical information indicating the type of medical device (e.g., medical information from identifier 1012a) (box 2308). The clinician server 200b then determines the device data template (e.g., the device data template) based on the information included in the message 2307 or specified in the patient's medical record. Fig.171700 ) (block 2310 ). For example, after determining that the message 2307 identifies the blood pressure monitor 104 (type and / or model), the clinician server 200 b determines or locates a device data template for the blood pressure monitor. The clinician server 200 b loads a device data template for identifying relevant medical device data from an image received from the screen of the blood pressure monitor 104 (block 2312 ).

[0324] Example process 2300 in Fig.24 Continuing in, wherein the clinician server 200b transmits a second camera message 2313 to the personal mobile communication device 200a (box 2314). The second camera message 2313 can be determined based on the type of medical device specified by the message 2307. In addition, the second camera message 2313 can include information for displaying a window (or related medical information) on the medical device used to record the image. After a period of time, the clinician server 200b receives a message 2315, which includes text or an image of a window from the medical device (box 2316). The example clinician server 200b extracts the relevant medical information from the image using the identified data template and determines or otherwise identifies the data field of the patient medical template corresponding to the relevant medical information (box 2318). If the message 2315 includes text, the clinician server 200b determines or otherwise identifies the data field in the patient medical template corresponding to the relevant medical information. Next, the clinician server 200b fills in the data field of the determined and / or identified template with the received relevant medical information (box 2320).

[0325] After filling in the relevant data fields, the example clinician server 200b determines whether additional relevant medical information is needed from the medical device associated with the received relevant medical information (decision box 2322). For example, the clinician server 200b may determine that the current medical device may include an additional window or operating display from which relevant medical information is still needed. If additional medical information is needed, the example clinician server 200b returns to box 2314 and transmits a camera message 2313 for another window for which relevant medical information is needed. However, if additional medical information is not needed for the current medical device, the clinician server 200b determines whether medical information from other medical devices (or consumables 1006) is needed (decision box 2324). If additional medical information is needed, the clinician server 200b returns to box 2306 and transmits a camera message 2305 that identifies another medical device for imaging or receiving relevant medical information from it. If no additional medical information is needed to complete the patient medical template 2100, the example clinician server 200b stores the completed patient medical template 2100 to the clinician database 1010 as the patient's medical record and the process 2300 ends.

[0326] The example process 2350 transmits a message 2301 indicating a request to perform treatment on a patient or to initiate input of medical information via the personal mobile communication device 200a. Fig.23 Start (2352). Next, the personal mobile communication device 200a receives the camera message 2305 from the clinician server 200b. The personal mobile communication device 200a uses the information from the message 2305 to display a prompt to the patient (box 2354). The prompt can specify, for example, the identifier 1012 of the medical device to be imaged. The personal mobile communication device 200a then records an image of the identifier 1012 of the medical device based on input from the patient (box 2356). In some embodiments, if the identifier is not available or the patient does not want (or cannot) record an image, the patient can enter text specifying the type / model of the medical device or select from a drop-down menu.

[0327] After recording the image of the identifier 1012, the personal mobile communication device 200a extracts or otherwise determines the medical information encoded in the identifier (block 2358). The personal mobile communication device 200a sends the extracted medical information in a message 2307 to the clinician server 200b. In some embodiments, the personal mobile communication device 200a sends the recorded image within the message 2307.

[0328] Thereafter, the personal mobile communication device 200a receives a camera message 2313 from the server 200b, the camera message 2313 having information for displaying a prompt to the patient for recording an image of the screen (or other designated area) of the medical device (block 2360). The personal mobile communication device 200a accordingly displays a prompt to the patient, the prompt having information required for imaging the medical device. In response to the prompt, the patient uses the personal mobile communication device 200a to record an image of the screen (or other designated area) of the medical device (block 2362).

[0329] exist Fig.24 In the example process 2350, the personal mobile communication device 200a creates a text message with the recorded image or text entered by the patient (block 2364). In some examples, the patient can modify or specify the medical information. The personal mobile communication device 200a then transmits a message 2315 including the medical information or its image (block 2366).

[0330] Next, the example personal mobile communication device 200a determines whether additional relevant medical information is needed from the medical device associated with the extracted relevant medical information (decision box 2368). This determination may include, for example, checking to see whether additional camera messages related to the current medical device are received from the clinician server (box 2360). If additional medical information is needed, the example personal mobile communication device 200a returns to box 2360 and processes the camera message 2313 for another window (or part of a medical device / consumable) for which relevant medical information is needed. However, if additional medical information is not needed for the current medical device, the personal mobile communication device 200a determines whether medical information from other medical devices (or consumables 1006) is needed (decision box 2370). If additional medical information is needed, the personal mobile communication device 200a returns to box 2354 and processes the camera message 2305 for identifying another medical device for imaging. If additional medical information is not needed for completing the patient medical template, the example personal mobile communication device 200a ends the session, thereby ending the process 2350.

[0331] 6. Manual / wireless / image medical information entry via web browser or file transfer

[0332] In some embodiments, Fig.11The data acquisition module 1104 is configured to enable patients to use their personal mobile communication device 200a to enter medical information or provide images via a web browser or file transfer program. The web browser or file transfer program enables the personal mobile communication device 200a to provide medical information and / or images without using the application 1002. In this embodiment, the clinician server 200b hosts a website, API, and / or file transfer site that is assigned an address or uniform resource locator ("URL"). The web browser or file transfer program on the personal mobile communication device 200a is configured to access the hosted website, API, and / or file transfer site to transmit medical information.

[0333] In some embodiments, the data acquisition module 1104 is configured to prompt the patient to enter a username and password to access the website or file transfer site. In other embodiments, the data acquisition module 1104 determines that the personal mobile communication device 200a has been previously registered and provides access. In other embodiments, the data acquisition module 1104 provides a mailbox or other interface (e.g., API) to receive medical information or images without providing access to a more secure location for the personal mobile communication device 200a.

[0334] Once the patient has gained access via the personal mobile communication device 200a, in some embodiments, the data acquisition module 1104 provides a graphical user interface that presents the patient with medical information and / or images. The user interface may be similar to that in conjunction with Fig.14 and 15 Described user interfaces 1400 and 1500. Similar to the personal mobile communication device 200a containing the application 1002, the clinician server 200b provides a user interface and data fields for receiving medical information. The data acquisition module 1104 may also enable the patient to select a data entry method, such as text or image.

[0335] In some embodiments, the clinician server 200b may provide a menu to enable the patient to select an appropriate user interface. In other embodiments, the clinician server 200b may select a user interface requiring medical information based on the prescribed treatment or treatment information provided by the patient. In other embodiments, the application 1020 of the clinician server 200b may operate a routine 2150 that provides a graphical prompt for medical information.

[0336] Fig.25A diagram of a clinician server 200b hosting a website or file transfer site to receive medical information via an image from a personal mobile communication device 200a is shown in accordance with an example embodiment of the present disclosure. In the example shown, the personal mobile communication device 200a is operating a web browser application 2500 directed to a website 2502 hosted by the clinician server 200b. The website 2502 includes a graphical user interface for inputting medical information. In this example, the personal mobile communication device 200a records Fig.10 The image 1800 of the screen of the blood pressure monitor 104 of the present invention is shown in Figure 2502. The clinician server 200b applies the data template 1801 to the image to extract the set of text, as shown in fields 1802, 804, 1806, 1808, and 1810. The patient selects fields 1802, 804, 1806, 1808, and 1810 to be filled with text into one or more selected data fields of the website 2502. In this way, the clinician server 200b enables the patient to provide medical information via a website, file transfer program, or API(s).

[0337] C. Data Access Module Embodiment

[0338] return Fig.11 , the example data access module 1106 is configured to provide patients and clinicians with access to medical information stored in medical records in the clinician database 1010. As described above in conjunction with the data acquisition module 1104, there are different possible configurations of the personal mobile communication device 200a, in which the application 1002 may or may not be installed. The data access module 1106 is configured to provide access or otherwise display data based on the configuration. In order to determine which configuration a particular patient is using, the example data access module 1106 is configured to access a registry or the patient's medical records to identify the registered personal mobile communication device 200a and / or whether the application 1002 is installed.

[0339] In some embodiments, the data access module 1106 is configured to provide medical information differently based on the operating system of the personal mobile communication device 200a and / or the capabilities of the personal mobile communication device 200a. For example, a first subset of medical information may be specified for a rich-featured personal mobile communication device 200a, while a second subset of medical information may be provided for a reduced-featured personal mobile communication device 200a. Based on the registration information, the data access module 1104 determines whether the application 1002 is running on a rich-featured device or a reduced-featured device, and selects the first or second subset of medical information accordingly.

[0340] The example data access module 1106 may also determine whether to convert the medical and / or treatment information in the patient's medical record into a different format before transmission. For example, the medical information and / or treatment information may be stored in the medical record in the HL7 format. However, this format is not conducive to text messages and / or applications. The example data access module 1106 determines the capabilities of the personal mobile communication device 200a to which the data is to be transmitted. The data access module 1106 determines the capabilities based on registration information indicating whether the application 1002 is installed and / or whether the personal mobile communication device 200a is a feature-rich device. In order to view the medical information on the application 1002, the data access module 1106 uses one or more APIs to convert the medical information and / or treatment information from the HL7 format into, for example, Hypertext Markup Language (“Hypertext Markup Language”). TM L") format, JavaScript Object Notation ("JSON") format, or XML format (e.g., an application format). If the data access module 1106 determines that the application 1002 is not installed, the data access module 1106 converts the information from the HL7 format to a text message or SMS message format via, for example, one or more APIs. Thus, the example data access module 1106 enables patients to view patient medical record information regardless of the capabilities of their personal mobile communication device 200a.

[0341] 1. Example of information display via application

[0342] In some embodiments, the data access module 1106 is configured to display medical and / or treatment information via the application 1002 installed on the personal mobile communication device 200a. In these examples, the data access module 1106 provides medical information from one or more medical records for display in specific fields, graphics, etc. of one or more user interfaces provided by the application 1002. In some cases, fields from the medical records are referenced to fields of the user interface of the application 1002.

[0343] Figures 26 to 29 A diagram of an application 1002 on a personal mobile communication device 200a that displays medical information provided by an access module 1006 is shown according to an example embodiment of the present disclosure. The application 1002 can be configured to display different user interfaces 2600, 2700, 2800, and 2900 when selected by the patient. In some cases, the application 1002 provides a menu or other selectable graphical feature that lists the different user interfaces available. The application 1002 can be configured to receive medical information via one or more APIs linked to data fields of a patient's medical record. In other words, the medical information from the medical record is inserted into blank templates that define graphical user interfaces for displaying the medical information.

[0344] Fig.26The user interface 2600 of provides a first chart 2602 and a second chart 2604, the first chart 2602 showing the total UF removed per day and the second chart 2604 showing the average UF removed for each individual diurnal exchange. It should be appreciated that the medical information displayed in the charts 2602 and 2604 may originate from the home treatment device 90 and / or one or more medical devices. Once the information has been stored in the patient's medical record, the data access module 1106 of the clinician server 200b provides access to medical information from different sources, thereby providing information transparency to the patient.

[0345] The user interface 2600 is configured to enable the patient to select data points on the graphs 2602 and 2604 to provide additional treatment information. The user interface 2600 also enables the patient to select a time range for the graphs 2602 and 2604. After receiving the selection, the application 1002 transmits a message indicating the selection to the data access module 1106. In turn, the data access module 1106 provides the requested medical information.

[0346] Fig. 27 The example user interface 2700 of FIG. 2700 shows the average drain time for each UF exchange. The drain time is provided in chart 2702. Between user interfaces 2600 and 2700, the patient can assess the progress of the treatment over time. Any deviation in treatment should be obvious and help convince the patient to adhere to the prescribed treatment.

[0347] The example user interface 2800 includes a calendar indicating the number of days that the patient adhered to treatment or therapy compared to the number of days that the patient did not adhere to treatment. The patient can select one of the days to view additional medical information. For example, the user interface 2900 displays treatment or medical information for April 26. In addition to the details of UF removed during manual exchange compared to the UF removed via the home treatment device 90, this information also includes the total amount of UF removed in one day. In the illustrated embodiment, the machine treatment information includes the program name, the prescribed treatment time, the actual treatment time, and the amount of UF removed. The data access module 1106 can determine whether to adhere to treatment based on the actual treatment time within the threshold of the prescribed treatment time. In some embodiments, the data access module 1106 and / or the data acquisition module 1104 can determine adherence when receiving medical or treatment information, and set a corresponding mark or other indication in the patient's medical record to reflect the adherence or non-adherence.

[0348] In some examples, while receiving machine treatment information separately from the home treatment device 90, the patient enters treatment information for manual exchange via the application 1002 on the personal mobile communication device 200a. In other examples, the user interface 2900 can display the treatment that occurs at the patient's home and the treatment that occurs in the clinic. The information can be organized based on the machine receiving the information, the program name, the type of treatment, the prescription, etc. The user interface 2900 in the illustrated example accordingly provides a single display of the UF removed for different exchanges, thereby providing the patient with information about the effectiveness of manual exchanges compared to machine-operated exchanges. Fig.10 The example system 100 enables information from both exchanges to be stored together (based on treatment day) for subsequent display and / or analysis.

[0349] 2. Example of information display via a web browser

[0350] In some embodiments, the personal mobile communication device 200a may not have the application 1002 installed. Instead, the patient may use a web browsing application to access a website or interface hosted by the clinician server 200b. In these embodiments, the data access module 1006 is configured to display medical information and / or treatment information in one or more web pages, similar to Figures 26 to 29 2600 to 2900 of the user interface. In this embodiment, the personal mobile communication device 200a accesses the data access module 1106 via the website. The user interface or feature selected via the personal mobile communication device 200a causes the data access module 1106 to display the medical information within the web page. The data access module 1106 can be configured to format or render the medical information and / or treatment information based on the web browser type and / or operating system of the personal mobile communication device 200a. In some cases, the data access module 1106 can request a username and password from the patient before providing access to the website.

[0351] 3. Example of information display via text

[0352] In some embodiments, the data access module 1106 is configured to provide medical information and / or treatment information to the personal mobile communication device 200a via a text message. In these examples, the data access module 1106 may provide the information in response to a text received from the personal mobile communication device 200a. In other examples, the data access module 1106 may periodically (e.g., daily, weekly, etc.) transmit medical and / or treatment information to the patient's personal mobile communication device 200a.

[0353] In an example, the data access module 1106 may receive a text message including the text “Sending 7 Days UF Data.” In response, the data access module 1106 identifies a medical record corresponding to the phone number of the personal mobile communication device 200a from which the text message was received. The data access module 1106 may then use a lookup table or keyword search to identify a field in the patient's medical record that includes a matching set of characters or text related to UF data (e.g., “7 Days UF”). The data access module 1106 copies the matching text and creates a reply message with UF values ​​for the previous seven days, which is transmitted to the personal mobile communication device 200a. Additionally or alternatively, the data access module 1106 creates and renders a seven day graph, similar to Fig.26 2602 in the text message. The data access module 1106 creates an image of the chart, which is sent to the personal mobile communication device 200a as an image in the text message. The image can be stored as a .jpeg, .gif, .png, etc. file. The patient of the personal mobile communication device 200a can view the chart via the text message. In this way, the example data access module 1106 is configured to provide patients with access to medical and treatment information regardless of the capabilities and / or operating system of their personal mobile communication device 200a. In addition, the data access module 1106 determines how to transmit data based on registration information provided by the patient and / or an indication of whether the application 1002 is installed on the patient's personal mobile communication device 200a.

[0354] 4. Alarm / Reminder Embodiment

[0355] In addition to providing the display of medical and / or therapeutic information, Fig.11 The example data access module 1106 is also configured to determine and / or generate alarms and / or reminders for patients and / or clinicians. The data access module 1106 can send alarms and / or reminders to the patient's personal mobile communication device 200a or clinician device 152. In some embodiments, the data access module 1106 may include a rule table that specifies which devices certain alarms / reminders will be sent to. Clinicians can use clinician devices 152 to subscribe to certain alarms / reminders and / or patients.

[0356] The data access module 1106 is configured to provide alerts / reminders based on how the personal mobile communication device 200a is configured to display medical and / or treatment information. For example, if the application 1002 is installed, the data access module 1106 provides the alerts / reminders through the appropriate user interface of the application 1002. In some cases, the application 1002 is configured to display a notification indicating the alert / reminder. If the application 1002 is not installed, the data access module 1106 determines that the alerts and / or reminders are to be transmitted to the personal mobile communication device 200a via SMS or other text messages.

[0357] In some embodiments, the data access module 1106 includes or has access to a data structure or list that specifies certain conditions under which an alarm or reminder is to be generated. In an example, a condition may compare a single data value or trend (e.g., a 30-day moving average) to a range of acceptable values ​​and / or thresholds (which may include hard limits and / or soft limits). In other examples, an alarm or reminder may be generated based on multiple conditions based on comparing different types of information to respective limits. In some cases, the data access module 1106 determines derived information calculated from treatment and / or medical information and then compares it to an acceptable range. Examples of alarms / reminders that may be transmitted by the data access module 1106 via text messaging and / or displayed within the application 1002 are provided below.

[0358] In an example, if it is detected that the patient begins to deviate from the prescribed treatment, the data access module 1106 can generate an alarm or reminder. For example, after detecting that two days have passed since the treatment information was received, the data access module 1106 (operating according to the reminder rule) transmits a reminder message to the personal mobile communication device 200a. For example, the reminder message specifies that the patient should perform the treatment. The reminder message may also include information (or information links) describing why the treatment is important, or describing to the patient what will happen to his body if the treatment is not carried out in time. If the data access module 1106 detects that the treatment information has not been received for four days, for example, the data access module 1106 promotes the reminder to an alarm (operating according to the alarm rule). The data access module 1106 transmits the alarm to the personal mobile communication device 200a and / or the clinician device 152 to provide an indication of the severity of non-adherence to the treatment. As described above, the alarm and / or reminder are transmitted by the data access module 1106 based on whether the application 1002 is installed. Even if the application 1002 is installed, the data access module 1106 is also configured to transmit a text message to the personal mobile communication device 200a to mark the patient's attention.

[0359] In some examples, the patient is prescribed manual exchanges. Therefore, the patient must provide treatment information indicating manual exchanges. The data acquisition module 1106 is configured to send an alarm or reminder if no manual exchange information is received within a predetermined time period (e.g., within 2 days after a scheduled treatment). In addition, if the manual exchange is not completed correctly (e.g., short fill or dwell time), the data access module 1106 sends a reminder and / or alarm about insufficient exchanges. In order to determine insufficient exchanges, the data access module 1106 can compare the fill, dwell and / or drain times with pre-established acceptable ranges and / or thresholds. In some cases, the data access module 1106 can request the patient to perform a complete exchange.

[0360] In an example, an alarm and / or reminder can be generated to indicate that the patient should select a different treatment program from a plurality of prescribed treatment programs or adjust the treatment program. In this example, the alarm or reminder rule can specify that the data access module 1106 compares the patient's blood pressure or weight with a corresponding change threshold, while calculating the cumulative fluid value and comparing it with the threshold. The cumulative fluid value can be determined by the individual fluid filling and discharge amounts, which indicates the fluid remaining in the patient's peritoneal cavity. If the blood pressure or weight and the cumulative fluid value (or trend) are outside the acceptable range, the data access module 1106 generates an alarm. The alarm can indicate that the patient has accumulated fluid and should select a treatment program with a longer drainage duration (or a shorter filling duration) (or the treatment program should be adjusted to provide a longer drainage duration or a shorter filling duration). The data access module 1106 sends an alarm to be displayed on the personal mobile communication device 200a. The patient can respond via the application 1002 or a text message, so that the clinician server 200b makes appropriate changes to the patient's prescription or treatment program.

[0361] In some embodiments, the alarm and / or reminder may specify conditions under which the patient is prompted to enter additional information. In these embodiments, the data access module 1106 uses the treatment information from the home treatment device 90 as the basis for determining whether the patient is to provide medical information via the personal mobile communication device 200a. In an example, the data acquisition module 1106 may access an alarm and / or reminder rule that specifies conditions under which a prompt or text message is sent to the patient's personal mobile communication device 200a to prompt an additional weight or blood pressure measurement. For example, if the blood pressure value (or trend) exceeds a predetermined threshold, the alarm or reminder may specify that a prompt for a new blood pressure measurement is required. In other examples, if the accumulated fluid value or UF removal value (or trend) exceeds an acceptable range, the alarm or reminder may specify that a prompt for a new blood pressure measurement is required. In response, the data access module 1106 sends a text message or notification via the application 1002 to enable the patient to perform and record a blood pressure measurement. In some cases, the application 1002 may open a user interface (e.g., Fig.30 3000 ), prompting the patient to enter blood pressure information. If the additional data received from the personal mobile communication device 200a is not within an acceptable range, the data access module 1106 can elevate the reminder to an alarm, which is transmitted to the clinician device 152 and / or the personal mobile communication device 200a. Therefore, the data access module 1106 is configured to operate a rule that determines a critical patient condition, which seeks additional information from the patient before determining whether further attention or action is required by the clinician or the patient.

[0362] In another embodiment, the rules of the data access module 1106 may instruct the patient to check and / or make changes to the home treatment device 90. In an example, the rule may specify that if no treatment information is received from the home treatment device 90 within a defined time period (e.g., two days), the data access module 1106 will send a reminder to the patient. In this case, the patient may have provided medical information indicating that treatment has occurred, and the data access module 1106 uses this medical information to determine that the reminder does not need to comply with the treatment. Instead, the data access module 1106 determines that a reminder to check the network connection of the home treatment device 90 will be sent to the patient so that the treatment information stored on the machine 90 can be retrieved. The patient can respond to the reminder using a personal mobile communication device 200a to indicate that the connection has been checked. After receiving a response from the patient, the data acquisition module 1104 can send a check message to the home treatment device 90 to obtain the missing treatment information. If the connection still cannot be established, the data access module 1106 can send a reminder to the patient, clinician, and / or network administrator, which has more specific instructions for activating the home treatment device 90 and / or overcoming network connectivity issues.

[0363] In another example, the data access module 1106 may include one or more rules that specify that a reminder is generated in response to treatment information being out of range. For example, a large difference between the fluid fill-in amount and the discharge amount may indicate that the dialysis tube or the connection to the patient has a leak. In response, the data access module 1106 sends a reminder to the patient, prompting the patient to verify the fluid connection. The patient can provide a response indicating whether a leak is detected. In response, the data access module 1106 determines whether the leak has been corrected in a subsequent treatment cycle (or basic sequence) or whether the pipeline should be replaced. The data access module 1106 can determine similar consumables problems such as boxes and cartridges based on treatment and / or medical information. For example, a small amount of UF removed can prompt the data access module 1106 to send a reminder to the patient to verify the concentration of the dialysate and / or concentrate being connected to the home treatment device 90.

[0364] D. Treatment Control Module Embodiment

[0365] Fig.11 The example treatment control module 1110 is configured to enable the patient and / or clinician to change the prescription and / or program on the home treatment device 90. For operation, the home treatment device 90 is assigned one or more prescriptions for the patient. The prescription can specify the type of treatment (e.g., automated peritoneal dialysis treatment, manual exchange treatment, hemodialysis treatment, etc.), the time period during which the patient will receive treatment, the glucose level or other concentration level of the treatment fluid, the amount of UF removed per day, and / or the number of times per day or within the duration range for each treatment. Each prescription can include one or more programs. The program can specify the duration of treatment, the total amount of fluid to be provided to the patient, the number of fill, stay, and drain cycles to be repeated, and / or an indication of whether the treatment includes tidal therapy. The program differences in the prescription allow the patient or clinician to change certain treatment parameters based on the patient's condition or activity.

[0366] The prescription and the associated program are stored in an electronic prescription in the clinician database 1010. In some embodiments, the prescription can be stored in the patient's medical record. The home treatment device 90 is programmed with one or more prescriptions. The programming can be performed locally by the clinician or the patient, or it can be performed remotely from the clinician server 200b. For example, the clinician server 200b (e.g., the treatment control module 1110) can send a copy of the prescription from the clinician database 1010 to the home treatment device 90 after registration.

[0367] In some embodiments, the example therapy control module 1110 is configured to operate in conjunction with the application 1002 on the personal mobile communication device 200a and / or an application on the clinician device 152 to enable the patient and / or clinician to select different prescription programs and / or prescriptions. Fig.31 A diagram of a user interface 3100 of an application 1002 is shown that enables a patient to select between three different programs: a short program, a long program, and a weekend program. The patient can select a program based on their activity and / or condition. In some embodiments, the application 1002 can display an alert from the data access module 1106 that provides a suggestion to change the program based on detected fluid accumulation, weight gain, or elevated blood pressure.

[0368] After the patient selects a different program via the user interface 3100, the application 1002 sends a message indicating the selection to the treatment control module 1110. In response, the treatment control module 1110 updates the patient's medical record to reflect the changed program, including the time / date of the change. In addition, the treatment control module 1110 transmits a message to the home treatment device 90, which provides instructions for changing to the selected program. In some cases, the message may include treatment parameters for the newly selected program. The home treatment device 90 therefore performs the next treatment based on the newly selected program. In some cases, the home treatment device 90 may display a prompt to allow the patient to confirm the new program before operating according to the program.

[0369] In some embodiments, the treatment control module 1110 can perform a check to verify that the patient is authorized to make a change to the program and / or whether the change is allowed. For example, the treatment control module 1110 receives an indication that the patient desires to change from a short program to a long program. The treatment control module 1110 compares the patient's medical information to one or more thresholds to ensure that the change will not adversely affect the patient. For example, if the patient has accumulated a relatively large amount of fluid, the treatment control module 1110 may not approve the change from a short program to a long program. If the change cannot be made, the treatment control module 1110 sends a message to the personal mobile communication device 200a indicating why the change cannot be made.

[0370] In embodiments, the therapy control module 1110 may send a notification to the clinician device 152 indicating that the patient desires a change in program. The therapy control module 1110 may not communicate the change to the home therapy device 90 until confirmation is received from the clinician device 152. In some embodiments, the clinician may use their clinician device 152 to change the program and / or prescription via the therapy control module 1110. In these embodiments, the therapy control module 1110 may send a message indicating the change in program and / or indicating that the clinician made the change for display in the application 1002 of the personal mobile communication device 200a.

[0371] In the event that the personal mobile communication device 200a does not include the application 1002, the therapy control module 1110 is configured to allow changes to the prescription. For example, the therapy control module 1110 may host a website accessible by a web browser on the personal mobile communication device 200a. The website may include a web browser similar to Fig.31 Functional components of the user interface 3100 to enable patients to remotely select different programs and / or prescriptions.

[0372] Additionally or alternatively, the treatment control module 1110 is configured to enable a treatment change via a text message. In an example, the patient can send a message with the text "Change Treatment" from the personal mobile communication device 200a. In response, the treatment control module 1110 is configured to send a reply message with different treatment program options and a corresponding code or indicator after each option. The patient can enter a marker or code in the response message to select the desired program. In another example, the patient can send a message with text consisting of, for example, "Long Program" to cause the treatment control module 1110 to change the program to a long program.

[0373] E. Educational Module Example

[0374] Fig.11 The example education module 1108 is configured to provide educational materials and / or encouragement to the patient via the personal mobile communication device 200a. Fig.11 In addition to the other modules 1102 to 1106 and module 1110 of the personal mobile communication device 200a, the education module 1108 is configured to provide content / information based on the configuration of the personal mobile communication device 200a. For example, if the application 1002 is installed, the education module 1108 is configured to select and provide educational materials through the application 1002. If the application is not installed, the education module 1108 is configured to provide educational materials via a website and / or text message. In the example of a text message, the education module 1108 can be configured to construct educational materials suitable for a text message, or provide a link to educational materials at the clinician database 1010 or hosted by a third-party server.

[0375] As described herein, educational materials may include text-based articles, audio, video, multimedia presentations, etc. The educational materials may provide general information about the patient's condition, information about the application 1002, and / or information about the home therapeutic device 90. The educational materials may also be targeted based on detected patient conditions (determined by their medical records) and / or feedback regarding the patient's use of the application 1002 and / or the home therapeutic device 90.

[0376] In addition, as described herein, encouragement includes text, audio, video, or multimedia presentations intended to improve patient mood or help patients adhere to the program. Incentives may also include rewards or badges. In some embodiments, the education module 1108 may be configured to provide encouragement based on the detected condition. In some cases, encouragement may be provided in conjunction with an alert generated by the data access module 1106. In an example of encouragement, different status levels may be provided to patients based on adherence rates (e.g., a "dialysis superstar" for near-perfect adherence).

[0377] The educational materials and / or encouragement may be stored in the clinician database 1010. Additionally, the education module 1108 may access third party materials, such as materials from the National Institutes of Health or the Cleveland Clinic®. The education module 1108 may include a rules data structure that specifies conditions under which certain educational materials and / or encouragement will be provided to the personal mobile communication device 200a.

[0378] In an example, the data access module 1106 determines that the patient is not adhering to treatment.In addition to the data access module 1106 sending reminders, the education module 1108 can also suggest or provide a video link about the importance of adherence. Fig.32 An example user interface 3200 of the application 1002 is shown, which displays an educational video related to adherence provided by the education module 1108. The example user interface 3200 also provides a list of recommended educational materials based on the detected patient condition. For example, after detecting from a medical record that the patient has high blood pressure or receiving it as medical information, the education module 1108 is configured to recommend educational content about lowering blood pressure. In addition, after detecting that the patient does not have a prescription program that has been changed, the education module 1108 determines that educational content explaining the program options should be recommended.

[0379] The example education module 1108 can also detect how the patient interacts with the application 1002 and recommend educational content. For example, the education module 1108 receives feedback from the application 1002 indicating that the patient is filling out a user interface (e.g., Fig.14In response, the education module 1108 can provide a notification via the application 1002 that recommends that the patient view a tutorial on information entry using the recorded images.

[0380] The example education module 1108 can store any educational content or encouraging instructions displayed by the personal mobile communication device 200a to the patient's medical record. Such information may be useful for clinicians to determine how to encourage patients to accept treatment. The stored information can also provide an indication of the patient's awareness of treatment.

[0381] F. Auxiliary Module Embodiment

[0382] Fig.12 The example auxiliary module 1112 is configured to create a communication session between a patient and a clinician. Specifically, the auxiliary module 1112 is configured to create a communication session between the clinician device 152 and the personal mobile communication device 200a. The auxiliary module 1112 can use the capabilities of the personal mobile communication device 200a to determine an appropriate communication session.

[0383] The communication session may include a video session, an audio call, a conference call, an SMS session, or a Web messaging session. If the application 1002 is installed, the auxiliary module 1112 may access options for selecting a video session, a conference session, or a Web messaging session for connecting the patient to the clinician via the application 1002. If the application 1002 is not installed, the auxiliary module 1112 may be limited to options related to the native communication capabilities of the personal mobile communication device 200a, such as text messaging and audio calling.

[0384] In some embodiments, the patient can initiate a session. Application 1002 is configured to enable the patient to request to contact a clinician, including specifying a preferred communication method. Using the text function component of application 1002, the patient can send a text message including a "help" text to auxiliary module 1112 to start a session. After the patient requests to start a session, auxiliary module 1112 is configured to identify available clinicians. In some embodiments, auxiliary module 1112 can locate the records of clinicians associated with the patient, and send a check / request message to their equipment. The response received from one of the devices 152 provides an indication that the clinician is available and willing to communicate with the patient. In some cases, the response may indicate the communication mode of the clinician. In response to the received message, auxiliary module 1112 starts a communication session. This can include establishing a Web call, a message sending and receiving session, or an audio call between a personal mobile communication device 200a and a clinician device 152. In some embodiments, in addition to broadcasting verification messages to a group of clinicians, the auxiliary module 1112 can send verification / request messages to clinicians sequentially according to a predetermined order (e.g., first: clinicians; second: clinicians on duty in the same office; third: clinicians on duty in other offices, etc.). Fig.33 A diagram of a user interface 3300 of an application 1002 providing a video session within a clinician is shown. The video session enables the patient to address their concerns about the treatment. The video session also enables the clinician to view the real-time setup of the treatment or assist the patient in setting up the treatment.

[0385] In some embodiments, the auxiliary module 1112 may determine to open a communication session, or recommend opening a communication session. The auxiliary module 1112 may provide recommendations in conjunction with the data access module 1106 that generates alarms and / or reminders. The auxiliary module 1112 may identify a clinician device 152 that can be used to participate in the session after detecting the conditions for the reminder and / or alarm, and then initiate a call to the personal mobile communication device 200a to resolve the reminder and / or alarm. In an example, the auxiliary module 1112 may attempt to create a communication session after detecting that the patient's blood pressure, weight, accumulated fluid, etc. is above a predetermined threshold or has changed significantly within a predetermined time period.

[0386] The example assistance module 1112 can determine the type of assistance being sought to identify the correct individual to connect. In addition to clinicians, the assistance module 1112 can also connect to information technology experts and home therapy instrument experts. Before starting a session, the application 1002 can prompt the patient to identify the type of assistance (e.g., application help, machine help, clinical help, etc.). In other cases, the assistance module 1112 can determine the type of assistance based on the context in which the session request is received. For example, after reviewing the educational training program about the home therapy instrument 90, the assistance module 1112 determines that the subsequent assistance request is related to operating the home therapy instrument 90. In another example, when the application 1002 is displaying a user interface about UF trends, the assistance module 1112 determines that the subsequent assistance request is about a clinical problem.

[0387] The example auxiliary module 1112 can be configured to record a log of the communication session into the patient's medical record. The auxiliary module 1112 can record the date / time of the communication session and an indication of how the session was initiated. The record can also include the participants in the communication session and a record of the communication. For text messages, this may include a copy of the message. For audio or video, this may include a recording of the call or a transcription of the call.

[0388] III. in conclusion

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

Claims

1. A system for transmitting treatment information from a home treatment device, the system comprising: Clinician Server; a personal mobile communication device including an application storing first registration information for communicating with the clinician server via an Internet connection; A home therapy device assigned to a patient, the home therapy device: (i) communicatively coupled to the clinician server via a separate Internet connection specified by the second registration information, and (ii) communicatively coupled to the personal mobile communication device via a local connection, and configured to transmit treatment information related to a treatment for renal failure of the patient as specified by the prescription; as well as a clinician database communicatively coupled to the clinician server, the clinician database being configured to store the treatment information from the home treatment device in the electronic medical record of the patient, wherein the home treatment device is configured to: transmit the treatment information to the personal mobile communication device when the second registration information is not available or the separate Internet connection is not available, and Wherein, the application on the personal mobile communication device is configured to: use the first registration information to transmit the received treatment information to the clinician server for storage in the clinician database at the electronic medical record of the patient.

2. The system according to claim 1, wherein: The application is configured to: The treatment information is converted to a Health Level 7 ("HL7") format before being transmitted to the clinician server.

3. The system according to claim 1, wherein: The first registration information includes at least one of the following: An Internet address of the clinician server, an identifier of the clinician server, application programming interface ("API") information for connecting to the clinician server, or an identifier of at least one of the patient or the home therapy device.

4. The system according to claim 1, wherein: The clinician database is configured to store registration information in a patient registration file, the registration information specifies at least one of a patient activation code ("PAC"), information indicative of the personal mobile communication device, or a patient identifier, The registration information used by the clinician server is used to communicate with the application and store received treatment information in the electronic medical record of the patient.

5. The system according to claim 1, wherein: The home treatment device at least includes a renal failure treatment machine or an infusion pump.

6. The system according to claim 1, wherein: The treatment information includes blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, consumption data regarding consumables, data on the amount of fluid injected, the amount of ultrafiltration ("UF") removed from the patient, the amount of fluid for renal failure therapy used during renal failure treatment, treatment time, alarms, reminders or at least one of diagnostic information.

7. The system according to claim 1, wherein: The personal mobile communication device is a smartphone, a cellular phone or a tablet computer.

8. The system according to claim 1, wherein: The personal mobile communication device communicates via wireless local area network ("WLAN"), local area network, Bluetooth TM Connectivity, WiFi TM Connection, Zigbee ® Connectivity, Z-Wave ® At least one of a wireless universal serial bus ("USB") connection is communicatively coupled to the home treatment device.

9. The system according to claim 1, wherein: The clinician server is configured to transmit a new prescription to the application on the personal mobile communication device when the registration information of the home treatment device is not available, and wherein, The personal mobile communication device is configured to transmit the new prescription to the home treatment device for subsequent renal failure treatment.

10. The system according to claim 1, wherein: The home treatment device is configured to transmit the treatment information to the application on the personal mobile communication device only after the renal failure treatment is completed or stopped.

11. A home treatment system comprising: a home treatment device configured to perform renal failure treatment; as well as A personal mobile communication device including an application having a calendar feature that identifies the time / date when the renal failure treatment is scheduled to be performed by the home treatment device, the application being configured to: using the calendar feature to determine the time / date of the next scheduled renal failure treatment, causing the display interface of the personal mobile communication device to display a prompt for medical information at a designated time before the next scheduled renal failure treatment, and When the medical information associated with the reminder is not received before the next scheduled renal failure treatment, a message is transmitted to the home treatment device, the message causing the home treatment device to delay starting the next scheduled renal failure treatment.

12. The system according to claim 11, wherein: The personal mobile communication device is communicatively coupled to the home treatment device via a server and a network, and wherein, The application is configured to transmit the message to the server, and the server transmits the message to the home treatment device.

13. The system according to claim 11, wherein: The personal mobile communication device communicates via wireless local area network ("WLAN"), local area network, Bluetooth TM Connectivity, WiFi TM Connection, Zigbee ® Connectivity, Z-Wave ® At least one of a wireless universal serial bus ("USB") connection is communicatively coupled to the home therapy device.

14. The system according to claim 11, wherein: The application is also configured to: receiving medical information associated with the prompt; and After receiving the medical information, transmitting a confirmation message to the home treatment device, wherein the confirmation message is at least one of (i) or (ii) (i), (i) indicates that the renal failure treatment can be continued, (ii) includes at least some of said medical information.

15. The system of claim 14, wherein: The personal mobile communication device is communicatively coupled to a server and a network, and wherein, The application is configured to transmit the medical information to the server for entry into an electronic medical record.

16. The system of claim 15, wherein: The application is configured to transmit the confirmation message to the server, and the server transmits the confirmation message to the home treatment device.

17. The system of claim 14, wherein: The application is also configured to: comparing the received medical information to at least one threshold value or acceptable range of values; and The affirmative message is transmitted when the received medical information is below the at least one threshold value or within the acceptable value range.

18. The system of claim 11, wherein: The prompt includes an alert, notification, or link, selection of which causes display of at least one data field for receiving alphanumeric characters as the medical information.

19. The system of claim 11, wherein: The prompt includes at least one data field configured to receive alphanumeric characters as the medical information.

20. The system of claim 11, wherein: The prompt includes a link to a tutorial, selection of which causes the application to instruct the patient how to obtain the medical information, The tutorial includes at least one of text, text / picture, audio recording, animation or video.

21. The system of claim 11, wherein: The prompt further indicates that the medical information is required before the next scheduled renal failure treatment can begin.

22. The system of claim 11, wherein: The medical information includes at least one of a systolic blood pressure value, a diastolic blood pressure value, a heart rate value, or a patient weight value.

23. The system of claim 11, wherein: The designated time is one of five minutes, fifteen minutes or thirty minutes.

24. The system of claim 11, wherein: The home treatment device at least includes a renal failure treatment machine or an infusion pump, and wherein, The personal mobile communication device is a smartphone, a cellular phone or a tablet computer.

25. A mobile communication device, comprising: Display interface; Memory, which stores: a calendar data structure identifying the times / dates when renal failure treatment is scheduled to be performed by the home therapy device, and Define the instructions for the application; as well as a processor communicatively coupled to the display interface and the memory, the processor configured to execute the instructions to cause the application to: using the calendar data structure to determine the time / date of the next scheduled renal failure treatment, causing the display interface to display a prompt for medical information at a specified time before the next scheduled renal failure treatment, and When the medical information associated with the reminder is not received before the next scheduled renal failure treatment, the home treatment device is caused to delay starting the next scheduled renal failure treatment.

26. The apparatus of claim 25, wherein: Execution of the instructions by the processor further causes the application to: receiving medical information associated with the prompt; and After receiving the medical information, the home treatment device starts the next scheduled renal failure treatment.

27. The apparatus of claim 25, wherein: The prompt includes at least one of the following: an alert, notification, or link, selection of which causes display of at least one data field to receive alphanumeric characters as medical information, or At least one data field is configured to receive alphanumeric characters as the medical information.

28. The apparatus of claim 25, wherein: The mobile communication device is communicatively coupled to the server and the network, and Wherein, the processor executing the instructions further causes the application to receive the calendar data structure from the server.

29. The apparatus of claim 25, wherein: Execution of the instructions by the processor further causes the application to: using the calendar data structure to determine that the next scheduled renal failure treatment has ended, causing the display interface to display a second prompt for second medical information, receiving second medical information associated with the second prompt, and The second medical information is transmitted to a server via a network.

30. The device according to claim 29, wherein: The second medical information includes at least one of blood pressure measurement data, pulse data, weight data, glucose data, temperature data, renal failure manual exchange data, consumption data on consumables, data on the amount of fluid injected, the amount of ultrafiltration ("UF") removed, the amount of renal failure treatment fluid used, treatment time, alarm information, reminder information or diagnostic information.

31. A home treatment system comprising: a home treatment device configured to perform renal failure treatment; as well as A personal mobile communication device comprising an application configured to enable a patient to select a type of procedure for future renal failure treatment, the application being configured to: determining that a short program and a long program are available for future treatment of renal failure, the short program comprising a first number of cycles for treatment of renal failure, and the long program comprising a second number of cycles for treatment of renal failure, the second number of cycles being greater than the first number of cycles, causing a user interface to be displayed on a personal mobile communication device, the user interface including an option to select one of the short program or the long program, receiving, via the user interface, a selection of the short program or the long program, and A message is transmitted to the home treatment device, the message indicating the selection of the short program or the long program for future renal failure treatment.

32. The home treatment system according to claim 31, wherein: The personal mobile communication device is communicatively coupled to the home treatment device via a server and a network, and The application is configured to transmit the message to the server, and the server transmits the message to the home treatment device.

33. The home treatment system according to claim 32, wherein: After confirming that selecting a short program or a long program for future renal failure treatment will not adversely affect at least one of fluid accumulation in the patient, the patient's weight, or the patient's blood pressure, the server transmits the message to the home treatment device.

34. A home treatment system according to claim 33, wherein: The server blocks transmission of the message to the home treatment device when selecting a short program or a long program for future renal failure treatment will adversely affect at least one of fluid accumulation in the patient, the patient's weight, or the patient's blood pressure.

35. The home treatment system according to claim 34, wherein: The application is configured to receive an alert message from the server indicating that selecting a short program or a long program for future renal failure treatment will have an adverse effect on fluid accumulation in the patient, patient weight, or patient blood pressure.

36. The home treatment system according to claim 31, wherein: The personal mobile communication device communicates via wireless local area network ("WLAN"), local area network, Bluetooth TM Connectivity, WiFi TM Connection, Zigbee ® Connectivity, Z-Wave ® At least one of a wireless universal serial bus ("USB") connection, or a wireless universal serial bus ("USB") connection is communicatively coupled to the home treatment device.

37. The home treatment system according to claim 31, wherein: The short program comprises a first total volume of dialysate to be provided and a first duration, and The long procedure comprises a second volume of dialysate to be provided that is greater than the first total volume and a second duration that is longer than the first duration.

38. The home treatment system according to claim 31, wherein: The application is also configured to: additionally determining a weekend schedule that may be used for the future renal failure treatment, the weekend schedule comprising a third number of cycles, the third number of cycles being greater than the first number of cycles and less than the second number of cycles, and The user interface is caused to additionally display the weekend program as a selectable option.

39. The home treatment system according to claim 11, wherein: The short program and the long program are configured to be performed during the night while the patient is asleep.

40. The home treatment system according to claim 39, wherein: The application is also configured to: Additionally determining a daytime program for the future treatment of renal failure, and The user interface is caused to additionally display the daytime program as a selectable option.

41. The home treatment system according to claim 31, wherein: The application is configured to determine that the short program and the long program are available for future renal failure treatment based on a message from a server indicating that the short program and the long program are available for a patient, and The server determines that the short program and the long program are available using medical data associated with the patient, the medical data including at least one of estimated fluid accumulation in the patient, a weight trend of the patient, or a blood pressure trend of the patient.

42. The home treatment system of claim 31, wherein: The home treatment device at least includes a renal failure treatment machine or an infusion pump, and The personal mobile communication device is a smart phone, a cellular phone or a tablet computer.

43. The home treatment system according to claim 11, wherein: The application is also configured to: a calendar showing scheduled renal failure treatments for the patient; and Upon receiving a selection of one of the scheduled renal failure treatments, the user interface is caused to display an option to select either a short procedure or a long procedure.

Images